Who's on your team?

• 27 August 2010
• dev

The days when developers did this sort of stuff, or indeed, this are long gone.

I was going to intro that with a "Sadly" but to be honest it's only sad for the management who exploited naive, passionate and gifted employees who "believed in the company". Those hackers who produced work out of love of what they were making rather than for fair payment also allowed themselves to be exploited so it works both ways.

I think (hope?) that developers have become more business savvy. On one hand this is bad for companies because they are more aware of the value of what they're producing and are less likely to be screwed over. It's also good for companies because it means that they will focus on creating what is important to the company rather than their own pet project.

That being said, I think there are many idealistic developers out there but that they tend to move towards smaller, more idealistic companies rather than to behemoths like Microsoft, IBM, Apple or Google. Any of these companies will have their internal fan boys but there's a difference between loving your company and loving what you're producing. Many of these idealists work in startups where they can be convinced that the technology is the difference between success and failure (it's a factor but so is marketing and most of all , luck).

Personally I'm somewhat conflicted on this change. Reading the stories on folklore.org I'm frankly jealous of these early hackers. Pulling together cutting edge products and loving every minute of it. The sheer enjoyment that comes out from the stories weighs against the absolutely massive work effort they put in and also, the individual technical brilliance they display(and I don't). I also realise that I've never heard of any of these guys except for Steve Jobs. The saying "there's no such thing as a rich engineer" comes to mind.

Most teams will need at least (these roles can/will overlap):

• A manager:  This doesn't have to be a formal assignation but there has to be someone responsible for divvying up the work. Even with self actualised and responsible employees, someone's got to keep an eye on the schedule and have the power to get people to do the grunt work when necessary.
• A domain expert: This could be someone on team or a client who comes on-site/is highly available to answer questions. When John asks "should the font be size 12 or 14" or "how do we calculate the monthly payment amount" someone's got to know the answer (or be able to find out)
• A guru: you'll need one for every technology you're using. So typically in an enterprise environment you'll have a DB expert, an application code expert (C#, Java what have you) and a front end expert. They need not be "expert" (though they should be unless you want unanswered questions) but they should know more that anyone else on the team. These tend to be the closest to the idealistic programmer of yore. Putting in longer hours and harder work.
• Low to mid level developers as backup: These are the G.I.'s of your team and will actually produce most of the work. Ideally they are pretty well cross trained. They have a good general knowledge of the system and can jump in where needed and pick up technologies as necessary. They will take their direction from the three above and provide backup to the guru when needed.
• Client liaison: You don't usually want the developers talking directly to the users. This liaison could be in-team (business analysts) or with the clients (QA department). The whole point is that users and developers may speak the same language, even use the same words but they're really in two different realities and without some translation issues can arise.

There will also be at least one guy (or gal) on every team who always seem slightly stressed, just a bit too loud talking about how tough their schedule is but yet appears to be under performing. They may be the best developer on the team but if they're constantly complaining it will destroy morale and bring down the performance of the rest of the team.

Also, while touch typing is a great skill and does help limit carpal tunnel syndrome (also watch your posture for that), developers don't type fast. If you can hear someone mashing away at a keyboard they're not typing code (or are typing code very badly). Chances are it's email or *cough* blog posts.