4 ms·

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 task

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.

ozim 2y ago
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.
- kjrfghslkdjfl 2y ago
  > 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.
  - disgruntledphd2 2y ago
    Which is why adding tests is a great way to get to understand a codebase.
  - ozim 2y ago
    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.
- WJW 2y ago
  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.
NomDePlum 2y ago
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.
- User23 2y ago
  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.
  - NomDePlum 2y ago
    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"
worstspotgain 2y ago
> 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.
- ozim 2y ago
  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.
  - JonChesterfield 2y ago
    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.
    - ozim 2y ago
      There is a world of difference to rip something apart and rebuild just for one person ego and actually serving other people’s needs.
    - worstspotgain 2y ago
      Isn't pittance the key word here?
agumonkey 2y ago
College should redesign the courses, the job is software reengineering.
- worstspotgain 2y ago
  Meanwhile, universities should research the "One Right Way of Writing It" to defeat reengineering when possible.
- walthamstow 2y ago
  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.
kjrfghslkdjfl 2y ago
[dead]
User23 2y ago
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.
- conartist6 2y ago
  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 https://thedailywtf.com/articles/the-cool-cam
- pm90 2y ago
  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.
disgruntledphd2 2y ago
> 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).
spencerchubb 2y ago
Is it the case that high performers are bored by it? Or companies don't reward it with promotions?
npteljes 2y ago
>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.
packetlost 2y ago
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.

ozim 2y ago

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.

kjrfghslkdjfl 2y ago
> 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.
- disgruntledphd2 2y ago
  Which is why adding tests is a great way to get to understand a codebase.
- ozim 2y ago
  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.
WJW 2y ago
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.

NomDePlum 2y ago

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.

User23 2y ago
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.
- NomDePlum 2y ago
  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"

worstspotgain 2y ago

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

ozim 2y ago
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.
- JonChesterfield 2y ago
  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.
  - ozim 2y ago
    There is a world of difference to rip something apart and rebuild just for one person ego and actually serving other people’s needs.
  - worstspotgain 2y ago
    Isn't pittance the key word here?

agumonkey 2y ago

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

worstspotgain 2y ago
Meanwhile, universities should research the "One Right Way of Writing It" to defeat reengineering when possible.
walthamstow 2y ago
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.

kjrfghslkdjfl 2y ago

[dead]

User23 2y ago

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.

conartist6 2y ago
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 https://thedailywtf.com/articles/the-cool-cam
pm90 2y ago
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.

disgruntledphd2 2y ago

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

spencerchubb 2y ago

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

npteljes 2y ago

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

packetlost 2y ago

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.