A star is born
The concept of the ten-times developer didn’t originate in software development. For anyone involved in engineering or science, the concept will also be familiar. It was familiar to my Father’s generation before software development was generally a thing. I’d suggest it’s also recognised in the arts. There are certain contributors whose input to a genre or style are prolific in the extreme.
How can such a person exist? How can it be possible that one person can do the work of ten without apparently breaking a sweat? Of course, there are examples of those who work every hour of every day, but that doesn’t account for a tenfold increase in output.
Hard work alone would only account for around a doubling of output, and that’s assuming the same level of activity can be maintained without impacting the long term health of the individual. This phenomenon, if it exists at all, is not about the hours worked. It’s about output per hour. So, ten-times seems unlikely, if not possible, doesn’t it?
Well, to be frank, ten-times is just a start. In my opinion, the productivity gains can be even greater, so if it’s real, then it’s definitely worth knowing about.
There can be only one
Those who do believe in the ten-times developer will talk of the “genius” with a “brain the size of a planet” who thinks in ways mere mortals can ever imagine. They make the case that this person is as rare as the famous rocking horse byproduct, and you can’t base a delivery model on their existence.
I suggest otherwise.
For me, the ten-times developer is smart, but no genius. After all, we’re all smart in our own way. The ten-times developer is smart in the ways of software development, but not in a rare way. Plenty of people are very talented when it comes to solving problems with software. So if it’s not just about being smart, what does this person have that makes the difference?
What they have is experience, wide and deep. They are both generalists and specialists. They understand a wide range of topics, so understanding a problem comes easy to them. They have deep experience in software and algorithm development so crafting software imposes a low cognitive load.
They’ve been there and done that, so they know all the things that won’t work, and can go quickly to the things that will. When you bring all these factors together, it means that they get the work done quickly. But that’s not where the ten-times bit really comes from.
If a job’s worth doing…
The ten-times bit comes from their ability to get it right first time.
Firstly, there’s the ability to solve the problem at the first attempt. All that hands-on experience means their knowledge has been tried and tested in real situations. What is more, those situations have been many and varied. This means they understand when an approach will be the answer, and when it will simply be another problem.
Secondly, they’ve practised time and time again. The problem solving process now comes easily to them, as the hitting of a ball comes easily to the experienced tennis player. The mechanical task of programming imposes a low cognitive load, so thinking is clearer and mistakes are far less likely.
The tennis player can consider tactics, observe the opponent, and be unfazed by distractions. They have the capacity to absorb all of that, and still have plenty left over for the shot itself. Similarly, the developer can comfortably cope with complex concepts, context switching, and problem solving. These things don’t sap their mental reserves, and so they have plenty left to focus on crafting performant, bug free code.
Thirdly, experience has taught them to use techniques that ensure the code works well first time. Manageable modular structure, clear layout and design and a rigorous testing approach all help the ten-times developer to keep the cognitive load low. As each part is completed, full attention can be given to the next. Existing code can be revisited and quickly understood. Confusion is kept to a minimum, as is uncertainty. If something does go wrong, it’s almost certainly in the latest piece of code, as trust has been built up in what came before. Building on solid foundations creates stable structures.
And this is where the ten-times really comes in. It’s quite possible that when placed side by side, the ten-times developer will at first seem to be only slightly faster than the one times developer. Maybe they’re as much as twice as fast, but it’s unlikely. However, that’s not when the clock stops.
When “done” is just the beginning
To really understand the gain, you have to look at what happens next. It soon becomes clear that the ten-times developer is not going faster as such. It is more a case that they create no ripples. There are no negative consequences. So what are the consequences that might be avoided by such a person?
Bug ridden code
Best case scenario is that this means it goes round a test, fix and retest cycle until all those bugs are gone. This takes time. Worst case scenario is that it goes live and takes down the system. Now the whole team could find themselves tied up in finding the issue and fixing it. Worse still, the bug is now embedded in a much bigger code base, and tracking it down will inevitably take more time.
Incomplete solutions
Although the solution seems to work in the simplest of situations, it quickly becomes clear that anything more complex has not been addressed. The world is a complex place, and so the solution fails more often than it succeeds. This requires rework, and rework takes time.
Inadequate performance
Inexperience often means that although a solution is found, it’s far from efficient. This isn’t always an immediate issue, but as things scale up these inefficiencies accumulate until the solution becomes so unwieldy that it’s unusable. Now you have a real problem. As with the bugs, those performance issues are buried deep in the system, and it’s hard to work out which parts are wasteful and which are as performant as can be expected. Once again, we’re into the world of time consuming rework.
Obscure code
All of this is exacerbated by poorly structured code, lack of meaningful comments and explanation, and confusing coding practices. These are all things that a highly experienced developer avoids. They code as much for the next person as for themselves. They give careful consideration to making sure what they create is easy to understand and maintain. After all, they’re aware that the next person could well be them. Obscure code is hard to get to grips with, and tricky to change, so the time incurred by each of the previous problems is further multiplied.
Clear roads ahead!
All this adds up to a lot of additional time and effort. Typically, in a responsible team this effort falls back on the original developer who created the problem. They become less productive as a result, and their habits mean that even the rework needs to be reworked. Over time, these issues build up like the snow in front of a snow plough. If it isn’t cleared out of the way, eventually everything grinds to a halt.
And that’s why a ten-times developer is ten-times as productive. Their approach means they can quickly move on to the next thing, not just once, but time after time. There is no snow plough effect. It’s also why I’d suggest that ten-times productivity is only the start.
So, if you want real velocity towards a goal, not just speed without progress, look for experience. Experience will get you over the bumps in the road, and through the barriers. Of course, there are times when the work is straightforward, and the problems easy to solve. Those are great times for the inexperienced to learn and grow, but when the going gets tough, a very small number of experts can make all the difference.
And, best of all, those ten-times developers have spare capacity. If you pick the right ones, they’ll mentor and guide, and before you know it, everyone’s a ten-times developer.