Support NeoGAF

[Exis]

Short version- couple of questions..
1) Is there a website or community for Tech workers that focuses on 'how' they work as opposed to the technology behind it?
2) Is there any resource that highlights development teams, even in a historical context?
3) How do you get career advise?


Long Version
I have been doing support work for ten years now, worked my way up from my first crappy job answering phones to having a small staff under me and running some important systems. I busted my ass to get here, and the next jump is having my own team.

Over the last couple of years I have been studying development and operations frameworks, passed a few overly expensive certifications and I started going to their conferences, users groups and the reading discussions on their boards. I have come to a conclusion that while the subject is fascinating and I can understand why it's important it has a number of mostly philosophical problems, and in my own opinion is pitched badly to workers when implemented.

So I don't like talking to them, where can I go online to find mid level tech workers talking about their jobs?

 

[CharlieDigital]

Short version- couple of questions..
1) Is there a website or community for Tech workers that focuses on 'how' they work as opposed to the technology behind it?

I haven't really seen any. I've been considering going back to school for a software engineering masters. That might be your best bet.

2) Is there any resource that highlights development teams, even in a historical context?

Fred Brooks' "The Mythical Man Month" is an excellent read, particularly his bit about the "Surgical Team". It's not 100% relevant today, but it's still a good read nonetheless. I also recently finished Eric Brechner's "I.M Wright's Hard Code". A great read, lots of humor, and good insight on practices from within Microsoft.

3) How do you get career advise?

Find more senior people in the field who have been successful and talk them up over coffee or work on their teams and see how they operate.

 

[CharlieDigital]

Some excerpts from "Hard Code"

From: October 1, 2004: "Lean: More than good pastrami", on how to increase efficiency

Go deep

Of course, you can use Scrum and XP poorly by making the customer wait for value while you work on "infrastructure." There is a fundamental premise behind quick iterations built around regular customer feedback: develop the code depth first, not breadth first.

Breadth first in the extreme means spec every feature, then design every feature, then code every feature, and then test every feature. Depth first in the extreme means spec, design, code, and test one feature completely, and then when you are done move on to the next feature. Naturally, neither extreme is good, but depth first is fa r better. For most teams, you want to do a high-level breadth design and then quickly switch into depth-first, low-level design and implementation.

This is just what Microsoft Office is doing with feature crews. First, teams plan what features they need and how the features go together. Then folks break up into small multidiscipline teams that focus on a single spec at a time, from start to finish. The result is a much faster delivery of fully implemented and stable value to demonstrate for customers.
...
Overprocessing

The fifth deadly waste is over-engineering. You see this all the time in the form of producing overly complex features, fine-tuning performance in areas that already perform adequately or aren't the true bottleneck, and adding generalization or extensibility when it isn't required. This waste is related to overproduction but focused on specific feature implementations.
...
Inventory

The sixth deadly waste is undelivered work product. This is related to cut features, but it also includes the amount of work in progress. When you develop breadth first, all your work is in progress until the code is complete and stable. All the completed specs, designs, and code that are waiting to pass tests are inventory. Their value is not yet realized.

Unrealized value is wasteful because you can't demonstrate the value to customers and partners. You can't get their feedback. You can't improve and optimize your customer value stream. Of course, if product plans change, this unrealized inventory often becomes a huge wasted effort.​

From June 1, 2004: "The day we met" , on how to effectively organize meetings:

Quit wasting my time. Would you, could you, PLEASE quit wasting my time? Maybe if I jump across the table and duct tape your mouth shut, I could take action instead of sitting here incredulously while you incinerate 60 minutes of my life. How does calling a meeting give people license to act like you're worthless? If time is money, most meetings are a market collapse. I am so tired of people who could sooner drive a bus off a cliff than run a decent meeting.​

:lol Brechner is my kind of guy.

 

[deadbeef]

There is sometimes the one-off nugget in Slashdot comments at ask.slashdot.org. You can also read http://stackoverflow.com/tags, which is a community site for developers started by Joel Spolsky, of Joel on Software fame.

There is a mix of technical and process-oriented questions there; I'm sure you could find something useful.

I guess different places use different terminology - what do you mean by an operations framework? A particular software process implementation?