The real 10x developer

10x developer is defined as the developer that is 10 times more productive than the average developer. Whether these developers exist is a matter of debate. Usually, people will tell you that 10x developers don’t exist. Most of them are trying to tell you what this article will try to explain.

10x programmers, or even 100x programmers, do, in fact, exist. But real 10x programmers are not the ones who “can perform a task 10 times faster than the average programmer”. Don’t get me wrong, there are people who can implement something extremely quickly, much faster than the average programmer. Does that, however, make these individuals 10x more valuable? I would argue not. And most of the time, those individuals do more harm than good. Real gains in software development are usually not measured in implementation times, but in future maintenance man-hours. The right person in the right position can save tens of thousands of man-hours for a company, essentially being 10x or 100x more valuable than others. Software engineering, because of its chaotic nature, really allows for such large gains, or losses, when practiced in the wrong way. Small mistakes have a tendency to pile up in huge technical dept over time.

So, why is completing a task very fast harmful? Writing solid software is hard. Systems are usually chaotic; maintenance is very hard, and there are a lot of pitfalls. Good programmers know this. When a programmer makes something work as described, he/she has finished about a third of the job. Then comes the hard part. That is, hold the task, until you are certain that you can answer yes to the following questions:

1. Is the task completely finished?
2. If I deploy this, am I reasonably sure that I didn’t break anything else?
3. Is the way I implemented the feature easy to maintain or change in the future?
4. Does my solution scale reasonably well?
5. Does my implementation deviate from the existing architecture?

Managers, salesmen and rookie “10x programmers” only care about the first question. Real 10xers know that the only constant is change. Somebody will ask you to change or add to the existing feature. Your first priority must be to make your future self’s life easier. That means a few things:

• Writing unit/system/integration tests. Contrary the widespread misconception that tests are for testing your features, this is not true. Tests are used mostly for regression. You create tests so that you can answer the question: “What did I break implementing this?”
• Do not deviate from the system’s architecture. Kent Beck said, “For each desired change, make the change easy (warning: this may be hard), then make the easy change.” If you see that, to support the new feature, you have many special cases, multiple ifs, forks in logic in various places; that means that you have to re-evaluate your architecture. Break things down, refactor, make the feature feel natural and easy on your framework, then actually re-implement it. Something really hard to pull off when you don’t have any tests to begin with.
• Do the math, do some tests. Does this SQL query scale? What will happen when we are in production and we have several million lines in x and y table? Often “easy”, straightforward solutions do not scale well. Do I need to create indexes, or secondary data structures, to efficiently support my queries? If you have to re-implement everything in six months and on top, migrate the old data, you are not very valuable, are you?
• Write clean and simple code. If you have trouble while developing the feature, when everything is fresh in your brain, imagine maintaining it in two years.

Thinking like this will certainly make your development slower. Development of the feature will most likely take two or three times longer, if implemented correctly. But if everything goes well, you won’t have to touch it again, and modifying it will be a lot faster and more straightforward. On the other hand, a hastily implemented piece of code can lead to thousands of hours of future maintenance, QA testing, server crashes, debugging, etc.

What is making things even worse is that managers, unless they come from a technical background of a sufficient level, cannot understand what all the fuss is about. They will pressure good programmers that take longer to implement features but deliver good code, and they will praise the ignorant programmer, who delivers quickly, for their “work ethic”, especially when they will rush to fix the myriad of inevitable production errors that will occur, mostly because the feature was not implemented correctly in the first place. Technical dept is not only a thing, but if not kept in check, can destroy a company. This is the first thing I look for when considering a new job. Will my boss understand when I explain a technical issue to him/her?

And all of the above are what you achieve as a developer, in the scope of a simple task. People in better positions, like Tech leads and other positions that have more influence on the company, can use the same principles to simplify procedures with code and automated systems that will be extremely beneficial in the future. Think differently, outside the box. You can eliminate entire classes of bugs by enforcing a specific architecture. If the rise of Devops taught us a lesson, it is that you can free the hands of many people that are forced doing trivial and boring tasks and avoid human errors by writing code and using tools to automatic a procedure. Many times, the only thing you have to do is just sit down and think what you can do to improve your situation and not take things for granted. That is why I think that most hackathons, programming challenges and “how do you know this or that” interview questions are pointless. They do not show the true qualities that define a good software engineer.

The Ultimate example of a truly valuable coder is Misko Hevery, the co-creator of AngularJs. Essentially, he and Adam Abrons invented AngularJS, and Hevery rewrote the Google feedback application in just 1500 lines of code, as opposed to the original, which was close to 17.000. These guys not https://twitter.com/newsycombinator/status/1266474792045154304only created AngularJs and Angular, they first introduced the principles that all the modern Javascript frameworks rely on. Before, Angular front-end development was a tedious and difficult job. By introducing Angular, they showed everybody that, even though we didn’t realize it for many years, there is an easier way of doing things. They believed that there was a better way to do things, and they proceeded to invent it. Imagine the millions of man-hours these guys saved for all front-end engineers worldwide.

And that, for me, is the true definition of a hacker:

Most people see what is, hackers see what can be.