Given the same task, two developers often come up with solutions that differ in an order of magnitude in size, complexity, dependency count and resource consumption.
I code for approximately an hour a day after my kids have gone to bed. (I’m a manager these days, so my job doesn’t involve day-to-day coding.) During that time I can be shockingly productive, cranking out a solid chunk of performant, safe, well-factored code in an amount of time that would have been an extended coffee break back in my “code-slinging” days.
So, have I discovered the Nirvana of 10x-ness? Could I jump back in to coding and be massively more effective than I was in my 20s or the portion of my 30s where I still considered myself a professional software developer?
No, and no. I’ve just found a comfortable niche where the problem domain, freedom to choose the tools I want, and lack of 50 competing demands on my time let me go head-down and code and consider only that time when I measure my production.
In my experience there’s a very strong correlation between “10x coders” and people who are given the space to work, control over their tools, and trust to architect systems as they choose.
Whether they earn that because of demonstrated, sustained performance or learn to do it after thrashing around in the deep end for a few years is kind of a chicken-and-egg problem, but studies and surveys (sorry to not have links handy, I’m typing this on my phone) show consistently that developers are happiest and feel most effective when offered those freedoms.
In what kind of setting do two developers have to produce the exact same thing at the same time, without talking to eachother about it? And is it always the case that developer A produces something that’s objectively 10x better than developer B, or are the roles sometimes reversed. For instance, does it depend on experience in a certain niche?
That happens all the time when discussing the scope of new projects.
A recent example I have in mind is, the employer wants a place to collect and analyze data that is being generated by their product.
Developer A’s proposal was to build a full data warehouse with SMT, CMT, ETL, Timeseries DB, …
Developer B’s proposal was to ingest the data into an S3 bucket in a regular format, and then plug whatever DB we need when we need it.
Without judging which proposal is the most appropriate, which varies on the context. It’s quite obvious to me that the first proposal is at least 10x bigger.
One example are test-work situations. Multiple developers who are considered for longer term projects do the same small project.
I did not say objectively better. But 10x difference in size, complexity, dependency count and resource consumption. Personally, I think this leads to even more then 10x slower progress when the code evolves. But opinions on this differ widely.
But 10x difference in size, complexity, dependency count and resource consumption.
I would probably call that objectively better. But maybe that’s my own biased thinking.
For instance, did the developers know that optimizing for these things was a goal? Did the other developers produce something in shorter time? Were they equally experienced?
did the developers know that optimizing for these things was a goal
No, because development is a tradeoff between so many goals that stating something like “size is important” would lead to absurd constructs. In my experience, every developer has their style and you cannot change it much. For example a dev who prefers to think in “business objects” over “sql queries” will struggle if you force them to change that type of thinking. Even if their approach creates code that needs ten million times more resources.
Did the other developers produce something in shorter time?
I would say usually coding time is shorter for the smaller, leaner, less resource hungry solutions with less dependencies.
Were they equally experienced?
In my experience there is a strong correlation betwen experience and the type of solutions a developer comes up with. And the time they need to implement them. More experienced developers tend to come up with leaner solutions and need less time to implement them.
In my experience there is a strong correlation betwen experience and the type of solutions a developer comes up with. And the time they need to implement them.
This would seem to fit well with other types of jobs. I think the myth is that there are people who are “magically” 10x better somehow, which makes very little sense to me.
It’s not that they’re magically better. There are practices you can follow that get you those results, but people just don’t seem interested in following them:
Understand the business reasoning behind the project…look for ways of exploiting that knowledge to minimize the amount of work done.
Less code is always easier to debug…or if you can’t debug, throw out and replace.
Clearly defined project goals and constraints and milestones make development fast and visible.
Throwaway prototypes are faster than big projects and teach you more–and may be good enough for the business.
Understanding, deeply, the tools you use and the basic principles of computer science and engineering help you prune solution spaces a lot better.
Identify whether or not the framework/third-party app is actually delivering value over just implementing a smaller bespoke solution yourself. Color picker? Almost certainly. Database extension? Probably. Container orchestration for a static blog? Probably not.
Pseudocode and stepwise refinement of the solution to a problem. If you can’t explain something with bullet points, you don’t understand it, and if you don’t understand it, you’re slow.
There are more I think, but that’s a start.
Somewhat grumpily: there may not be 10x software engineers, but there sure as hell are 10x embedded AWS salesfolk.
I think your third point is the most important one. Perhaps a 10x developer is gifted at recognizing the business priorities even when the Product folks don’t see how much size/complexity matters?
I would like to think that my style has some flexibility to it, though I’ve definitely landed on the SQL queries side of that divide in the past.
Of course, everyone struggles with a new way of thinking at first. Which is why, for me at least, I seek out new ways of thinking, so I can get the struggle done with.
I would say usually coding time is shorter for the smaller, leaner, less resource hungry solutions with less dependencies
I’m not sure I agree, here. Maybe if you take “coding time” (as opposed to “dev time”) very strictly, but even then…
My anecdata includes a bunch of hackathon projects that, when polished up for production, amounted to far less code. Reducing duplication, refining design for smaller code, replacing bespoke with off-the-shelf libraries, etc, all benefit from taking time.
This is actually a key source of disagreement about the whole “10X” idea. As far as I know, it was supposed to be about the difference between the worst developers and the best ones, not between average developers and the best ones.
There’s definitely something to that, but I think professional baseball is the wrong analogy for the software development profession as a whole.
Major-league baseball would maybe be more of an analogy for big-N tech companies (where the highly-skewed distribution definitely exists, based on my experience working for one of them) and the bush leagues are all the anonymous development teams in big companies that need people to churn out CRUD apps for low-volume internal use and can’t afford to (nor have any reason to) reject 95% of their job applicants.
Given the same task, two developers often come up with solutions that differ in an order of magnitude in size, complexity, dependency count and resource consumption.
I have witnessed that over and over.
I code for approximately an hour a day after my kids have gone to bed. (I’m a manager these days, so my job doesn’t involve day-to-day coding.) During that time I can be shockingly productive, cranking out a solid chunk of performant, safe, well-factored code in an amount of time that would have been an extended coffee break back in my “code-slinging” days.
So, have I discovered the Nirvana of 10x-ness? Could I jump back in to coding and be massively more effective than I was in my 20s or the portion of my 30s where I still considered myself a professional software developer?
No, and no. I’ve just found a comfortable niche where the problem domain, freedom to choose the tools I want, and lack of 50 competing demands on my time let me go head-down and code and consider only that time when I measure my production.
In my experience there’s a very strong correlation between “10x coders” and people who are given the space to work, control over their tools, and trust to architect systems as they choose.
Whether they earn that because of demonstrated, sustained performance or learn to do it after thrashing around in the deep end for a few years is kind of a chicken-and-egg problem, but studies and surveys (sorry to not have links handy, I’m typing this on my phone) show consistently that developers are happiest and feel most effective when offered those freedoms.
In what kind of setting do two developers have to produce the exact same thing at the same time, without talking to eachother about it? And is it always the case that developer A produces something that’s objectively 10x better than developer B, or are the roles sometimes reversed. For instance, does it depend on experience in a certain niche?
That happens all the time when discussing the scope of new projects.
A recent example I have in mind is, the employer wants a place to collect and analyze data that is being generated by their product.
Without judging which proposal is the most appropriate, which varies on the context. It’s quite obvious to me that the first proposal is at least 10x bigger.
One example are test-work situations. Multiple developers who are considered for longer term projects do the same small project.
I did not say objectively better. But 10x difference in size, complexity, dependency count and resource consumption. Personally, I think this leads to even more then 10x slower progress when the code evolves. But opinions on this differ widely.
I would probably call that objectively better. But maybe that’s my own biased thinking.
For instance, did the developers know that optimizing for these things was a goal? Did the other developers produce something in shorter time? Were they equally experienced?
No, because development is a tradeoff between so many goals that stating something like “size is important” would lead to absurd constructs. In my experience, every developer has their style and you cannot change it much. For example a dev who prefers to think in “business objects” over “sql queries” will struggle if you force them to change that type of thinking. Even if their approach creates code that needs ten million times more resources.
I would say usually coding time is shorter for the smaller, leaner, less resource hungry solutions with less dependencies.
In my experience there is a strong correlation betwen experience and the type of solutions a developer comes up with. And the time they need to implement them. More experienced developers tend to come up with leaner solutions and need less time to implement them.
This would seem to fit well with other types of jobs. I think the myth is that there are people who are “magically” 10x better somehow, which makes very little sense to me.
It’s not that they’re magically better. There are practices you can follow that get you those results, but people just don’t seem interested in following them:
There are more I think, but that’s a start.
Somewhat grumpily: there may not be 10x software engineers, but there sure as hell are 10x embedded AWS salesfolk.
I think your third point is the most important one. Perhaps a 10x developer is gifted at recognizing the business priorities even when the Product folks don’t see how much size/complexity matters?
I would like to think that my style has some flexibility to it, though I’ve definitely landed on the SQL queries side of that divide in the past.
Of course, everyone struggles with a new way of thinking at first. Which is why, for me at least, I seek out new ways of thinking, so I can get the struggle done with.
I’m not sure I agree, here. Maybe if you take “coding time” (as opposed to “dev time”) very strictly, but even then…
My anecdata includes a bunch of hackathon projects that, when polished up for production, amounted to far less code. Reducing duplication, refining design for smaller code, replacing bespoke with off-the-shelf libraries, etc, all benefit from taking time.
I’m not sure if there are 10x developers, but there sure are 0.001x developers.
This is actually a key source of disagreement about the whole “10X” idea. As far as I know, it was supposed to be about the difference between the worst developers and the best ones, not between average developers and the best ones.
I’d say it applies somewhat to both, because like most talented jobs, the distribution is right-skewed.
There’s definitely something to that, but I think professional baseball is the wrong analogy for the software development profession as a whole.
Major-league baseball would maybe be more of an analogy for big-N tech companies (where the highly-skewed distribution definitely exists, based on my experience working for one of them) and the bush leagues are all the anonymous development teams in big companies that need people to churn out CRUD apps for low-volume internal use and can’t afford to (nor have any reason to) reject 95% of their job applicants.
I recently read Peopleware which also makes the 10x claim as original source and it seems at least plausible to me. The caveats are:
Environment is the big factor. The average difference between programmers in the same organization was less than 50%.
Not gonna lie, I’m sad that automoderation removed the performance tag, but I was being a bit cheeky.