3 ms·

> because they don’t get “respect” Nah, that's not what the blog post says. It says engineers aren't given sufficient responsibility, so that they can assume t

> because they don’t get “respect” Nah, that's not what the blog post says. It says engineers aren't given sufficient responsibility, so that they can assume the respective blame, when something goes wrong. If an engineer says it would take 1 month to build a feature so it's sufficiently reliable, and the manager says "nah that's ridiculous, you have 1 week", then when the cobbled together feature breaks in production the manager should take the blame, since they effectively took the responsibility away from the engineer, upon themselves.

9dev 2y ago
I used to think that way, until I had my own junior developers, and felt like that guy trying to bake a cake with three beagles: They veer off, constantly, in all directions. Developers deep in the trenches tend to have a bad feeling for business requirements or constraints; coupled with a knack for perfectionism and premature optimisation, that really often results in ridiculous time frames that are just plain unrealistic and would ruin the organisation long term. I don’t have any profound insights, though: The only sane mantra can be keeping things in balance. Too much management, you drive your devs insane; too much engineer control, and the architecture astronauts reinvent the wheel every other day.
- strken 2y ago
  It's hard to tell whether perfectionism means doing a pointless refactor to cloud microservice event-driven k8s buzzword Rust WASM-on-the-server sharded graph databases, or whether it means spending 30 minutes putting a password on that MongoDB instance your data science team wants to load prod data into.
  - 9dev 2y ago
    Yeah, exactly. That’s why you want a culture of collaboration between engineers and managers to come together and decide what is important. It’s just hard to keep that up in practice, especially if a company grows.
- happymellon 2y ago
  > Developers deep in the trenches tend to have a bad feeling for business requirements In my experience, this is because the developers are removed from interacting with the business. How are they supposed to make good decisions if they don't talk to their customers and understand what they are aiming for? And I don't mean have the business folks show a roadmap once a year.
  - 9dev 2y ago
    I wasn’t assigning blame here, but rather preaching the virtues of balancing the interests of engineering and business folks.
- mondrian 2y ago
  > They veer off, constantly, in all directions. I have a similar opinion of being micromanaged. The micromanager is like a chaos demon that keeps pointing me in random directions. I lose all internal vision / intuition and turn into an unhappy task robot.
AmericanChopper 2y ago
> If an engineer says it would take 1 month to build a feature so it's sufficiently reliable, and the manager says "nah that's ridiculous, you have 1 week" This is just standard corporate accountability avoidance on the side of the engineer though. Most people don’t want to be accountable for any risk so they advise against it, or give impractical advice, so that somebody else has to make the decision and hold the accountability.

9dev 2y ago

I used to think that way, until I had my own junior developers, and felt like that guy trying to bake a cake with three beagles: They veer off, constantly, in all directions. Developers deep in the trenches tend to have a bad feeling for business requirements or constraints; coupled with a knack for perfectionism and premature optimisation, that really often results in ridiculous time frames that are just plain unrealistic and would ruin the organisation long term. I don’t have any profound insights, though: The only sane mantra can be keeping things in balance. Too much management, you drive your devs insane; too much engineer control, and the architecture astronauts reinvent the wheel every other day.

strken 2y ago
It's hard to tell whether perfectionism means doing a pointless refactor to cloud microservice event-driven k8s buzzword Rust WASM-on-the-server sharded graph databases, or whether it means spending 30 minutes putting a password on that MongoDB instance your data science team wants to load prod data into.
- 9dev 2y ago
  Yeah, exactly. That’s why you want a culture of collaboration between engineers and managers to come together and decide what is important. It’s just hard to keep that up in practice, especially if a company grows.
happymellon 2y ago
> Developers deep in the trenches tend to have a bad feeling for business requirements In my experience, this is because the developers are removed from interacting with the business. How are they supposed to make good decisions if they don't talk to their customers and understand what they are aiming for? And I don't mean have the business folks show a roadmap once a year.
- 9dev 2y ago
  I wasn’t assigning blame here, but rather preaching the virtues of balancing the interests of engineering and business folks.
mondrian 2y ago
> They veer off, constantly, in all directions. I have a similar opinion of being micromanaged. The micromanager is like a chaos demon that keeps pointing me in random directions. I lose all internal vision / intuition and turn into an unhappy task robot.

AmericanChopper 2y ago

> If an engineer says it would take 1 month to build a feature so it's sufficiently reliable, and the manager says "nah that's ridiculous, you have 1 week" This is just standard corporate accountability avoidance on the side of the engineer though. Most people don’t want to be accountable for any risk so they advise against it, or give impractical advice, so that somebody else has to make the decision and hold the accountability.