This reminds me of some issues in my relationship. Some problems that never gets solved.
this post was submitted on 29 Dec 2025
483 points (99.8% liked)
Programmer Humor
28076 readers
945 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
As an aside, a Scottie dog called Haggis wearing a tam o' shanter is an adorable character for a children's book
This why any good engineer would bake it into their estimates when working around the area. I think Martin Fowler covers this in Refactoring. Eiher that or it was Kent Beck in TDD. Both books complement each other really well.
A good civil engineer doesn't ask a Project Manager if they can add in structural supports. A good software engineer shouldn't ask to build things right.
"Before we build x, we need to adapt the foundations by resolving x problem. If we don't get this right, it'll increase the chances of bugs surfacing in production and would make our team look like a joke."
Bad PO: "So it will only increase the chance of bugs if we don't do it? There won't necessarily be any. So we can skip it and just put the feature in."
I hope you have a good PO who is on the same page as you, but to a bad PO, it still sounds optional.
A civil engineer doesn't say "If we don't put supports there's a chance the ceiling will fall in and people may die," because history has shown there are plenty of unscrupulous project managers who are quite willing to take construction risks, even with people's lives. As a result of this there are now plenty of laws in construction, and a civil engineer has a convenient fallback of saying "If we don't put supports it won't pass inspection, and we won't get paid."
Everyone wants to get paid.
In software we don't have many laws we can fall back on to justify our work, but we can still treat our tech debt and refactoring as if it's equally mandatory.
"To add feature x, we need to resolve problem y. The feature can't be added until we've completed this prerequisite."
My current boss: so I sold this at least 10% below budget and we have to make it work.
Fuck that guy!
Sure, then you get outbid by another contractor who is willing to cut corners.
That’s why you should go work at big corporate enterprises. Then you have both job security as well as the ability to spend as much time as necessary on getting things right. And you might even learn to say no to middle management.
The big difference is a civil/structural engineer has to individually certify a plan sets and take legal responsibility for it. The project manager can't override them.
They can fire them and hire another engineer, but even if they found someone to stamp bad plans for a fee, the original engineer could report the new engineer and have their credentials yanked.
We don't have that in software engineering. And outside of critical software we don't need it. When the audio fucks up in Teams and you have to leave and re-enter the meeting, people don't die.
Fuck Teams. The buggiest, most crash prone mess I've even been forced to use. They keep bolting on new, unnecessary "features" that only selectively work on some of their "supported" platforms.
The difference there is that our project manager guy is afraid they're gonna go to prison if they don't let you add those supports and something goes wrong. But for the software dude, building things properly is unfortunately mostly a concern for you and the other software engineers, and mr project manager doesn't have that much of an incentive to let you do that
A good project manager understands technical debt.
Edit: moderately good
and the response will invariably be: “Is there a way we can just ship feature x now and fix up the other stuff after?”
Just increase your time estimate,
calculate in the time needed to refactor,
but don't tell them you're gonna refactor.
Works out most of the time.
Only when they ask why the estimate is so long, then you explain your reasoning behind it, and then they might reply with your statement and block your refactoring idea.
However, getting time to refactor most of the time, is aleady way better then never being allowed to do so.
How is this so accurate...
Oddly enough there are roof patch compounds that works in wet areas. Have used them
Resolution: Issue solved by applying patch.
translate from french
Outstanding.
I saved it for a new years mail for my company :)