0.1x or 10x, time matters
There is a lot of chatter in the industry about the notion of 10x programmers. People who can routinely be an order of magnitude faster than mere mortals. Okay, that was a bit snarky, I’ll admit.
I have had the pleasure to interact with a lot of developers, from people whose conversation I could barely follow (way above my level) and whose code I mined for insight and ideas to the the classic outsourcing developer who setup a conference call for assistance in writing “Hello World” to the console. I think that I have enough experience at this point to comment on the nature of developer productivity. More to the point, I know of quite a lot of way to destroy it.
The whole 10x developer mentality assume that a single (or very few) developers are actually able to make a major difference, and that is usually not the case. Let me try to explain why, and note that I assume a perfect world in which there no need to burn this 10x dev with all nighters and hero mode.
The problem is what we are talking about when we are talking about major difference. Usually, as developers, we can talk about making major technical changes. Let us consider the Windows Kernel Dispatcher Lock removal. That was 8 years ago and it is still something that pop to my mind when I consider big changes in the guts of software. This is something that is clearly beneficial, was quite complex to get right and require a lot of work. No idea if the people working on it were “10x” but I assume that the kernel team in Microsoft weren’t pulled from the lowest bidder by the Shady Outsourcing R Us.
What real difference did it make for Windows? Well, it became faster, which is great. But I think it is fair to say that most people never heard about it, and of those who did, fewer cared.
The things that really matter for a product are a solid technical base, and then all the rest of the stuff. This can be the user interface, the documentation, the getting started guide and even the “yes dear” installer. It is the whole experience that matters, and you’ll not typically find a who can do all of that significantly better than others.
One of the guys in the office is currently spending much more time writing the documentation and walkthrough for a feature than the time it took to actually write it. The problem with developers is that we tend to live in our own world and consider everything else that isn’t technical secondary.
But as good as the software is, the actual release to customers require a lot more work that isn’t even remotely technical, be it marketing materials, working with partners or just making sure that the purchase workflow actually work.
Comments
Good point, but 0.1x developers will never finish a product ready for marketing because they simply do not know what they are doing. The definition is not only about speed but also about knowledge and attitude.
Carsten, Bad people can slow things down, sure, but that assume that they are in the blocking path. If you have a non blocking thing that you can give them, that can free more valuable members to do more crucial work.
This is funny coming from a person that knows the terrible developers (because you have interviewed many) that are out there somewhere getting paid to write software so shitty it'd make you cry, and other other hand know of the really talented developers that get quality stuff done all the time
My understanding of being 10x is not doing all nighters as a lone cowboy, but instead enabling rest of the team to progress much faster.
Your kernel lock is a good example here. Having a team of highly effective core developers in kernel allows non-senior developers in apps to do awesome stuff. Without the 10x boost, their products would have suffered significantly.
Eber, You can assume that negative values people aren't here. I'm not talking about the kind of people who actually do damage.
Sukru, Yes, that is indeed the major factor of these 10x people. However, as in the kernel example, from technical perspective, it might be very impressive, but it didn't have a major affect on the _product_.
Comment preview