11 ms·

This is exactly why I think the "myth of the 10x engineer" is so obviously false. An average software engineer will create an overly complex system. If a skil

This is exactly why I think the "myth of the 10x engineer" is so obviously false. An average software engineer will create an overly complex system. If a skilled engineer can come in and create something that doubles team productivy, decreases bugs by 60% and improves retention across the org by 10x, that's huge! That's not a 10x engineer, that's a 100x engineer.

nerpderp82 4y ago
Engineers that make simple systems are not rewarded is most organizations. In a ten person company, sure thing! In a large corporate org, no way.
- dustymcp 4y ago
  Man the dead weight around development in corporations are mind numbing..
  - nerpderp82 4y ago
    The institutionalized brain damage is real, I see bright new hires coming in, within 3 months they are towing all the lines, spouting tautologies, seeking alignment with corporate velocity vectors to gain momentum, generate impulse. Talking in non-specific platitudes that could literally mean anything and thus mean nothing. The biggest problem with a simple architecture and often why someone would complexify it up, is as a protection mechanism so you don't get some performance review motivated yokel doing a drive by to add in a feature and look like a rock star because it was so damn easy. NSS, that was the next step. You see this in open-source as well. Someone builds a beautiful foundation, and Steve rolls up with a submarine pull request to slam that cherry on top. A complex architecture ensures that you can adequately gate keep. The next aspect is you have to relentlessly say no to feature requests that literally destroy the system to add some new feature, the pressure to smash it to bits and make it a no longer simple system is such a perverse incentive that unless you have support from on high, every simple system will decay into a total mess, then the finger-painters will have moved on to some other system to predate on.
    - babyshake 4y ago
      > non-specific platitudes Anything specific that tends to be used often?
      - nerpderp82 4y ago
        It is org specific, I have already triggered myself and need to find a safe space.
      - damiankennedy 4y ago
        "Move fast and break things". At 48 I've stopped fixing other people's things.
        runlaszlorun 4y ago
        Prob OT but ‘break things’ old Zuck sure did. A bit sad given the billions folks made in the meantime. I almost said that I’m surprised they weren’t held accountable… but we all know better.
      - bradstewart 4y ago
        Appealing to "best practice" without concrete, specific reasoning is a big one.
      - whstl 4y ago
        "We need to build something that scales" to justify virtually every single source of complexity.
        dahauns 4y ago
        Especially when then understanding of scaling only distinguishes between "unmaintainable monolith" and "full-blown web scale".
    - waynesonfire 4y ago
      I don't think it has to be so nefarious. What I've experienced is developers taking the path of least resistance and failing to perform proper analysis to arrive at a less complex architecture. Why are folks taking the path of least resistance becomes an interesting question.
  - WakoMan12 4y ago
    [flagged]
    - zaphar 4y ago
      On the chance that this is a real cry for help and you are in a really bad place, please seek help.
- pixl97 4y ago
  This is why small organizations produce stuff, then large organizations buy it and sell it as a product. As an engineer you just have to ensure you have equity in the small company before it's purchased and/or hope the big company buys your company rather than just copying it and fighting you in court for a decade.
- travisgriggs 4y ago
  Is this because as groups grow in size, high level decision making power tends to move up to less informed management individuals? You'll end up with a "I programmed a little bit back in the day" person who makes decisions based on how to currently keep their staff best utilized. Tools choices, boundary points, stacks, become chosen based on goals that are not rooted in design simplicity. I've watched this story play out again and again and again at companies. Upper management will promote these types of individuals into lower/middle management because a) they're deemed actually reassignable whereas a really talented Ux designer is obviously adding the most value doing that b) people buried/invested in tech stack/design details are harder for owner/operators to relate to than individuals more like themselves.
  - api 4y ago
    As groups grow in size it becomes increasingly hard to be informed as management. Eventually it becomes near impossible.
    - travisgriggs 4y ago
      And yet, somehow open source projects manage to have some degree of success with very little of anything representing “management”.
      - api 4y ago
        How many do, and how many of those see success outside their core highly technical user bases?
      - code_biologist 4y ago
        How many of the extremely successful open source projects have clear strong management that's one dude(ette)? Linux, Python, Ruby, Blender... Great delegation and engaging with community feedback productively are of course part of that strong management.
