Aleksander Demko,
November, 2016
Lately I was listening to a podcast (Coder Radio, by Jupiter Broadcasting) where one of the hosts declared that they don't believe that "10x" programmers exist.
I'm going to add my own thoughts to the topic and hopefully convince you that such special snow flakes exist. Some of my arguments build upon the ideas presented by Yevgeniy Brikman and although I don't like to quote Steve Jobs, he also agreed when he said "the difference between the average software developer and the best is 50:1; Maybe even 100:1".
"10x" programmers are simply programmers that are really good at the craft of programming such that their total output or productivity can often be 10 times more than an average worker. Although this sounds ludicrous at first - how can one human equal 10 others? - there is precedence in other fields. For example, rock stars or star athletes often single handedly carry entire teams.
For programming, these output amplifications can be had because programming is a creative job and not a manual labour one. The 10x gains do not come through speeds in labour or typing, but rather through cleverness and efficiency. Programming is fundamentally a job in managing complex machines of logic, where bad choices and mistakes can multiply and compound into giant cesspools of unproductive work.
The original concept came from an old research paper. I won't go into or debate the details of that work here. Trying to objectively measure such things is near impossible, so all that we're left to work with is piles of personal stories and patterns that seem to constantly reoccur.
Here are some of the techniques that I believe a 10x programmer uses to achieve these performance gains:
Most software projects tend to be over or under-engineered.
Over-engineering occurs through the overuse of UML, abstractions, OOP hierarchies, language features, run time options, plug in architectures and giant frameworks. These can easily burden a project with more infrastructure than it needs. Maintenance and basic additions become a sluggish nightmare as all that code must be constantly relearned and visited. All this extra code is technical debt as it adds no value to the application.
Similarly, under-engineering can leave a bunch of one-off projects who have no code reuse (except through cut and pasting) leaving each new project to start from scratch. Fixes require going back and manually updating all the original copies. Technical assets are never built and all that cut and pasted code becomes difficult to maintain in the future.
A 10x programmer does the perfect amount. The code that is written often minimalist: small, modular and easy to understand while getting the job done. The key is modular and minimalist. Less code is always the best code. Given two interfaces, implementations or ideas, you generally always want to the smaller of the two as that means less code to understand, change and maintain.
A 10x programmer is aware of all the external libraries and dependencies that can be used to help their project along. It's a waste of time to reinvent the wheel, especially when there is a good project that already does the job. Reusing such a library will give your project a productivity boost, letting you focus on your valued added portions.
A 10x programmer will also realize which things you should implement yourself, as a library may be an ill fit, immature, expensive, poorly licensed or not multi-platform. Some dependencies take more time to learn or modify that it would be to write a custom solution from scratch. A bad dependency choice becomes a maintenance project unto itself as it becomes permanently wed to your project, limiting future directions and development while soaking up developer hours.
Through total, end-to-end and in depth knowledge of the application and its use cases, a 10x programmer can pick the perfect amount of libraries and dependencies allowing for maximum benefits with minimal risk.
Although this sounds simple, it's really not. Most programmers simply think bugs are a part of software development and simply shrug their shoulders when a bug is discovered.
A 10x programmer views bugs as a learning lesson and thinks about how they can never repeat it and ideally, eliminate the entire class of bugs outright. Bug defense strategies come from design patterns, language features, testing patterns and discipline. Traps will be set in the program to catch bugs as soon as possible ("fail fast") before they become subtle bugs that can take days or weeks to reproduce or fix. A 10x programmer will preemptively re-factor code to reduce future bugs and complexities, recognizing and paying down the technical debt before it comes unmanageable.
Time spent fixing bugs is completely unproductive and a sign of waste. Bugs should be prevented or detected early, as they can easily soak up developer time and productivity.
In many organizations the bug fixers are looked on as heroes. The root cause of these bugs is almost never examined, the fix is all that matters. In many cases, the heroes themselves are the cause, so rewarding them would be like rewarding an arsonist for putting out his own fires. However, the 10x programmers simply don't create that many bugs to begin with. Reward instead the developers that create less bugs. This might seem hard at first - after all, how can you measure the lack of something. However, if you just look at the types of bugs reported and who's code created them, patterns should become evident. You just have to look. The amount of time a bug takes to fix should also be considered. Cosmetic and fail-fast bugs tend to be easy to fix.
When a 10x does have to debug an issue, they do with fast and cold logic, immediately eliminating issues and not falsely ruling out others. Many days can be wasted examining the wrong parts of an application.
Software development is fundamentally about building applications that automate tasks. Ironically, many developers don't apply the same process to their own tasks and end up wasting time doing menial and repetitive tasks. The time wasted can be significant, often taking up large fractions of people's day to day activities.
10x programmers immediately recognize such tasks as repetitive and automate them as soon as its worthwhile to do so. Composable command line tools are preferred to slow GUI ones. Scripts are written to automate development, testing and deployment tasks. Recognizing which tools can make source code management and bug tracking more efficient. Unit testing can reduce QA cycles. Custom applications or scripts can automate many tasks. Generated source code can reduce errors. Using advanced editors along with their scripting systems can greatly amplify refactoring and editing tasks.
10x programmers tend to bring with them to the job an extensive knowledge of programming languages, algorithms, operating systems and software tools. They might know how to build compilers, graphics engines, network protocols, and complex threading systems. They do this by following the state of the art via blogs, books and pod casts. They're driven primarily by a natural curiosity. It doesn't take a lot of time to do this, but since regular programmers spend no time on this (and thus 'stand still'), the 10x programmer is able to build and maintain a large 'knowledge' lead. Regular programmers don't read blog posts like this one, for example.
While regular programmers demand expensive and questionably useful training classes just to maintain their limited fields of knowledge, the 10x programmers, through self motivation and efficient use of spare time are providing the company with free R&D.
The 10x programmer draws upon this external experience when looking at large problems or new application designs. They might come up with solutions that are drastically more efficient or cost effective that anything that the company has ever used. To the normal programmers, it looks like the 10x programmer is an all knowing wizard as he pulls out concepts and ideas that they have never heard off. They're often very skeptical. The 10x programmer thinks it's all just basic stuff that everyone should know.
Young programmers are particular susceptible to this. They'll often ignore the advice of a 10x developer and constantly repeat the same mistakes and lessons, all on company time.
Experienced non-10x programmers can also be dangerous. Simply surviving in this field for a few decades can build a sense ego even if the developer has simply done the same jobs (and same mistakes) the whole time. Convincing these developers to change their process or tooling is incredibly difficult, if not impossible.
Finally, the 10x is just typically smarter and more clever than the normal programmer. They love math. They've found school assignments easy. Programming concepts always seems easy and natural.
They're able to see the essence of a software project, from the higher level functional view all the way down to its hardware implementation. This allows them to build simpler, faster and more scalable solutions. They understand algorithms, and the compounding effects of what bad choices can make for performance. They can build more with less, giving your applications more performance headroom and generally happier customers.
10x programmers are hard to find, and its impossible to fill your company with them. They tend to be seem frustrated or arrogant, as they're surrounded by normal programmers who seem (to them) to make silly, wasteful mistakes. However, if you do have on, appreciate him and do utilize his skills.
Sadly, most managers don't even know about the existence of 10x programmers, never mind be able to recognize them. Managers also tend to be insecure, and can't image that a programmer under them could do a better job than them. They're completely ignorant of the benefits of 10x programmers and think that all software development is hard, programmers are interchangeable and that project problems are the norm.
Sadly, your manager is probably one of these.