The Firepower of Teams
I just finished reading an interesting post by Ben Collins-Sussman. In an attempt to argue that distributed version control is not the silver bullet, he classifies us and puts us into two groups, which he calls the 80% and the 20%.
The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools.
The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. They went to school, learned just enough Java/C#/C++, then got a job writing internal apps for banks, governments, travel firms, law firms, etc. The world usually never sees their software. They use whatever tools Microsoft hands down to them — usally VS.NET if they’re doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java development. They’ve never used Linux, and aren’t very interested in it anyway. Many have never even used version control. If they have, it’s only whatever tool shipped in the Microsoft box (like SourceSafe), or some ancient thing handed down to them. They know exactly enough to get their job done, then go home on the weekend and forget about computers.
Ben took a lot of heat for his oversimplification. People, it seems, don’t like to be categorized, a fact I too discovered when trying to make a distinction between Developers and Programmers. They especially don’t like to hear that they’re mediocre, not special, or less worth, which is the undertone of Ben’s 80% category.
During my military service I learned that statistically, only two soldiers in a group of eight would be effective in a combat situation. The rest would be pinned down, unable to return fire. Thus, one could say that the firepower of a squad comes from a fraction of it’s soldiers. I think this is often true for development teams as well. A few members are accountable for a majority of the produced value.
The funny thing is, that some of the best value-bringers I’ve met in my career does not fit the 20% alpha-geek group defined by Ben. And many of the “elite” programmers, the ones that do fit the description, have been remarkably inefficient. One reason for this could be that bleeding edge isn’t always the best strategy to achieve business value.
So, the question we should ask ourselves is not whether we’re in the 20%, it’s: Do I add to the firepower of my team? What can I do to bring more value?
Ben’s 80-20 generalization is just that: a generalization. Sure, there are programmers who know their company’s software inside out, and can add three new features during a their coffee break, but only develop software when they’re being paid, and only with the tools provided. There are also brilliant programmers who are too caught up in the bleeding edge technology that they don’t manage to invest any energy in actually getting things done (rather than finding new ways to do it), and end up being thoroughly inefficient.
However, the generalization does hold overall: by and large, the best programmers will also be sufficiently interested in programming that they spend time out of work doing it, and contribute to open-source projects.
I wholeheartedly agree with your final comment, though: if we’re working on a project (whether or not we’re part of a team), it’s important to focus on things that make progress towards the goals of the project, rather than just focusing on what we find interesting.
Absolutely, but it depends a little on how you define “best”. If you mean “most skilled”, I agree. But if you mean “most productive” (from an employers point of view), then I’d say the generalization may or may not be true.
I think if you redefined it a bit to leaders and followers, it would be easier. Most programmers I know are a bit of each, and often that changes with age and whatever else is happening in their life. Sometimes I’m the first in, sometimes I wait, it often depends on how tired I am of banging my head against the brick wall of new technology.
The best programmers I know all share a common characteristic: they want to build things. They are driven deep inside by the need to create pieces of software. Not all of them ‘care’ about the technology or the vendor, instead they focus on what they want to create. Assembler, C, C++, Java, Cobol, RPG, APL, Lisp, etc. they are all just different means to the same ends. They all basically allow you to offer functionality to the user to manipulate data. Just because someone has a preference for some flashier bit of pain, doesn’t make them any better or more sophisticated (in fact one might actually draw the opposite conclusion :-). It’s all about the building.
It is the power and flexibility to create new tools or extend the existing ones that is important. If the capabilities are there, the actual technology is just a minor issue.
Paul.
Good points.
I too am mood-driven and sometimes on bleeding edge, sometimes in mainstream and sometimes legacy. It’s equally fun as long as I’m getting somewhere, but I need to change tasks regularly to stay efficient.