- kps 4y ago
  At a place I worked, they explicitly rewarded ‘solving complex problems’. It's actually surprising there weren't more cobra farms.
- deleted 4y ago
  [deleted]
iancmceachern 4y ago
Exactly this. I've done well for myself by focusing on building things that work, and shipping them on time. Anything else is extra and not to be done at the expense of the first two things.
- code_biologist 4y ago
  Would you build something simpler and more reliable if it took you from shipping a week early to a week late? I agree that anything else is extra, but most of my difficult professional engineering decisions are tradeoffs between those first two things: I can build on an older system less well adapted to current needs and deliver more quickly, or build something that fits current needs better but takes a bit longer. I sadly don't have enough days in life where there's a better and quicker option! Put differently, it's a lot faster to put another layer of duct tape on top of the last duct tape patch of a pipe leak. But every layer of duct tape you put on makes it more difficult to replace the pipe segment underneath. Developing judgement on when to do which is the (difficult) trick.
  - iancmceachern 4y ago
    If given that choice, we usually build both. We deliver the duct taped one one time so the software folks can start their work, and then we build the non-duct taped one wheel it in a week later and quietly swap it out for the duct taped one.
niels_bom 4y ago
Reminds me of “I apologize for such a long letter - I didn't have time to write a short one.”― Mark Twain
- hikarudo 4y ago
  That was Blaise Pascal.
  - runlaszlorun 4y ago
    Funny… I’d actually always heard it was Newton. I checked and looks like you’re def right here. I actually expected to find that it was a fake quote. Lately, I keep finding that many of the good quotes are actually fake. It’s like they actually survive on the value of the quote and, if we’re honest, whether someone decades or centuries ago actually said it is only tangential. But thx for the correction!
contemplatter 4y ago
That's not a 10x engineer, that's a 100x engineer. You're speaking of ChatGPT!

nerpderp82 4y ago

Engineers that make simple systems are not rewarded is most organizations. In a ten person company, sure thing! In a large corporate org, no way.

dustymcp 4y ago
Man the dead weight around development in corporations are mind numbing..
- nerpderp82 4y ago
  The institutionalized brain damage is real, I see bright new hires coming in, within 3 months they are towing all the lines, spouting tautologies, seeking alignment with corporate velocity vectors to gain momentum, generate impulse. Talking in non-specific platitudes that could literally mean anything and thus mean nothing. The biggest problem with a simple architecture and often why someone would complexify it up, is as a protection mechanism so you don't get some performance review motivated yokel doing a drive by to add in a feature and look like a rock star because it was so damn easy. NSS, that was the next step. You see this in open-source as well. Someone builds a beautiful foundation, and Steve rolls up with a submarine pull request to slam that cherry on top. A complex architecture ensures that you can adequately gate keep. The next aspect is you have to relentlessly say no to feature requests that literally destroy the system to add some new feature, the pressure to smash it to bits and make it a no longer simple system is such a perverse incentive that unless you have support from on high, every simple system will decay into a total mess, then the finger-painters will have moved on to some other system to predate on.
  - babyshake 4y ago
    > non-specific platitudes Anything specific that tends to be used often?
    - nerpderp82 4y ago
      It is org specific, I have already triggered myself and need to find a safe space.
    - damiankennedy 4y ago
      "Move fast and break things". At 48 I've stopped fixing other people's things.
      - runlaszlorun 4y ago
        Prob OT but ‘break things’ old Zuck sure did. A bit sad given the billions folks made in the meantime. I almost said that I’m surprised they weren’t held accountable… but we all know better.
    - bradstewart 4y ago
      Appealing to "best practice" without concrete, specific reasoning is a big one.
    - whstl 4y ago
      "We need to build something that scales" to justify virtually every single source of complexity.
      - dahauns 4y ago
        Especially when then understanding of scaling only distinguishes between "unmaintainable monolith" and "full-blown web scale".
  - waynesonfire 4y ago
    I don't think it has to be so nefarious. What I've experienced is developers taking the path of least resistance and failing to perform proper analysis to arrive at a less complex architecture. Why are folks taking the path of least resistance becomes an interesting question.
