Occasionally the term “10X developer” keeps on surfacing in blogs and social media. Some of the writings are sarcastic, but it’s not always the case. I became curious what is this “10X developer”. To me it sounded like a unicorn developer who is 10 times more efficient, creative and productive than average developer. This kind of stuff normally is not invented out of thin air. There must be something else behind it.
Developers are artisans
Before we go any further with digging the story of “10X developer” I must say that it sounds ridiculous. Developers are artisans - not machines with multipliers. To me the term alianates the human in developer and turn him or her into a machine which has a certain machine type of capacity. It bit like a car engine has horse powers. Developers are creative people. Their creativeness is not artistic as it normally is understood. But great code is pleasant to read and looks “nice”. It has artistic features. Every bigger code block is unique and thus are representations of the creators mind and desires.
Developers are the artists of the digital economy.
Developers have different skills
Not all developers are ninja-guru-fullstack-unicorns which produce 3000 lines of super efficient code every hour. That would be a machine and machines are standardised engines. Developers at least for now are humans. We have different skills. It’s not about writing more code; it’s about writing the right code. Thus it can be said that you can become a 10x programmer, but not by doing an order of magnitude more work, but by making better decisions an order of magnitude more often. Skills are acquired by training, using the tools and exploring the opportunities.
Remember to serve the “Jack Sparrows” of the customers as well. I feel like Sparrow 99% of the time I develop/code something
As like consumers can be divided to segments so can the developers. Even though putting a developer to a box is not nice (nobody likes it) it helps us to understand the developer pool better. Some stereotypical classifications makes it easier to target right kind of developers at the right moment in product’s development cycle.
Most of the developers are in the middle and possibly become innovators (hackers). To me most talented developers are labelled as hackers. They find unusual usage to tools and services as well as hardware. They are the explorers of the digital economy/realm.
AI probably will be able to create beautiful code in the future, code which is hard to differentiate from human production, but we are not there yet. AI and even simpler tools like code generators can assist the developer with boring stuff, but the creative part still requires human touch. It requires an artisan. It must be admitted that I have not checked the latest innovations and research on “AI programming” so I might be wrong and all developers can be replaced with machines. I have my doubts about that.
But what is the origin of 10X developer myth?
It most likely comes from measuring the efficiency of programmers. I understand the need and desire for measuring. Management wants to know how efficient the “developer machine” is. Hell, even the developers want to measure their progress. Old ways to measure productivity was lines of code is given period of time. More recently measurement has turned into bugs solved in given period of time, features or user stories finished over given period of time, create less bugs. Sometimes even epics finished in given timeframe. There are multiple ways to measure productivity but for sure taylorism way of tracking lines of code is not one of those.
The earliest known research about the productivity is from 1968. That is where the “10X” probably comes from. Sackman, H., W.J. Erikson, and E. E. Grant in 1968 did a study (“Exploratory Experimental Studies Comparing Online and Offline Programming Performance.”) comparing people solving a particular debugging problem, and found that some of them did it 10x faster than others. From this we could conclude that some people are 10x better at solving that problem, or we could conclude that some people got lucky, or a wide variety of different things. Some people chose to quote this as (these are all paraphrases) “a study (Sackman et al, 1968) found some programmers work 10x faster than others”. Then it became “studies have shown that good programmers are 10x better than average” then finally “it is common knowledge that programmer productivity varies by 10x between individuals”. If you want to read solid information about productivity, check out DeMarco, Tom and Timothy Lister, 1999. Peopleware: Productive Projects and Teams.
DX and 10X
If your view to efficiency is lines-of-code “10X”, then you probably fail in understanding the Developer eXperience as well. It’s not all math! It’s combination of engineering, psychology and empathy. 10X thinkers most likely fail in the last two items. As a API provider you should be concerned about how productive the API consumers can be with your product. In those cases your metrics are something like: time to first hello world, do they use your API and how much, what is the churn rate, what technical issues causes flow state breaks and so on. I would say that “10X” is not complete myth, but it has negative stigma due to false metrics.
If you can prove by using hardcore statistics that you have improved the usability of your API by 10X, you can call your self 10DX - truly a unicorn DX developer. If you can do that, your productivity value is enormous since it multiplies as the API is used.
Next post is personal experience related to text-to-speech services. You can always suggest topics for future post in Github. Just make an issue! I already added some, so no need to be shy.
Some more to read from 100 Days DX
- #100 - The biggest open resource on Developer eXperience so far
- #99 - Hackers - the top 1% of engineers
- #98 - Invalid Open API spec files ruins the developer experience
- #97 - Lightweight API evaluation framework
- #96 - Embracing open source community driven tools development
- #95 - Exploring the multilevel nature of API Design Guides
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!