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