3 ms·

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

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.

rhizome 13y ago
And does it day-in and day-out consistently.
mgkimsal 13y ago
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.
noir_lord 13y ago
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.
mahyarm 13y ago
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.
- paulrademacher 13y ago
  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.
  - mahyarm 13y ago
    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.
    - Swannie 13y ago
      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.
      - gexla 13y ago
        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.

rhizome 13y ago

And does it day-in and day-out consistently.

mgkimsal 13y ago

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.

noir_lord 13y ago

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.

mahyarm 13y ago

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.

paulrademacher 13y ago
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.
- mahyarm 13y ago
  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.
  - Swannie 13y ago
    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.
    - gexla 13y ago
      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.