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.
Comments
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.