Becoming a 10x Developer (2018)(kateheddleston.com)
kateheddleston.com
Becoming a 10x Developer (2018)
https://www.kateheddleston.com/blog/becoming-a-10x-developer
32 comments
I think this is the closest I've seen to a concise answer to the 10X programmer's advantage. Earlier in my career, I noticed a fellow programmer who was quite noticeably faster at completing tasks than everyone else including myself. We also had a coding competition and I 'programmed' as fast as he did in direct comparison on the same task. So it turns out, the performance boost was not in raw coding speed but a lot of other things like not being distracted, being ok with a great but not the greatest design, getting to work and avoiding analysis paralysis. A sense of urgency from day one on a project.
When competing head to head for a fun competition, many of these things come naturally but when given 'time' it can be easy to fall back to less productive habits when a deadline is months away.
Like my mentor Steve Hayes once told me 'hands on keyboard'
When competing head to head for a fun competition, many of these things come naturally but when given 'time' it can be easy to fall back to less productive habits when a deadline is months away.
Like my mentor Steve Hayes once told me 'hands on keyboard'
>The programming community is extremely polarized about the existence or not of such a beast: who says there is no such a thing as the 10x programmer, who says it actually does not just exist, but there are even 100x programmers if you know where to look for.
I think it depends on your definition. If you compare with the average programmer in your company then you can easily be a 10x if you're working in a big company where the average abilities are low. But it becomes very hard in a smaller company where most of your colleagues are competent.
If you define it relative to a more global average I think it's too difficult to know what an "average" programmer even is.
Now if in that big company you have to work only on small parts of the whole it often becomes harder to be fast again, since your colleagues might be writing APIs with a lot of hidden complexity.
If however your task is more isolated it becomes easier to do good design.
I think it depends on your definition. If you compare with the average programmer in your company then you can easily be a 10x if you're working in a big company where the average abilities are low. But it becomes very hard in a smaller company where most of your colleagues are competent.
If you define it relative to a more global average I think it's too difficult to know what an "average" programmer even is.
Now if in that big company you have to work only on small parts of the whole it often becomes harder to be fast again, since your colleagues might be writing APIs with a lot of hidden complexity.
If however your task is more isolated it becomes easier to do good design.
> Teams that work well together can outperform groups of people who are collectively more talented because there is a multiplication factor for teamwork.
There's some great advice here about building a team culture that allows everyone to level-up and contribute their best. Some comments here have suggested that this isn't what 10x means but that's the point! What if we value the wrong kinds of people in our teams - the talented jerks? We should instead call out the value of those that help the whole team improve.
On top of the productivity gains, the value of building a culture like this is invaluable for a startup or team with a long-term vision. It builds a sense of camaraderie and environment for learning and growth that draws people in and keeps them around for a long time.
Jessica Livingston shares on the role she played in founding YC and building the culture. She points out some of the same kinds of ideas in one of her talks[1] showing that some of the soft skills and the social environment that founders build are way more important than they often realise.
[1] - https://www.youtube.com/watch?v=8d-cApFHjeY
There's some great advice here about building a team culture that allows everyone to level-up and contribute their best. Some comments here have suggested that this isn't what 10x means but that's the point! What if we value the wrong kinds of people in our teams - the talented jerks? We should instead call out the value of those that help the whole team improve.
On top of the productivity gains, the value of building a culture like this is invaluable for a startup or team with a long-term vision. It builds a sense of camaraderie and environment for learning and growth that draws people in and keeps them around for a long time.
Jessica Livingston shares on the role she played in founding YC and building the culture. She points out some of the same kinds of ideas in one of her talks[1] showing that some of the soft skills and the social environment that founders build are way more important than they often realise.
[1] - https://www.youtube.com/watch?v=8d-cApFHjeY
Here are some serious outstanding problems in software:
* Considering how fast modern computers are, software is so damn slow.
* Software frequently stops working. When it does, the process to diagnose the bug and fix it conclusively is not a straightforward one.
* Software is poorly understood. Most developers today work with other people’s abstractions. It’s rare to find a software system that someone can describe the inner workings of end to end.
* Software is excessively complex. To understand a codebase, you might have to crawl through ten layers of dependencies, imports, and scaffolding before finding code that actually does anything.
These are just some obvious ones off the top of my head. Does following the advice on this list make me any better at tackling any of these problems?
Could someone conceivably do none of the things on this list, and still be a very skilled developer who makes strong strides toward solving these problems?
* Considering how fast modern computers are, software is so damn slow.
* Software frequently stops working. When it does, the process to diagnose the bug and fix it conclusively is not a straightforward one.
* Software is poorly understood. Most developers today work with other people’s abstractions. It’s rare to find a software system that someone can describe the inner workings of end to end.
* Software is excessively complex. To understand a codebase, you might have to crawl through ten layers of dependencies, imports, and scaffolding before finding code that actually does anything.
These are just some obvious ones off the top of my head. Does following the advice on this list make me any better at tackling any of these problems?
Could someone conceivably do none of the things on this list, and still be a very skilled developer who makes strong strides toward solving these problems?
> These are just some obvious ones off the top of my head.
But they are all the same one (the last form is the clearest statement), restated in different ways or viewed through effects that the same source causes.
But they are all the same one (the last form is the clearest statement), restated in different ways or viewed through effects that the same source causes.
I’d argue that there’s at least two problems: software is needlessly complex, and no one understands what the computer is doing.
You might say that second one is the same, but our model for what a processor is and what it’s doing and how fast it’s working hasn’t changed in at least 10 years. Graphics cards have gotten faster, but still have a similar operating model. If anything access to low level systems has gotten easier to understand and harness.
Because all of this stuff is still the same, you can usually take a look at any piece of software and make it faster by aligning the code to what the computer is good at. That could be done by increasing data locality and widening the processing pipe with SIMD. Caching and cheating the calculations are also often good since they essentially skip work that will go unnoticed. This will often increase the code complexity, but improve the software speed.
You might say that second one is the same, but our model for what a processor is and what it’s doing and how fast it’s working hasn’t changed in at least 10 years. Graphics cards have gotten faster, but still have a similar operating model. If anything access to low level systems has gotten easier to understand and harness.
Because all of this stuff is still the same, you can usually take a look at any piece of software and make it faster by aligning the code to what the computer is good at. That could be done by increasing data locality and widening the processing pipe with SIMD. Caching and cheating the calculations are also often good since they essentially skip work that will go unnoticed. This will often increase the code complexity, but improve the software speed.
You’re right.
> Could someone conceivably do none of the things on this list
Conversely, you could do everything on this list, and still be a lousy programmer. Or not even a programmer at all.
Conversely, you could do everything on this list, and still be a lousy programmer. Or not even a programmer at all.
Excerpts:
"1. Create an environment of psychological safety"
"6. Hold yourself and others accountable"
Now, not to get all lawyerly (I am not a lawyer) or anything, but...
How exactly do you do #1 if it conflicts with #6?
?
And...
How exactly do you do #6 if it conflicts with #1?
?
"1. Create an environment of psychological safety"
"6. Hold yourself and others accountable"
Now, not to get all lawyerly (I am not a lawyer) or anything, but...
How exactly do you do #1 if it conflicts with #6?
?
And...
How exactly do you do #6 if it conflicts with #1?
?
Psychological safety, I think, comes with not being afraid of unexpected actions or consequences of actions, and from knowing that not everything is on the line all the time, ie it is ok to make mistakes. Safe = not having to fear being fired or worse due to either mistakes or unexpected reactions of bosses and peers.
You can do accountability while having that safety by (kindly) informing people that they will be expected to do a task that they accept/are given, and being clear about other expectations like deadlines, BEFORE they start the task. Give people the informantion needed to predict the result of their actions. And by growing a culture where people know that it is bad not to uphold an agreement (and that may include some kind of “punishment”, which ofc is known to everyone beforehand). It is not bad to do you best to solve a task but make a mistake doing it. That should not have consequences.
You can do accountability while having that safety by (kindly) informing people that they will be expected to do a task that they accept/are given, and being clear about other expectations like deadlines, BEFORE they start the task. Give people the informantion needed to predict the result of their actions. And by growing a culture where people know that it is bad not to uphold an agreement (and that may include some kind of “punishment”, which ofc is known to everyone beforehand). It is not bad to do you best to solve a task but make a mistake doing it. That should not have consequences.
I know a >250x programmer. That is strictly objective: on a 500-engineer 6-month death-march project, fully half the code delivered was his. He knows somebody who he estimates at 10x his own rate, and who wears out 2 keyboards a year (or did, 20 years ago).
(You might object that this makes him a 500x programmer, but he doesn't agree: a fair bit of code was written that did not end up in the product, an unknown fraction of which was good.)
(You might object that this makes him a 500x programmer, but he doesn't agree: a fair bit of code was written that did not end up in the product, an unknown fraction of which was good.)
I'm curious about what was the technology stack for that project. Also, it would be very interesting to learn what those ">250x" programmers think on various languages / technology stacks (that they use) from the developer productivity perspective ...
This was in the '90s, so pre-'98 C++, on a proprietary OS fielded by Siemens and Ericsson.
The stacks in use today optimize for accessibility by less skilled programmers, and (more) for heavy requirements on management participation and total head count. Productivity is a non-goal. A 250x programmer would be distinctly unwelcome almost everywhere, today, although there are still more places that want one than are available to hire. I spoke recently with someone who spent time at Walmart corporate, and got in deep, deep trouble for finishing in a week a project scheduled to take 12.
Dan Luu explains on his blog how little value his employers have placed on his contributions that earned or saved them hundreds or thousands of times his salary for the time he spent. Managers mostly value what improves their standing among other managers, not what benefits the company.
Doing what benefits society or the world gets you escorted out without severance pay.
The stacks in use today optimize for accessibility by less skilled programmers, and (more) for heavy requirements on management participation and total head count. Productivity is a non-goal. A 250x programmer would be distinctly unwelcome almost everywhere, today, although there are still more places that want one than are available to hire. I spoke recently with someone who spent time at Walmart corporate, and got in deep, deep trouble for finishing in a week a project scheduled to take 12.
Dan Luu explains on his blog how little value his employers have placed on his contributions that earned or saved them hundreds or thousands of times his salary for the time he spent. Managers mostly value what improves their standing among other managers, not what benefits the company.
Doing what benefits society or the world gets you escorted out without severance pay.
I much appreciate your comment. This is all very interesting and very weird (or even quite scary), at the same time.
And I thought being a 10x developer meant cranking out high quality code..
I would have thought it would have at least something to do with computers at all...
In a context where it useful. 10x is about impact, not lines of code.
Every developer should do all of these things, the behavior and norms described in this blog post seem like the absolute minimum to have a healthy work environment.
> Invite discussion with your language by using words like “I think” and “maybe”. (I call this conversational style: "Maybe you should talk more like a woman?")
Aside from the fact that I did not understand that "talk like a woman" thing, is the author advising us to stop the long-running advice of "speak precisely" with "say anything, even if you are not sure' with the only caveat being to let people know when you aren't certain of something?
That's like a public speaker telling me to say "uuhh..." in between my phrases!
Aside from the fact that I did not understand that "talk like a woman" thing, is the author advising us to stop the long-running advice of "speak precisely" with "say anything, even if you are not sure' with the only caveat being to let people know when you aren't certain of something?
That's like a public speaker telling me to say "uuhh..." in between my phrases!
> is the author advising us to stop the long-running advice of "speak precisely" with "say anything, even if you are not sure' with the only caveat being to let people know when you aren't certain of something?
You got it all wrong. The key point is that by adopting a conversation style where you cease to impose your beliefs as unquestionable facts and start to leave the door open for others to provide their observations and insight, you start to get observations and insights from others.
It's as simple as that.
And by the way, your personal opinion is not precision or an expression of a fact. Your personal opinion is just the conclusion you've made based on the information and experience you had up to that point. If you cease to be defensive about your opinions when sharing them with others, others will follow suit.
You got it all wrong. The key point is that by adopting a conversation style where you cease to impose your beliefs as unquestionable facts and start to leave the door open for others to provide their observations and insight, you start to get observations and insights from others.
It's as simple as that.
And by the way, your personal opinion is not precision or an expression of a fact. Your personal opinion is just the conclusion you've made based on the information and experience you had up to that point. If you cease to be defensive about your opinions when sharing them with others, others will follow suit.
I don't think the advice entails lower quality discourse. The prescription here, read literally, is to say the same thing, phrased in a way that invites relevant discussion.
Language emphasising subjectivity can do several things - a) you signal uncertainty so that the group has a better idea of what's really known, b) you explicitly distinguish opinion from fact, c) you invite people to share their understanding so you can get on the same page.
The emphasis seems to be less the informational (a) and (b) and more the cultural (c). It's tricky - in some sense if you're certain, you undermine the force of your opinion this way. Comparing the two communication styles there's a tradeoff between reducing friction (unnecessary? examination) and encouraging communication in general, with possible benefits for cohesion, shared understanding and expertise but also the possible detriment of communal navel gazing. If you trust the studies this refers to, encouraging equal turn-taking overall has long-term benefits for productivity.
I think both approaches have failure cases where communication becomes ineffective. Individuals will adapt to each style to different degrees, and there's no total substitute for savvy folks who are alert to social forces at play, and guide discussions when team members over- or under-play their hands.
To share the generalisation used by this piece, the suggested conversational style is more hospitable to women. Where this article talks about psychological safety, equal participation etc., I think a lot of male engineers feel safe in much more confrontational and argumentative situations than women - they can even find a kind of fun in conflict, or regard it as totally impersonal, where many women would find it deeply unpleasant and to be avoided at all costs.
Language emphasising subjectivity can do several things - a) you signal uncertainty so that the group has a better idea of what's really known, b) you explicitly distinguish opinion from fact, c) you invite people to share their understanding so you can get on the same page.
The emphasis seems to be less the informational (a) and (b) and more the cultural (c). It's tricky - in some sense if you're certain, you undermine the force of your opinion this way. Comparing the two communication styles there's a tradeoff between reducing friction (unnecessary? examination) and encouraging communication in general, with possible benefits for cohesion, shared understanding and expertise but also the possible detriment of communal navel gazing. If you trust the studies this refers to, encouraging equal turn-taking overall has long-term benefits for productivity.
I think both approaches have failure cases where communication becomes ineffective. Individuals will adapt to each style to different degrees, and there's no total substitute for savvy folks who are alert to social forces at play, and guide discussions when team members over- or under-play their hands.
To share the generalisation used by this piece, the suggested conversational style is more hospitable to women. Where this article talks about psychological safety, equal participation etc., I think a lot of male engineers feel safe in much more confrontational and argumentative situations than women - they can even find a kind of fun in conflict, or regard it as totally impersonal, where many women would find it deeply unpleasant and to be avoided at all costs.
Maybe framing it different might help. “Be honest with yourself and others about how certain you are about your facts, and never state opinions as facts.”
If you do this, people will more readily challenge the ideas they have evidence against and trust you when they don’t. It also allows you to throw more ideas into the pot since you don’t always have to know the perfect answer before saying something.
If you do this, people will more readily challenge the ideas they have evidence against and trust you when they don’t. It also allows you to throw more ideas into the pot since you don’t always have to know the perfect answer before saying something.
When working as a part of a group on a complicated problem, it is valuable to throw in information of which you only have say 70% confidence, provided you qualify it with an explicit statement of such confidence ("I think", "maybe"). This is especially relevant in problems involving people/teams in large organizations - there it's often hard to know much for sure and planning becomes an exercise in probabilities and speculation.
However overused, the phrase 10x developer does have a fairly specific meaning, and this isn't it.
The article is pretty up-front and unapologetic about that conceit: the argument is "that mythology isn't useful, here's a better one."
That said, it's certainly a bait-and-switch headline. Kind of par for the course.
That said, it's certainly a bait-and-switch headline. Kind of par for the course.
> the argument is "that mythology isn't useful, here's a better one."
That's just a lame attempt to piggy-back on the name recognition of an established concept to try to funnel the spotlight on an entirely different and unrelated concept.
Different concepts are different. Thus they should be named differently, without resorting to unexcusable PR tactics.
That's just a lame attempt to piggy-back on the name recognition of an established concept to try to funnel the spotlight on an entirely different and unrelated concept.
Different concepts are different. Thus they should be named differently, without resorting to unexcusable PR tactics.
Let's be clear: I don't think this article has created any confusion. It's manipulative, like a lot of headlines that hit the front page - you click on it expecting one thing, and find another. It's not misleading in the way poor naming in technical contexts is misleading, so I think you're somewhat guilty of conflating different concepts yourself.
The substitution is a rhetorical device to deliberately draw comparison between different ways of approaching the same goal, i.e. being more effective as a programmer.
The author, I expect, would justify the sleight of hand by saying: the audience that believes most wholeheartedly in 10x programmers is precisely the audience that needs to hear how to benefit from low-hanging fruit that will make teams more effective. Really it's an old saw, "the brilliant jerk vs. collaborative team".
You're welcome to disagree with that assessment, but I'd suggest that responding to the particular contentions in the article is more worthwhile that overinvesting in a rhetorical dichotomy which has been used for effect only.
The substitution is a rhetorical device to deliberately draw comparison between different ways of approaching the same goal, i.e. being more effective as a programmer.
The author, I expect, would justify the sleight of hand by saying: the audience that believes most wholeheartedly in 10x programmers is precisely the audience that needs to hear how to benefit from low-hanging fruit that will make teams more effective. Really it's an old saw, "the brilliant jerk vs. collaborative team".
You're welcome to disagree with that assessment, but I'd suggest that responding to the particular contentions in the article is more worthwhile that overinvesting in a rhetorical dichotomy which has been used for effect only.
It's not like "10x developer" was ever an intellectually rigorous concept.
> It's not like "10x developer" was ever an intellectually rigorous concept.
Isn't it? The developer whose productivity is 10x the average developer's?
Sounds like it's straight forward to me.
Isn't it? The developer whose productivity is 10x the average developer's?
Sounds like it's straight forward to me.
Discussed at the time: https://news.ycombinator.com/item?id=17304619
I think Antirez[1] has more practical advice on how to actually become a "10x programmer"
Key points:
* Experience: pattern matching
* Knowledge: some theory is going to help
* Low level: understanding the machine
* Debugging skills
* Perfectionism, or how to kill your productivity and bias your designs
* Design sacrifice: killing 5% to get 90%
* Simplicity
* Focus: actual time VS hypothetical time
[1] http://antirez.com/news/112