4 ms·

> Leadership does not trust the grunts to do productive work Not only that, but unfortunately they are usually right. Without oversight the in-house team has h

> Leadership does not trust the grunts to do productive work Not only that, but unfortunately they are usually right. Without oversight the in-house team has high likelihood of building NIH spaghetti, which causes more problems down the line. To avoid the negative outcome leadership needs to be technically competent and resourced, and that's the other side of the coin - usually they don't have the expertise so in a way they also do not trust themselves to lead the project to a positive outcome.

danaris 2y ago
> Without oversight the in-house team has high likelihood of building NIH spaghetti I think when you see this you need to start digging deeper and questioning why this is happening. Is it because the "grunts" are genuinely bad at their jobs? If this is the case, then who hired them? Or is it because they have been conditioned to believe that if they ask for permission to use an outside tool/library/etc, they will be told "no, we don't have the budget for that" or "that has to go through 12 layers of approval" or "great idea! we'll get it into a committee to talk about the best way to implement it and get back to you (in 6-12 months)"? In other words: Are they building NIH spaghetti not because they lack oversight, but because they have too much, that hampers them from actually doing their damn jobs?
- cruffle_duffle 2y ago
  Don’t forget incentive structures that award developers for “org wide impact”. Often the way to do that is to roll your own crap instead of use off the shelf stuff. This is how you wind up with developers creating their own key-value databases or billing systems… it sounds much better to write these from scratch.
- Terr_ 2y ago
  I'd like to add that NIH spaghetti sometimes comes from customer relationships rather than from exuberant developers. The important customer wants just one tiny convenience-feature that fits their use case and it sorta makes sense... Which somehow keeps scope-creeping over time into a cancerous unplanned product which is expensive to support. With the benefit of hindsight, you realize it's something the customer should have bought directly for themselves from a completely separate and more-qualified vendor. However they either didn't realize what they wanted or they were able to trick you into building an over-specialized product for their use case--for much cheaper than if they had hired a contractor to customize another better offering.
throwaway82931 2y ago
> they are usually right. This message encapsulates why so many software jobs are terrible. Put your heart and soul into doing your best, earnestly combat NIH and pursue meaningful productivity, and _still_ the culture is such that at many companies, there will never be trust because the prevailing culture is that management is "usually right" that grunts can't be trusted. I've worked for good bosses that aren't like this, but they're hard to find.
- foobarian 2y ago
  Clean up enough messes left behind by grunts that were trusted by management and you will be cynical too :-)
  - aiisjustanif 2y ago
    I still blame the management here for not building a team where quality and foresight matter enough to avoid large messes. Trust from management isn’t all that is needed for good work to be accomplished, good managers of software development also should not shockingly know good software development. I swear software and tech related roles are one of the few places where the managers don’t also know how to do the job of their reports.
    - oopsallmagic 2y ago
      [flagged]
    - oopsallmagic 2y ago
      [dead]
  - oopsallmagic 2y ago
    Concur. It's an unfortunate race to the bottom which is just indicative of the dilution of ability in this godforsaken industry. Why can't a team of grunts manage a basic CRUD web app? That's what's so frustrating: most of these problems aren't even _hard_, and yet devs screw them up anyway. Signed, a greybeard sick of cleaning up messes.

danaris 2y ago

> Without oversight the in-house team has high likelihood of building NIH spaghetti I think when you see this you need to start digging deeper and questioning why this is happening. Is it because the "grunts" are genuinely bad at their jobs? If this is the case, then who hired them? Or is it because they have been conditioned to believe that if they ask for permission to use an outside tool/library/etc, they will be told "no, we don't have the budget for that" or "that has to go through 12 layers of approval" or "great idea! we'll get it into a committee to talk about the best way to implement it and get back to you (in 6-12 months)"? In other words: Are they building NIH spaghetti not because they lack oversight, but because they have too much, that hampers them from actually doing their damn jobs?

cruffle_duffle 2y ago
Don’t forget incentive structures that award developers for “org wide impact”. Often the way to do that is to roll your own crap instead of use off the shelf stuff. This is how you wind up with developers creating their own key-value databases or billing systems… it sounds much better to write these from scratch.
Terr_ 2y ago
I'd like to add that NIH spaghetti sometimes comes from customer relationships rather than from exuberant developers. The important customer wants just one tiny convenience-feature that fits their use case and it sorta makes sense... Which somehow keeps scope-creeping over time into a cancerous unplanned product which is expensive to support. With the benefit of hindsight, you realize it's something the customer should have bought directly for themselves from a completely separate and more-qualified vendor. However they either didn't realize what they wanted or they were able to trick you into building an over-specialized product for their use case--for much cheaper than if they had hired a contractor to customize another better offering.

throwaway82931 2y ago

> they are usually right. This message encapsulates why so many software jobs are terrible. Put your heart and soul into doing your best, earnestly combat NIH and pursue meaningful productivity, and _still_ the culture is such that at many companies, there will never be trust because the prevailing culture is that management is "usually right" that grunts can't be trusted. I've worked for good bosses that aren't like this, but they're hard to find.

foobarian 2y ago
Clean up enough messes left behind by grunts that were trusted by management and you will be cynical too :-)
- aiisjustanif 2y ago
  I still blame the management here for not building a team where quality and foresight matter enough to avoid large messes. Trust from management isn’t all that is needed for good work to be accomplished, good managers of software development also should not shockingly know good software development. I swear software and tech related roles are one of the few places where the managers don’t also know how to do the job of their reports.
  - oopsallmagic 2y ago
    [flagged]
  - oopsallmagic 2y ago
    [dead]
- oopsallmagic 2y ago
  Concur. It's an unfortunate race to the bottom which is just indicative of the dilution of ability in this godforsaken industry. Why can't a team of grunts manage a basic CRUD web app? That's what's so frustrating: most of these problems aren't even _hard_, and yet devs screw them up anyway. Signed, a greybeard sick of cleaning up messes.