Hi, friends!
Have you ever experienced that? You hear a term for the first time that you hadn’t heard in your life before, and shortly after that you hear the same term again in a totally different context? Crazy coincidence or selective perception?
In the SE-Radio Episode with Jonathan Nithingale that I already blogged about, he mentions a “10-ex-developer” (phonetic). I figured he said “10x” like in “ten times” which should mean a really productive developer. But I wan’t sure, he could also have been talking about some kind of rank or whatever.
Today I read the blog article “The cloud skills shortage and the unemployed army of the certified“, and there is the “10x coder” again!
This time I had a PC in front of me (instead of the steering wheel of my car), so I googled the term immediatly. Unsurprisingly, the “10x” means basicly what we thought – a software developer who is ten times as productive as the worst (professional!) developers.
Now, this is funny, because it’s actually a well-known term; and I had once told my managers as my mid-term career goal “I want to be a developer five times as fast as anyone else and be paid accordingly”, without knowing that other people actually talk about something like this.
Also very interesting was to learn that there is a debate whether the 10x programmer exists, argueing whether the literal factor 10 is possible or not. I expected that “10” was an arbitrary number to figuratively say “way more productive”, what I meant when I said “five times”, but here they are discussing if “ten times more productive” is a thing.
The factor 10 is apparently the result of a study from the 1960s that found:
They studied professional programmers with an average of 7 years’ experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1; the ratio of debugging times over 25 to 1; of program size 5 to 1; and of program execution speed about 10 to 1 .
The data was later adapted and confirmed to be around 10x for the overall productivity.
It’s easy to refuse this and think a single programmer can never produce as much output as 10 other programmers in sum. This seems obvious when you have some kind of manual labor in mind, like a construction worker or a barber; I would believe, even the fastest of them cannot do as much work as ten of their colleagues together, because of physical constraints.
But software development is different, the physical activity is not the limiting factor of productivity.
Here is my own reasoning about this:
- In a typical software project, after some initial weeks the code base has grown enough that a developer is spending only 20% of his time on writing code and 80% on reading already existing code, in order to figure out who the existing stuff works, where to put in new code and what can be copied or reused and so on.
- A developer who writes clean code can read and understand his existing code much faster.
- A developer who understands and applies design patterns and good architecture can understand the existing structure and find the place where to add new code much faster.
- A developer who writes good automated regression tests will hardly break existing code while adding new stuff, which would lead to time consuming bug reports and debugging sessions. (I have seen tasks with 2 days of implementation work followed by 10 days of bug fixing…)
- A developer who comes up with a working solution for a problem fastly saves lots of time compared to a developer who doesn’t have a good idea in the beginning and stumbles from try to try until he finds a solution.
- A developer who fully understands the business requirements and has an instinct for questioning given requirements that are potentially incorrect, can save lots of effort of working in the wrong direction.
- A developer who is teaching and helping his colleagues to be faster and espacially less blocked, can leverage the productivity of his whole team.
If you have a hard time imagining how someone could do the same job ten times faster than someone else, think in the different direction: Imagine a developer who gets all those things right, and then ask yourself if it sounds reasonable that someone else would take ten times longer when he is not able to fullfill all of these properties?
A very nice article on the 10x programmer with different reasons, but a similar conclusion is this blog post by Nathan Epstein.
I like very much that he ranks the aspect of teaching and enabling as the second most important. And I really love the wording of his top reason, “Strong programmers can take ownership of projects”.
In the past I have sometimes thought about how to put in words why I think I am more productive than some of my coworkers (especially before salary negotiations, performance reviews and applications, you need to prepare to argue what you think you are worth!). Now I realized, this is what I unintentionally end up doing in all the projects I join: I take ownership by identifying the stakeholders needs, coming up with some options, get second opinions and align my team members to deliver a great outcome together.