- WakoMan12 4y ago
  [flagged]
  - zaphar 4y ago
    On the chance that this is a real cry for help and you are in a really bad place, please seek help.
pixl97 4y ago
This is why small organizations produce stuff, then large organizations buy it and sell it as a product. As an engineer you just have to ensure you have equity in the small company before it's purchased and/or hope the big company buys your company rather than just copying it and fighting you in court for a decade.
travisgriggs 4y ago
Is this because as groups grow in size, high level decision making power tends to move up to less informed management individuals? You'll end up with a "I programmed a little bit back in the day" person who makes decisions based on how to currently keep their staff best utilized. Tools choices, boundary points, stacks, become chosen based on goals that are not rooted in design simplicity. I've watched this story play out again and again and again at companies. Upper management will promote these types of individuals into lower/middle management because a) they're deemed actually reassignable whereas a really talented Ux designer is obviously adding the most value doing that b) people buried/invested in tech stack/design details are harder for owner/operators to relate to than individuals more like themselves.
- api 4y ago
  As groups grow in size it becomes increasingly hard to be informed as management. Eventually it becomes near impossible.
  - travisgriggs 4y ago
    And yet, somehow open source projects manage to have some degree of success with very little of anything representing “management”.
    - api 4y ago
      How many do, and how many of those see success outside their core highly technical user bases?
    - code_biologist 4y ago
      How many of the extremely successful open source projects have clear strong management that's one dude(ette)? Linux, Python, Ruby, Blender... Great delegation and engaging with community feedback productively are of course part of that strong management.
kps 4y ago
At a place I worked, they explicitly rewarded ‘solving complex problems’. It's actually surprising there weren't more cobra farms.
deleted 4y ago
[deleted]

iancmceachern 4y ago

Exactly this. I've done well for myself by focusing on building things that work, and shipping them on time. Anything else is extra and not to be done at the expense of the first two things.

code_biologist 4y ago
Would you build something simpler and more reliable if it took you from shipping a week early to a week late? I agree that anything else is extra, but most of my difficult professional engineering decisions are tradeoffs between those first two things: I can build on an older system less well adapted to current needs and deliver more quickly, or build something that fits current needs better but takes a bit longer. I sadly don't have enough days in life where there's a better and quicker option! Put differently, it's a lot faster to put another layer of duct tape on top of the last duct tape patch of a pipe leak. But every layer of duct tape you put on makes it more difficult to replace the pipe segment underneath. Developing judgement on when to do which is the (difficult) trick.
- iancmceachern 4y ago
  If given that choice, we usually build both. We deliver the duct taped one one time so the software folks can start their work, and then we build the non-duct taped one wheel it in a week later and quietly swap it out for the duct taped one.

niels_bom 4y ago

Reminds me of “I apologize for such a long letter - I didn't have time to write a short one.”― Mark Twain

hikarudo 4y ago
That was Blaise Pascal.
- runlaszlorun 4y ago
  Funny… I’d actually always heard it was Newton. I checked and looks like you’re def right here. I actually expected to find that it was a fake quote. Lately, I keep finding that many of the good quotes are actually fake. It’s like they actually survive on the value of the quote and, if we’re honest, whether someone decades or centuries ago actually said it is only tangential. But thx for the correction!

contemplatter 4y ago

That's not a 10x engineer, that's a 100x engineer. You're speaking of ChatGPT!