The "10x" developers are seductive, and can supercharge a project into getting version 1.0 off the ground in months instead of years. However, each one we've hired has left us worse off than before once they got bored and left us in the weeds trying to piece together what they had done.
Most of them suffer from "shiny ball" syndrome and are constantly dismayed by the complexities of the real world. The real world is a grind, filled with edge-cases, filled with needing to make 1-off exceptions, etc. These types of developers tend to hate that, and prefer the abstract beauty of their elegant and simple solutions....and when the real world crashes into their elegant creations, they get 'burned out' and jump ship.
I'm not blaming them, its just an observation. These 10x developers can be a godsend to a brand new startup, but past a 1.0 product, they can subtly turn into a liability fairly quickly.
When I build teams I usually select "builders" and "improvers." Improvers can't create new systems because they spend all day theorizing edge cases and what-ifs. Builders can't improve systems because they spend all day theorizing new systems to replace the legacy one they see as imperfect. You also have to get the right ratio of those two. Too many builders gets you a lot of brittle systems and a huge JIRA backlog; too many improvers creates stagnation.
Openers want to create new things, they love a blank canvas. Where some people are scared of this, they thrive in a place where you can lay down rules, define parameters, and create structures that are a good fit for the problem domain.
Sustainers like to work within a project that's evolving, but largely defined, where they can get a lot of things done and move the ball forward. They may create more work along the way, go on excursions, but the overall direction is roughly towards the goal. They have to make many compromises along the way.
Closers like finishing things, closing out bugs, wrapping up features, taking care of a myriad of loose ends and "TODO" type tasks. They're interested in completing work, not creating more work. This is where you have to make harsh judgement calls, implement ugly hacks, anything to wrap things up.
It's rare you'll find someone who excels at or even likes to do all three. We often have our bias.
Anyone can close if they're forced to, but some people actually like it. Clear objectives, solutions need to be focused, etc.
The dev you describe sounds like a junior who can crank out code at high velocity.
Syntactic sugar can't impress me anymore, unless it comes with significant performance gains or compress the code significantly without sacrificing readability to average Joe coder (this is important part). Actually I prefer 1 page of simple clean code to 1/2-liners that do it all, until they don't. I guess I am getting old.
You're saying their code was so good it survived 3 years of real world use and project evolution. That's extremely rare.
Of course it is possible for one developer to be better then other, but it is not necessary fixed. It changes during lifetime of same person, depends on technology, experience, type of project and other factors.
Meanwhile the typical use is to look at some stereotype you have in head that has nothing to do with the project or position at question and then wonder why it did not worked out.
E.g. If they previously wrote compilers and you tasked them with graphics you'd see a book explaining affine transforms on their desk. Or parsing theory for the reverse transition.
A key part however is the ability to switch between fields. I've seen people I thought were 10x completely fail when tasked with something new.
His code had major issues, but that's not to say that he couldn't write software. He could, in a manner completely different from me. Amazingly well, yet frustrating.
Above a certain level, one developer isn't universally better than another. It's not linear any more.
He's a CS professor now.
It's a case where the whetstone sharpening the knives also gets sharper by virtue of what they learn from the juniors they mentor.
OTOH there is a cycle I see everywhere, all the time:
* A first generation of anything is bare-bones, with multiple deficiencies and corners cut, with important parts held together by duct tape.
* A second generation of the same thing tries to fix everything, adds reams of missing features, and ends up being an over-complicated, bloated monster [second system].
* A third generation of the same thing builds on the knowledge gained so far, refines the ideas, throws away all the unneeded parts, and organizes the few necessary parts elegantly and reliably.
(I use indefinite articles before "first", "second", and "third", because each may take much more than one iteration.)
Your hyper-productive developers likely produce the first two varieties. This may still be very useful, if they allow the business to grow. They as well may introduce too many technical problems and operation costs, and thus be detrimental to the business, too.
[second system]: http://wiki.c2.com/?SecondSystemEffect
(Edited: typos.)
Fake 10x: Turns out lots of stuff quickly but it crumples under edge cases and has non-obvious tight couplings that keep biting you. No one else can make changes to their code. None of their stuff can really be used when they leave the company, but they can fix it really fast.
Real 10x: Is able to explain what they did and why bugs happened. Easy to follow along in their code, you get the impression the job was easy. You constantly find yourself turning to their old solution, when it really matters, rather than the new way everyone's trying to migrate to. Suggests ways their existing system can handle new business use-cases with only a trivial modification. You keep trying to improve upon their work but keep concluding that there was a good reason for all their decisions.
Depending on the context, someone might be referring to one or the other.
Almost all real jobs are mostly grind.
Even startups ... a good one, is 99% stupid, annoying details, some of which would be fun if you were not so busy.
Airtable.
What a cool app! In the news today.
"But I have to get fing xyz done fing now, so abc can ship out to Hong Kong before 5 hurry up!"
So there's not time to search, explore, try it out, it's just a very rapid short query to figure out the essential basics and move on.
Early stage is all a grind and there's nary a moment in between.
Apologies for the language.
Nobody should claim washing dishes is inherently wasteful or pointless. Legacy code on the other hand, comes with a lot of social pressure to just layer on more debt.
The person who grinds through the boring stuff while thinking about how to automate it so they don't have to be bored anymore, is the person I want to hire.
The comparisons being made to washing dishes aren't realistic.
The important part is noticing and recognizing things that are ripe for automation, rather than accepting the shitty world as it is and continuing to suffer through repetitive work that could've been automated.