Hacker News Reader

Comment by anotherhue | Hacker News Reader

High performers tend to get bored with the reality of most development. This usually presents as over-enginerring and a reluctance to do dull but necessary tasks.

Over time the risk of them leaving builds and others are reluctant to take on their mantle (complex code, assumed overtime, whatever). I've never been able to hire a high performer with the remit of 'please take over this complex and custom system your predecessor built and walked away from' - such people want to build that stuff themselves and someone else has already had the fun.

Businesses want reliability and predictability, your high performance is probably better spent on your hobbies, or your own (ownership >= 10%) businesses.

High is relative to other team members so I suspect this is true no matter the baseline skill.

View on HN

One of the easiest ways to be a 10x dev is to sabotage the productivity of every other dev on your team. I suppose it’s often not consciously intentional, but that’s the end result when you ship features at a breakneck rate using the bolt-on pattern. That being the one where every new feature is bolted on to the existing code without ever bothering to refactor or otherwise slow down and consider the design as a whole. The end result is the 10x dev runs the technical debt printing press hard and fast, and then once he perceives that the system is about to collapse under its own weight, he moves on to another project. Meanwhile whatever sucker takes over responsibility gets left holding that bag and the almost inevitable PIP that comes with it.

One of my more gratifying mentorship experiences was having one of the devs I advised come back to me years later and tell me how much my teaching him to recognize this phenomenon helped his career.

I don't think someone who cranks through 10x more features while leaving loads of debt behind them is a 10x engineer.

In general you could think of all software development as a heap of hacks. It gets taller and taller and taller until it falls over. What you are describing is someone who makes the heap a lot closer to falling over. The ideal of a 10x engineer is someone who makes the heap more stable, someone whose architectural contributions make it possible to have a higher heap and allow others to do more/better work. Over the long term a 10x engineer's product is the capacity for more growth.

Mentorship is certainly one way to get a longer lever to stand on -- a way of making investments in the future, but even feature dev can fit the bill: https://thedailywtf.com/articles/the-cool-cam

Ive seen this happen wayyy too frequently. My general perspective now is to never ever trust tech blogs or hype until youve seen a system work in production. 99% of the time its a polished turd for some dumbfucks promo packet.

Your definition of high performers seems different from the articles. How can someone be a high-performer if they don't maintain a system they are involved with, or consider how it will be maintained by others if they move on?

I see lots of really good Devs who love the details and making sure they are communicated well, writing code that is understandable and time on ensuring regular maintenance and upgrades are carried out or better still automated, but most importantly spreading that knowledge around the team.

It does sound like you have considered these things, just your definition of high performers seems like it could do with a rethink.

In every big company high performer means “ships, a lot.”

That’s one of the benefits of a higher job level. You get to claim credit for shipping everything you had a hand in even when your contribution was often little more than organizational presence. Which is to say, being the “face” of the project to upper management.

Doesn't reflect my experience of working in many organisations. Not to say I haven't seen what you describe, but only in the more dysfunctional ones. Maybe the issue is more the "low performing management"

I dunno, the best devs I know get bored but spend that in thinking a lot about how to make things simpler and with less. It's equally as challenging as over-engineering if not more so.

>High performers tend to get bored with the reality of most development. This usually presents as over-enginerring and a reluctance to do dull but necessary tasks.

Oh hell yes. This exactly matches my experience. To the point where I actually consider high performers a detriment to the overall effort. I have been the most happy with mediocre, cooperative people in the team.

I would say it is basically the same on all levels. Devs just want to rebuild everything all the time and most of the time reasons are made up - real reason is they want to make it themselves their way.

> real reason is they want to make it themselves their way.

I have a different theory. I think the real reason is that writing code is easier than reading. Literally, it's psychologically more comfortable to write code than to read it.

Which is why adding tests is a great way to get to understand a codebase.

This is part of it that I agree with.

Downside is those devs forget that in 3-6 months of not working on that part will have the same feelings.

I work on the same system for 10 years now, I moved to a more dev ops position and don't write that much code, when I pick up some ticket I am really amazed to find out code that I am working on changing for the ticket is something I wrote a year or two years ago and I have no memories of writing that because I was doing thousands other tasks in different places of the system.

