But engineers blaming engineers that benefit from being a rational actor inside the mainstream incentive structure of corporate life is basically a distraction, because it gives management a pass for their mismanagement. Like, you don’t have to know the details, but it’s pretty fundamental to understand / recognize / triage tech debt.
Persuasion and honesty are great tactics with good managers. With bad managers they tend not to work. Bad managers will demand bad software and only be happy when they find someone to deliver it.
Pete's got a choice about whether or not to act with integrity, same as everyone else at pretty much every other fork in the road. If management orders you to do something stupid, ways to act with integrity might include: you can say no, or you can do it under formal or informal protest, or you can do it under the condition that related technical debt is prioritized in a timely fashion, etc. There are usually many options for a proportionate response. Design docs with some formal structure will often increase accountability, or since management isn't reading the code anyway perhaps a bare minimum is a comment for posterity that says "Code written under duress. Senior manager SomeGuy said on SomeDate that this would be temporary and can be rewritten by OtherDate" ?
In terms of acting without integrity, sure it's possible to go through a career/life acting out endless scenarios where you basically enter into a conspiracy with your direct superior to screw the other people at your level and to a lesser extent the company in general, all so that you can possibly go one rung up the ladder and do the same thing again. Setting aside the ethical question of how this effects others, and whether or not this is a soul-crushing and dehumanizing thing for Pete to do to himself.. my guess is that most engineers will avoid this mainly just because they'd find ladder-climbing more boring than problem-solving.
> Management are not there to be defied. [..] Bad managers will demand bad software and only be happy when they find someone to deliver it.
Oof. Lucky that when people talk about engineers working "down in the trenches" or "on the front lines" it's usually just making apps or whatever and not actually soldiering, otherwise the whole "just following orders" thing can get ugly. Bad outcomes may always happen regardless, but it makes a big difference to me whether I'm the one that's responsible.
That's the norm, isn't it? The bulk of product managers aren't even technically oriented, let alone software engineering experts with a deep understanding of their own codebases.
Once I worked with a PM that quite openly stated he had to google what was a frontend and a backend developer and still failed to get a clear idea of what they did. How do you explain concepts such as technical debt to this sort of character?
If you refuse to explain relevant concepts to your PM, as a neighbouring commentor suggests, that increases the knowledge gap between you (or your team) and the PM. I think it's in the best interest of both the team and the PM that they have a shared understanding of what happens within a project. On the other hand, if the PM is not interested in any of those details, that is a sign that they might not be a good fit in that part of the organisation.
Sure it happens often because tech is a very profitable, grifter magnet, but we really shouldn't normalize it nor expect to solve what is ultimately an organizational problem.
If you are an engineer with a reputation of getting things done, they will listen to you. They may not always follow your recommendations, but often they have context you do not have.
Admittedly, some managers are just ladder climbing batards who will make bad calls regardless.
