Ending the myth of the 10x, 100x, SuperStar programmer — quants
Part I of a 2-part article about the mythical SuperStar programmer, the effect on teams and why it doesn’t really exist. To find out the non-quantifiable reason why, read Part II here
Roaming around the software community is an elusive yet apparently highly worthy beast: the 10x programmer.
Sometimes called by other names, the main quality of this mysterious and elusive beast is its apparently incredible productivity compared to other programmers.
So without further ado and with all the bravado I can muster: I officially call bullsh*t.
Let’s first look at the ‘quantitative’ part: the 10x, 100x, 1Gx…
Productivity: the mechanistic view
At some point, some time in the beginning of last century, the concept of productivity was born.
After many Ford-isms and some Keynes-isms, a standard definition matured: productivity is the direct ratio between amount of work and time spent producing said work.
Prod = Aw / Tw
By this simple definition, a 100x developer would be either doing 100 times as much work (Aw * 100) or the same work a 100 times less (Tw / 100)
For a project that would take a ‘normal’ (does that even exist?) programmer: 100 units of work in 100 units of time, our SuperStar would be either producing this 100 units of work in 1 unit of time, or the reverse.
Here is the problem I’ve got with this: a programmer’s ‘unit of work’ and ‘unit of time’ are never constant in my experience.
Where do I come up with such a certainty, you ask?
Before I go throwing book and study references at you, let’s get a little empirical with my own experiences both as a programmer and as a manager of programmers.
An organic disciplined exercise of mind: getting in the zone
When I’m coding, I spend at least one third of the time ‘warming up’. If you’ve ever been serious about programming, you know that existing in all of us is a fuzzy, sharped-focused, external-sensations-dimming, quasi-hypnotic state, we software makers, call the ‘Zone’.
Until I reach this tricky and slippery ‘Zone’, where I comfortably sit in my most productive apex, I spend my time preparing for it:
• Making sure my version control is updated
• Thinking about names — variables, classes, functions, interfaces,… so many names!
• The division of labour between my components and communication between them — an interface? a shared object? a callback? RPC? a message queue? HTTP? pigeons? smoke signals… give me a sign!?
• Information exposure — local, as a class property, private, public, static,…choices, choices, always choices
• My library dependencies, information dependency
• My parameters parsing, error handling, possible injections
• My continuous integration flow, delivery gates, integration tests, system tests, you have got to test Bruno!
At some point, like assembling a puzzle made up of thousands of micro decision sharp edges — because a good chunk of them always bite you later… — I enter the infamous twilight Zone.
OK maybe, it’s not always twilight and unicorns, mostly a lot of code.
The important part being that, for me, I can never predict when and why I enter that state. It takes not only a random set of actions or ‘workout’ routine, but also a very specific environment.
Legend is, J.K. Rowling needed a noisy, social interactions-filled coffee place to write the Harry Potter novels [internet legend has it that, in the end, she had to use a disguise to avoid being recognized in order to write the last ones…]. It is also well-known that Albert Einstein — when you cite people, let’s go for the greatest, right? — couldn’t really be efficient without interrupting long stretches of work with playing the violin.
Me? I’m all about an absence of social interaction, silence or music with no singing, and tea. Yup, I’m a bit of an autistic.
That is why I strongly believe that every individual knowledge worker (including programmers) has a set of changing, complex, environment-dependent and routine activities that are necessary to trigger peak productivity. If the individual had less sleep the night before, ate too many bagels or had to spend 20 minutes more than usual in traffic, peak productivity may never or partially be reached that day.
Quantifying productivity is too complex
Many studies, books and publications are confirming my biased opinion [1][2][3][4][5] that, for a knowledge worker, ‘amount of work’ and ‘amount of time’ are simply non-linear and most of the time quasi-chaotic.
Hence:
Prod = rand( Aw ) / rand ( Tw )
Corollary: nobody can establish a constant ratio of productivity based on two non-linear quasi-chaotic quantities (except if you could prove that they are in fact the same, and that would mean…OK, come on, do the math!)
Now, if we consider this as at least partially true, just imagine how complex a productivity function must be. Not only is it multi-dimensional and quasi-chaotic, but those dimensions are themselves mostly dependent on each others, or some day… they may not:
I ate too much bagel because I spent 20 minute more in my car due to entering traffic late after a sleep-deprived night…
…The next day may be my most productive ever.
How could anybody predict/model that?
Now, try to apply this multidimensional function to a group of people and add more dimensions: their interactions.
You may like one of your teammates one day, or be p*ssed because his/her preferred DOTA team beat yours yesterday. You may love your team one day because they told you how amazing you are…and then feel challenged the next day trying to reach their new expectations or even the perception you have of them.
And, of course, you would want all your people, ideally, to get to peak productivity AT THE SAME TIME.
Good luck with that!
Read Part II here, to explore the human ‘qualitative’ aspect of programming and what I think we should do better…
