[_red]

As a manager of a dev group, I've migrated away from trying to hire "10x developers" and now optimize for "intelligent and persistent".

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.

[SilasX]

I think there's "10x" and then there's real 10x.

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.

[taneq]

Exactly. There are cowboys and then there are master crafters. Both will rapidly produce awesome results, but the cowboy's results are messy, fragile and temperamental, while the master crafter's results are robust and easy to understand.

[tomaskafka]

This. I understand 10x as a kind of person who creates MapReduce and writes very convenient abstraction around it that anyone can use and become 2x.

[nine_k]

It takes repetition: code is a liability. The less code you produce to solve your problem, the better.

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

[friendly_chap]

That's not a 10x developer if they don't know how to write maintanable software, you just thought they are.

The dev you describe sounds like a junior who can crank out code at high velocity.

[AWildC182]

This is why the 10x is a unicorn. HN likes to shift the definition every time it's found to have some quality we don't like. In the real world there is a broad spectrum of devs and their capabilities. Each one has strengths, weaknesses, areas of expertise, and character flaws. You'll basically never find one that just blindly produces 10x the code of the rest of your team without some downside.

[slededit]

They are Unicorns but you know them when you see them. Cranking out code at high velocity that looks and feels right. When they don't know how to do something they actually research and look at the field. If no prior art exists at all (they frequently find themselves in this situation) they're already on their third iteration before anyone else has a prototype - even they can't get it perfect the very first time.

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.

[strken]

I reckon that if there's such a thing as a 10x dev, they'd act as a force multiplier rather than a faster assembly line worker. Fixing architectural problems early raises the productivity of everyone who ever has to touch the code, as does setting up practises like code review and automated testing, and as does culling bad features early on.

[peteradio]

I agree and it might not be possible to recognize such a person as a 10x dev.

[watwut]

Imo, the whole concept is idiotic and serves nothing.

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.

[Arnt]

I've met someone who I'd call 10×. I've worked with him. He once wrote a usable spreadsheet, with a fine set of formulae and an entirely plausible UI, in an evening and a night.

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.

[rcavezza]

This is so interesting. I have met many people that others considered "geniuses" because they solved hard problems and got things done fast. And then 3 years later, people still complain about having to deal with "[Name of Developer] Code". I guess if you move fast and write code that others can't read, it's easy to get labeled a genius.

[saiya-jin]

Yeah, I kind of moved of definition of good code from cool-smart-novel approach to something as simple as possible, that almost anybody can pick up, maintain and improve. This has various aspects - cleanness of the code, comments of algorithms/edge cases, overall structure, modularity etc.

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.

[Swizec]

> And then 3 years later, people still complain about having to deal with "[Name of Developer] Code"

You're saying their code was so good it survived 3 years of real world use and project evolution. That's extremely rare.

[slededit]

Counter intuitive, like the "put the armor where the bullet holes aren't" story about WWII bombers.

[ohithereyou]

The best way to get a 10x developer is to have a productive senior closely mentor 10 juniors - pair programming, code reviews, testing strategies, deep dives into architecture, bi-directional knowledge sharing.

It's a case where the whetstone sharpening the knives also gets sharper by virtue of what they learn from the juniors they mentor.

[astrodust]

Unless you can coach and pivot someone from that "must make everything perfect" mentality to one where they can take a more pragmatic approach to things.

[kradroy]

This is really hard. Really hard. It can take years to get an engineer to that sweet spot.

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.

[astrodust]

This is part of a larger spectrum of developer preferences: openers, sustainers and closers.

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.

[kradroy]

I disagree that "closer" is a distinct class. It's a necessary aspect in any class. In most companies if you don't "close", you get fired or put on a PIP (and you don't get coffee). There is another class that at some companies where closing isn't necessarily expected: "tinkerer". They just mess around with various projects to learn and make suggestions, but they don't have to close to keep their job.

[astrodust]

I'm trying to distinguish between responsibilities and obligations, which you're forced to adhere to, and affinity.

Anyone can close if they're forced to, but some people actually like it. Clear objectives, solutions need to be focused, etc.

[ballpark]

I've never heard it stated that way, but I can strongly identify with this. After 18 yrs in the industry, I am finding more and more that I enjoy improving much more than building.