[joshdev]

All jobs have some amount of grind. Being able to acknowledge its going to suck and push through it quickly can be super beneficial to your career. It's also one of the reasons why I encourage those in high school or college to try a non technical job first. Learn to appreciate doing monotonous tasks well.

[_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.

[sonnyblarney]

"All jobs have some amount of grind"

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.

[mlevental]

learning to appreciate monotonous tasks is too zen/enlightened (like someone in another thread weeks ago saying they enjoyed washing to dishes) and therefore sets the bar too high. but learning to persist and endure (by way of coping mechanisms e.g. music, short breaks) is very possible.

[bonniemuffin]

I definitely don't want my team to appreciate boring tasks! I want them to persist, endure, and then automate.

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.

[WalterSear]

The nature of the work doesn't allow that. Coding takes all your thought - even when it's boring and monotonous.

The comparisons being made to washing dishes aren't realistic.

[bonniemuffin]

Sorry for the ambiguity: I didn't mean literally at the same time like washing dishes while dreaming of dishwashers. I mean, like, do some boring coding drudgery one day/week/month, and then the next day/week/month do a bit of dreaming and whiteboarding of how to automate a better world, and then we can prioritize and make time for the automation work to make the better world a reality.

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.

[dageshi]

I agree with this, boring & monotonous code tasks are basically excruciating because you've got to concentrate on them hard and yet you'd rather be doing just about anything else.

[nradov]

I've done some refactoring work that didn't take any more mental effort than dish washing.

[WalterSear]

Sure. Is most work like that, though?

[bootsz]

There's also different kinds of boring/tedious though. I'd argue it's much easier to learn to enjoy washing your dishes at home than it is to enjoy slogging through trying to grok horrible legacy code. Maybe that's just me though.

[chrstphrhrt]

I agree. Especially if there are other teammates who defend the bad codebase because of their association to it.

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.

[devonkim]

Maybe I’m just weird but I’ve never really defended my code because I never found defensiveness to be helpful for moving projects forward. In fact, most of the code I’ve put out in my career has been rushed under pressure to deliver something fast so most of the time I’m distancing myself from the work usually saying “that wasn’t written by me, it was my evil twin that comes out at 2 am.” Trying to fix the problems of the past that keeps your codebase from improving at a better pace isn’t something shameful to me as much as a matter of pride - that you have learned from your mistakes and are not above reproach. The best stuff for me is what I do after iterating many times without fear of breaking anything though and that’s exactly what you would hope from a codebase matured through TDD.

[joshdev]

That's fair. When I say appreciate, I mean the results of the grind. Washing Dishes or any type of cleaning isn't fun, but finding coping mechanisms (zoning out, music, etc...) you can enjoy the results.

[JustSomeNobody]

I agree. A lot of the devs I know who had non tech jobs have a better appreciation for business decisions and management than do those that just went into a dev job.