This might be true sometimes, but it hardly addresses the real problem: WHY are (some) devs like that?

From experience I'd say that there are at least three (usually overlapping) reasons:

- There are often valid technical reasons to rewrite at least parts of the codebase. Most companies tend towards a "don't fix it if it isn't broken" policy, which tends to lead to most components being in a "not far from broken due to poor maintenance" state. It is reasonable to want to fix those up before they cause an outage. An ounce of prevention saves a pound of cure and all that.

- Making new things is more "fun" in one way or another, even if it is just because trying to grok the spaghetti code of another is "not fun".

- The dev in question has (usually correctly) identified that the way to get more of what they want, be it money or power or fun colleagues or interesting projects, is to be involved in building new things. It's no secret that humans often ascribe more value to those who make new things even if it's not justified.

Unless the environment becomes such that these three get mitigated, devs will always want to rewrite things as they are heavily incentivized to do so.

College should redesign the courses, the job is software reengineering.

Meanwhile, universities should research the "One Right Way of Writing It" to defeat reengineering when possible.

Most people who have studied this field we're in have gained Computer Science degrees. These courses often don't prepare the student for working as a SWE.

I work with more graduates of Russian than I do Software Engineering.

> Over time the risk of them leaving builds and others are reluctant to take on their mantle (complex code, assumed overtime, whatever). I've never been able to hire a high performer with the remit of 'please take over this complex and custom system your predecessor built and walked away from' - such people want to build that stuff themselves and someone else has already had the fun.

Let me read between the lines here and assume the worst, then please correct me and tell me it doesn't apply to you.

A left. High performer candidate B didn't want to pick up A's stuff. Let's say it was over-engineered or over-complex or whatever. You ended up hiring C, and C was not a high performer. In fact, a wild guess: you hired two C's at the price of one A.

Perhaps your preference was to hire two "everyone is replaceable" C's all along? That's not to say that some projects are not more suited to low performers. But the engineering management style can tip the scales no matter what.

Depends on how you define “high performer”.

Someone who doesn’t want to take over someone else’s code deep dive and understand it first is not high performer in my understanding.

Efficient debugging and understanding systems other wrote or created is basic requirement for high performing dev in my opinion.

Life is too short to want to spend it grovelling around in the shit left behind by other people.

There's a fundamental difference between being able to rip apart a ball of mud and rebuild something sane out of it and being excited to do that for a pittance.

There is a world of difference to rip something apart and rebuild just for one person ego and actually serving other people’s needs.

Isn't pittance the key word here?

Yep. I think there's a correlation between expecting people to joyfully do very boring things and believing they should do it cheaply.

I think we're conflating skill with performance. The hiring system should be assumed to filter for a baseline skill, when I say performance I really mean output.

A high output team player is gold and we want as many as possible. A high output singleton will likely have sacrificed some element of quality or maintainability or thoroughness or likely even their own personal lives to reach that output, for the projects they enjoy doing.

That output is unlikely to translate into a new, less interesting project and if the work or system is now structured to require that level of output then few would want to take up the position.

The over used canoe metaphor is useful, you want people to pull at the same speed. I also enjoy the 'always be leaving your job' approach that guides people away from building themselves into the system.

Let me rephrase. Let's say you're writing textbooks instead of code. You need Ivy League PhD's to write grad school textbooks, but not grammar school ones. Here are two crappy scenarios I was thinking about:

- You choose to write grammar school textbooks just so you can hire cheaper writers.

- Or worse, you're required to write grad school textbooks but you still hire cheaper replaceable writers.

We are conflating skill with performance, but the 10x theory (IIRC) is that they are correlated, or at least can be given the proper motivation.

Team players are always better than singletons, so let's assume there's no correlation there (which may be a stretch, sure.)

> I've never been able to hire a high performer with the remit of 'please take over this complex and custom system your predecessor built and walked away from' - such people want to build that stuff themselves and someone else has already had the fun.

Are you hiring right now, cos this sounds like fun?

(modulo the likelihood that our definitions of high performance differ).

Is it the case that high performers are bored by it? Or companies don't reward it with promotions?

Reply on news.ycombinator.com