Not a myth at all. I have seen this in real life many times. The engineer who finishes a task (correctly!) in 2 days instead of 2 weeks. Who fixes the system along the way. Whose code is readable and maintainable. Who doesn't get blocked.
I pondered this for some time and the conclusion I came to is this.
I'm a reasonably good developer (been selling software in one form or another for nearly 2 decades) and I've worked with people who where twice as productive as me bit I've also worked with people who where 1/5 as productive.
So relative to them the x2 developer looks x10 where compared to me he looks x2.
It's all relative, in a company of top-class engineering talent their should be no x10 engineers as if there are then the others by definition aren't top class (though possibly still way above average).
As for been a rockstar who wants to be they die at 27 in a drug fuelled binge or live long enough to become a mockery of themselves.
Nope. The top engineers will be drastically more effective than the average developer, in ANY codebase. They take the time to understand it, and change things when necessary. I have seen this in every place I've worked.
They will still be more effective, but if the codebase has a bunch of fundamental structural flaws that they have to work around, he would be a lot slower in net effectiveness if he didn't have to work with that code base until he gets the 4 months to a year it will take to fix the structural problems. His work ability, along with everyone else's will be divided by 10.
They see the mess, and they see the way out. Any change they make is a refactor with the end goal in mind. Before you realize it the codebase is cleaner, concerns have been separated, interfaces made extensible, concepts more clean.
They use a number of tools, from creating facades of the previous interfaces/implementations. From judicious use of aspects, annotations, functional elements. And just plain old better coding.
Of course, sometimes they are too clever for their own good, and things quickly slide backwards when they move on, because no-one else understood the grand vision, the master plan, and quickly things fall back to hacks-upon-workarounds-of-kludges.
There was a post a while back talking about the myth of the 10x developer. It mentioned that there aren't 10x developers, but there are 10x teams. In these teams you have the developers who are productive and churn out a lot of code. Then you have the developers who can stand back and be more thoughtful about the whole. Together they can be productive while still producing quality code.
In your example, someone has already written the code, possibly shipped it and if it's not a complete disaster, created value. The "10x developer" comes along and is able to take the time to refactor and clean things up (or direct someone to do so.)
As you mentioned, there are pros and cons for each role. The "10x" developer might think too much. The grinder might not create the prettiest code, but he might be great at moving the chains.
I think we can all place ourselves in either role. To get something out the door to meet a deadline sometimes requires the quick and dirty way. And sometimes shipping quick and dirty is far more important. To move from one role to the other is sometimes as difficult as switching between projects, so it's great to be able to have one person who can go in with one mind and another person to go in with a different mind.
As I'm usually the sole developer on my projects, I don't know if this is how things work in practice. I imagine in a cash strapped start-up all developers might be the type to shove out as much code as possible.
Perhaps all other things being equal, a 10x developer in that environment (a cash strapped start-up as opposed to a mature Twitter) might be the person who understands that shipping is more important when resources are short. The "other type" might not realize that things will probably work out in the end as long as the team is shipping. Things are never perfect, the stack will always be a house of cards, but the cash must keep flowing be it from investments, from clients or from customers all of whom are expecting progress.
Personally, I seem to switch back and forth. Sometimes I get on a roll and I'm knocking stuff out at a pace where I surprise myself. Sometimes I get locked up trying to over-think a problem. Sometimes I can go back through my code and see obvious problems and refactor the code with the same momentum as I had when I originally wrote it. I think the tricky part is finding the right balance and knowing what you need to be doing within your particular environment.
You have a bad codebase full of technical debt and bad early decisions. You know there is a way out, but it takes _time_, a good amount of time due to it's size. Time that management won't let you have due to it's ship yesterday culture. You do what you can with your re-factor as you go. People keep on digging shit in faster than you can dig shit out. They will recognize your a better developer, but when you compare yourself to the general market you are NOT a 10x developer in that place. The potential-10x developer will be one of the better ones there, but his multiplier effect is significantly reduced because he is walking in code molasses.
Because of this he will look like a medicore developer inside the that place, and it will hamper his career progression. By having to slog through crap, it doesn't push him in the right way and he doesn't improve the best he can. That is the big difference.
I think how someone else said there are 10x teams is a more accurate way to think about it. People are not islands.
still somewhat an issue of measuring against 'what?'. If most of the people on the team are already good, it's much harder for anyone to be 10x anyone else in terms of productivity. You almost have to have dead weight on the team to be a 10x developer.
Apparently it "is a person so talented that he or she does the work of 10 merely competent engineers."
So, I guess this guy is a 100x engineer, based on his income.
Comments
great story, but my question is how can i be a 10X engineer? or what does 10X engineer mean ?
I think the "10X engineer" is the new word for "Rockstar Developer".
Manage a team of ten engineers.
Extremely timely post from Shanley about the mythos of the "10x engineer", how it began, and why it is so pernicious:
https://medium.com/about-work/6aedba30ecfe
(Hint: 10x what? what is the thing being measured, and how?)
Not a myth at all. I have seen this in real life many times. The engineer who finishes a task (correctly!) in 2 days instead of 2 weeks. Who fixes the system along the way. Whose code is readable and maintainable. Who doesn't get blocked.
I pondered this for some time and the conclusion I came to is this.
I'm a reasonably good developer (been selling software in one form or another for nearly 2 decades) and I've worked with people who where twice as productive as me bit I've also worked with people who where 1/5 as productive.
So relative to them the x2 developer looks x10 where compared to me he looks x2.
It's all relative, in a company of top-class engineering talent their should be no x10 engineers as if there are then the others by definition aren't top class (though possibly still way above average).
As for been a rockstar who wants to be they die at 27 in a drug fuelled binge or live long enough to become a mockery of themselves.
Nobody can be a 10x engineer if they are working in a molasses of a codebase or workplace. And fixing the codebase would be a many month project.
Nope. The top engineers will be drastically more effective than the average developer, in ANY codebase. They take the time to understand it, and change things when necessary. I have seen this in every place I've worked.
They will still be more effective, but if the codebase has a bunch of fundamental structural flaws that they have to work around, he would be a lot slower in net effectiveness if he didn't have to work with that code base until he gets the 4 months to a year it will take to fix the structural problems. His work ability, along with everyone else's will be divided by 10.
I'm not sure you've worked with a 10x developer.
They see the mess, and they see the way out. Any change they make is a refactor with the end goal in mind. Before you realize it the codebase is cleaner, concerns have been separated, interfaces made extensible, concepts more clean.
They use a number of tools, from creating facades of the previous interfaces/implementations. From judicious use of aspects, annotations, functional elements. And just plain old better coding.
Of course, sometimes they are too clever for their own good, and things quickly slide backwards when they move on, because no-one else understood the grand vision, the master plan, and quickly things fall back to hacks-upon-workarounds-of-kludges.
There was a post a while back talking about the myth of the 10x developer. It mentioned that there aren't 10x developers, but there are 10x teams. In these teams you have the developers who are productive and churn out a lot of code. Then you have the developers who can stand back and be more thoughtful about the whole. Together they can be productive while still producing quality code.
In your example, someone has already written the code, possibly shipped it and if it's not a complete disaster, created value. The "10x developer" comes along and is able to take the time to refactor and clean things up (or direct someone to do so.)
As you mentioned, there are pros and cons for each role. The "10x" developer might think too much. The grinder might not create the prettiest code, but he might be great at moving the chains.
I think we can all place ourselves in either role. To get something out the door to meet a deadline sometimes requires the quick and dirty way. And sometimes shipping quick and dirty is far more important. To move from one role to the other is sometimes as difficult as switching between projects, so it's great to be able to have one person who can go in with one mind and another person to go in with a different mind.
As I'm usually the sole developer on my projects, I don't know if this is how things work in practice. I imagine in a cash strapped start-up all developers might be the type to shove out as much code as possible.
Perhaps all other things being equal, a 10x developer in that environment (a cash strapped start-up as opposed to a mature Twitter) might be the person who understands that shipping is more important when resources are short. The "other type" might not realize that things will probably work out in the end as long as the team is shipping. Things are never perfect, the stack will always be a house of cards, but the cash must keep flowing be it from investments, from clients or from customers all of whom are expecting progress.
Personally, I seem to switch back and forth. Sometimes I get on a roll and I'm knocking stuff out at a pace where I surprise myself. Sometimes I get locked up trying to over-think a problem. Sometimes I can go back through my code and see obvious problems and refactor the code with the same momentum as I had when I originally wrote it. I think the tricky part is finding the right balance and knowing what you need to be doing within your particular environment.
ETA: Changed things around for clarity.
If you divide everyone by 10, wouldn't that keep the 10x guy still 10x better/bigger/stronger/faster?
Also, "bad codebase" is a terrible excuse. There is always a way out.
You have a bad codebase full of technical debt and bad early decisions. You know there is a way out, but it takes _time_, a good amount of time due to it's size. Time that management won't let you have due to it's ship yesterday culture. You do what you can with your re-factor as you go. People keep on digging shit in faster than you can dig shit out. They will recognize your a better developer, but when you compare yourself to the general market you are NOT a 10x developer in that place. The potential-10x developer will be one of the better ones there, but his multiplier effect is significantly reduced because he is walking in code molasses.
Because of this he will look like a medicore developer inside the that place, and it will hamper his career progression. By having to slog through crap, it doesn't push him in the right way and he doesn't improve the best he can. That is the big difference.
I think how someone else said there are 10x teams is a more accurate way to think about it. People are not islands.
still somewhat an issue of measuring against 'what?'. If most of the people on the team are already good, it's much harder for anyone to be 10x anyone else in terms of productivity. You almost have to have dead weight on the team to be a 10x developer.
And does it day-in and day-out consistently.
Apparently it "is a person so talented that he or she does the work of 10 merely competent engineers." So, I guess this guy is a 100x engineer, based on his income.
I was thinking the same thing