10x programmers are a hot topic to discuss in the software industry nowadays, so thought it'd be a good idea to share my view point in this regard.
Honestly I don’t know the exact definition of a 10x programmer, but I assume it refers to hyper productive programmers (which may not map to exactly 10 times productivity, but to a significant level near or more than 10 times).
Based on few successes I had while delivering ultra-big pieces of software for startups and corporations, and working experience with a few top-notch developers, I can share some insights about this topic.
The 10x Programmer Then
Software developed 20–30 years ago was much simpler compared to modern software, with respect to functionality, security, performance, and scalability. On the other hand, only a handful of libraries or frameworks were available at that time to implement any functionalities.
Thus, software written 20–30 years ago involved a significant amount of effort in programming.
Defining a 10x programmer in that context is comparatively easy. The difference between the amount of core programming effort given to implement the same set of functionalities by 10x and regular programmers.
The 10x Engineer Now
Before going into additional details, lets make one thing clear: software development is a complex process, and programming is just one of the areas to contribute to modern software.
Because of increased usage of software, especially over the Internet, by both consumers and organizations, software is very complex, and it might be an insane decision to build something from scratch. Honestly, unless it's a completely a new platform or operating system, the core programming required to develop modern software is less intense compare to older efforts.
While programming knowledge and effort is still very important, the amount of effort that is required to build great software (bug free, secure, and salable) is in engineering.
So on today’s context, a 10x programmer may not bring much value in the industry, but a 10x engineer creates a very wide impact in the development process.
I’d like to add my 3 cents here.
1. They Make the Best Usage of Tooling
Software development is a complex process, which involves a lot of different kinds of effort. Besides coding, it involves efforts from documenting process, to formatting data, from reading log data, to sending reports, from automatically testing, to manually testing, from complex debugging, to manually investigating issues, and so on and so forth.
A huge effort can be made extremely efficient by using the right set of tools and platforms (that are appropriate to a client's budget and other constraints).
Editors
Writing software involves one or more editors, some of which also referred as IDE (Integrated Development Environment). Modern IDEs, such as Visual Studio or Eclipse, offer a great amount of functionality to make developers productive, but a significant amount of these features are not known by most developers.
Popular IDE’s also have commercial and free plugins (such as Resharper), which enable even more developer productivity.
Besides IDE’s, other editors such as NotePad++, MarkdownPad, etc. are also very useful in a relevant context.
Utilities and Online Services
Utilities and online services such as reading or searching large log files, http debuggers like Fiddler, build and deployment tools, etc.
Own Tools
10x engineers also make their own sets of tools to perform repetitive actions for which the appropriate software may not be available externally.
In lots of cases, business owners in a software development house don’t seem to be interested in investing much on tooling for developers, but using the right set of tooling will enable a surprising amount of productivity.
For software developers, who are some of the most expensive people to hire, spending money on right tooling for them is worth doing.
As a .net developer team lead, developing a ASP.NET Core & Visual Studio starter template following latest .net coding practices helped my team boosting up overall productivity three times.
2. They Don’t Reinvent the Wheel
The software industry has become very mature in the last three decades. Almost every problem that developers are trying to solve by coding has been solved and are available as APIs (either as binary or web services), some of which are commercial, while others are free.
Besides, open source frameworks also provide great flexibility to understand underlying API behavior or customization as needed by the users.
Before jumping into programming, 10x engineers actually make sure this problem has not been solved fully (or partially) before or, if so, they are not available to be used.
3. They (Continuously) Write Beautifully Engineered Code
Writing great software requires defining a good architecture that not only follows good design patterns and principles, but also takes advantage of modern infrastructures. Producing well-engineered code not only enables writing new functionalities faster, but also reduces bugs significantly.
But, beautiful engineering requires continuous improvement.
I’ve seen a surprising amount of low quality code in different software projects in my professional career, which continuously adds technical debt. A simple project that started 5 years ago is full of non-engineered ugly code and requires 20+ people to handle the development cycle (where they are spending 80% of their time actually fixing bugs).
One of the main reasons behind this awful situation, I found, is “fear”.
Organizations, especially enterprise entities, mostly fear change.
Software development is an incredibly fast-changing discipline in terms of tooling, frameworks, and engineering, and requires continuous change to get to the right place.
Change is frightening, but it's not as dangerous as it sounds, especially in the software industry (with the right sets of tooling and people). But if it is not done as expected, it will not take much time for the project to be abandoned entirely some day.
Top comments (11)
"10x" wasn't originally an engineering term, but a business term.
The term is bullshit and you shouldn't be using it or trying to identify with it. If you do, you're just trying to make yourself look better than you are by gatekeeping perspective.
It was:
To be perceived as a "10x" dev, ditch all of your preconceptions/prejudices/engineering habits and focus solely, and almost mindlessly, on the immediate business goal that affects the bottom-line.
Result in the commercial world is money and how efficiently you can get it, that's it. Not how good of a person you are, not performance, not scalability, not technologies or frameworks, not engineering.
Business doesn't care that they're spending €1k/mo on server costs while it could be only €50/mo because the original dev didn't "engineer it properly", because they can earn more money bringing on new clients.
(Until the point where the # of incoming clients is so high that they've reached a growth spurt and the scaling needs some % improvement to keep up.)
It's about investing yourself and putting yourself on the line to make results happen. Step out of the bounds of what you're taught as an engineer and stop trying to be just an employee. (Though at that point I'd personally recommend taking full responsibility and starting your own business.)
I don't really like the prefix of '10x' on anything, it's a (silly) business term that's now filtered its way through into our domain.
Firstly, I think that people should avoid any attempt to quantify their value over others, because what you offer is not some magical linear spectrum based on one single capability.
There's also a real hint of narcissism about it. Most tech places will have a structure in place, which will have senior/principal prefixes before roles. These gives a rough indication of seniority. This seems infinitely preferable, because it is representative of their abilities and experience rather than being a dogmatic self-assertion of some sort of quantifiable exponential value over others. You can be a prodigy programmer within a company, but to refer to yourself as a 10x programmer is still just a bit overly-confident and a bit silly.
Companies shouldn't condone the use of the phrase, either, and should stop using it in jobs specs.
I don't think coding ability alone defines a 10x programmer. In my experience they've been people that excel in a lot of other abilities, especially in soft skills, such as negotiating and planning.
The high productivity isn't about getting lots of code, but about getting the right code as well, and there's no way to do that without having good skills in all areas of programming, not just coding.
I talk about these other skills in my book What is Programming
nice post. and I agree with this comment too.
coding ability is just one part of being a very good engineer ( if he/she is 2x 5x or 10x who cares). of course, they make the foundation for it but as I also wrote in What makes a 10X developer the multiplying factors are others ( which as you said go more under the soft skills and being able to do the right things in the right way).
I understand that people get irritated by these marketing / recruiting buzzwords, but I don't get why they get so upset and can't just focus on the positive aspects of this "label" and use it for self-growth.
I imagine the people who string tons of frameworks, extensions, javascript doodads, and other forms of other people's code ( OPC ) would be considered 10x programmers.
Very productive, yet you end up with hollow bloatware that can't be maintained in the future..
I'd rather get into another profession if this became a standard way of thinking.. although it kinda already is!
That is not being productive. A productive developer is the one that generates good code, understanding good code as the one that is maintainable and extensible with ease, in a quickly fashion while giving and getting feedback from the other departments.
To be very frank, crude, and also "In my honest opinion" only (so add lots of salt)
There are a lot of programmers who are really bad. Like 10x or even 100x bad.
So as most pointed out, it ended up as a business term in larger companies. Especially nonengineering companies, who could not know better regarding programming.
Because due to their sheer hiring size - a good chunk of their developers ends up being really bad, or worse, being busy with politics rather than actual work.
So whenever a good programmer, is willing to ditch the political nonsense. Put his job on the line and risk. And get things done...
Suddenly from the average perspective in that company: he is truly 10x (Assuming he succeeded, if he didn't, he would be fired)
I personally witnessed many times as a vendor working for such big companies. Which is interesting to say per least, cause being in an engineering-focused company. We would not consider such individuals 10x. But I guess 2, or 3x technically? I have no idea how to quantify this.
So in that sense, they were 10x not because they were extremely great. But because the average was really bad. And they have the courage to stand up to it.
Also to be clear: For those in such a situation, and made it through. They automatically earn my mark of respect. Cause I will emphasize. It takes real courage to get things done in such an environment. And in development work, cutting through the crap and communication is a good half of the battle.
Personally, I would not stand for it. And send in my resignation letter for a real engineering company... or in my case form my own engineering company.
I really like the idea of 1% improvement. When you gradually tweak your skills and becoming better. For me the tipping point was wathching vlogs. Then I started to pick up some cool new habits here and there.
I do remember a video from @mpj where he was coding an offline Pomodoro Button. That hit me :)
I've recently shared my experice on dev.to:
How Failing With Pomodoro Technique Made Me 2x Better Programmer
Also I do believe into becoming 10x programmer. But where «x» is referred to yourself years ago.
And. Speaking for myself. What was NOT healthy for me — was comparing myself to «10x developers» (from a marketing point of view).
It made me worry and put some invisible pressure on me.
Nice article. I particularly like the distinction you draw between a programmer and an engineer.
My two cents to your three: big picture awareness and OCD-like strive for improvement (micromanaging the right things if it had to be one).