Guest Blog: The mythical 10x programmer by Antirez

In the mythology of programming, a 10x programmer is a programmer that can do ten times the work of another typical programmer. The programming community is exceptionally polarized about the existence or not of such a beast. However, many people told me that they believe I’m a very fast programmer. Considering I’m far from being a workaholic, I have put together a list of qualities that I believe make the most difference in programmers’ productivity.

Bare programming abilities

One of the most self-evident limits or strengths of a programmer is the skill to effectively implementing the basic parts of a program: a function, an algorithm, or whatever. Surprisingly the ability to use basic imperative programming constructs very efficiently to implement something is, in my experience, not as widespread as one may think. I observed experienced yet uneducated programmers getting more work done than graduate programmers, in theory extremely competent, but very poor at implementing solutions.

Focus

The number of hours spent writing code is irrelevant without looking at the quality of the time. External and internal factors can cause a lack of focus. Internal factors cause procrastination. They can be things like lack of interest in the project at hand (you can’t be good at doing things you do not love), lack of exercise or well-being, and poor or little sleeping. External factors are frequent meetings, work environments without actual offices, coworkers interrupting often, etcetera. It seems natural that trying to improve focus and to reduce interruptions is going to have a significant effect on programming productivity. Sometimes to gain focus, extreme measures are needed. For instance, I only read emails from time to time and do not reply to most of them.

Design sacrifice

Often complexity is generated when a non-fundamental goal of a project is accounting for a considerable amount of design complexity. In other cases, there is a design tension between a fundamental feature and a non-fundamental one, and this is making the more important goal very hard to reach. A designer needs to recognize the parts of a design that are not easy wins or where there is no proportionality between the effort and the advantages. To execute a project maximizing the output, one needs to focus precisely on the aspects that matter, and that they can implement in a reasonable amount of time. When designing the Disque message broker, I realized that by providing only best-effort ordering for the messages, I could substantially improve all the other aspects of the project: availability, query language, and client interaction, simplicity, and performance.

Simplicity

Simplicity is an obvious point that means all and nothing. It is worth to check how we often generate complexity to understand what simplicity is. I believe that the two main drivers of complexity are the unwillingness to perform design sacrifices and the accumulation of errors in the design activity.

If you think of the design process, each time we pursue a wrong path, we get farther and farther from the optimal solution. An initial design error, in the wrong hands, is not corrected with a re-design of the same system. It leads to the design of another complex solution to cope with the initial error. The project, thus, becomes more complex and less efficient at every wrong step.

We can achieve simplicity by thinking in terms of small mental “proofs of concept” so that we can explore a large number of simple designs with our minds. This technique allows us to start working from something that looks like the most viable and direct solution. Later, experience and personal design abilities allow us to improve the design and find sensible solutions for the sub-design issues that we need to resolve.

However, each time a complex solution seems to be warranted, it’s essential to think deeply about how to avoid this complexity. Only continue in that direction as the last resort, even considering completely different design alternatives.

Perfectionism

Perfectionism comes in two variants: an engineering culture of reaching the best possible measurable performance in a program, and a personality trait. In both instances, I see this as one of the most significant barriers for a programmer to deliver things fast. Perfectionism and fear of external judgment bias us to refine a design only according to psychological or trivially measurable parameters. Instead, we tend to forget things like robustness, simplicity, ability to deliver in time.

Knowledge

When dealing with complex tasks, knowledge of data structures, fundamental limits of computation, non-trivial algorithms is going to have an impact on the ability to find a suitable design. It is not necessary to be a super expert in everything. Still, it is essential to be at least aware of a multitude of potential solutions for a problem. For example, it is possible to use algorithms which are very efficient at counting unique items in a stream, if we can accept some error percentage. Not everyone is familiar with them.

Low-level understanding of the machine

Many issues in programs, even when using high-level languages, arise from the misunderstanding of how the computer is going to perform a given task. Sometimes, this may lead to re-designing and re-implementing a tool from scratch because there is a fundamental problem in the tools or algorithms used. High competence in C, understanding of how CPUs work, and knowledge of how the kernel and system calls are implemented, can be essential in preventing bad, late-stage surprises.

Debugging skills

It is surprisingly easy to spend an enormous amount of effort to find bugs. Being able to focus on a bug incrementally and to fix it with a rational set of steps, together with having to deal with simple code that is unlikely to contain too many bugs, can have a significant effect on the programmer's efficiency.

In conclusion, it is not surprising to me to see how the above qualities of a programmer can have a 10x impact on the output. Combined, they allow for proper implementations of designs that start from a viable model and can be several times simpler than alternatives. There is a way to stress simplicity that I like to call “opportunistic programming.” Basically, at every development step, the set of features to implement is chosen to have the maximum impact on the user base of the program, with the minimum requirement of efforts.