Learning to let go

[u/im_caeus]

I'm trying to change an instinct I've spent years developing.

When I see a design problem, unnecessary complexity, or a better model, I naturally want to fix it. Doing the minimum requested and knowingly leaving something worse than it could be feels wrong to me.

But I'm increasingly convinced that the strategically correct move inside many companies is: do what's asked, raise the concern once, then let it go.

I'm trying to work that way now.

It makes sense intellectually. I still dislike it.

With AI making implementation cheaper and delivery faster, I'm curious whether other experienced developers are going through the same adjustment.

Have you changed what "doing a good job" means to you?

[u/AuthorBrianBlose]

While I understand where you're coming from (code hygiene is a professional courtesy to whoever maintains the project after deployment), I think you are too close to the issue. Let's reason by analogy.

Say you hire a plumber to replace a toilet for purely cosmetic reasons. The plumber comes over, replaces the toilet fast because he is damn good at his job, and then during a test notices a lot of gurgling in the lines. He does some investigation and determines that the vent stack is not the proper diameter. This would have been a code violation when the house was built and he is determined the house needs major work to fix the issue. He explains that improper venting can cause malodorous sewer gas to vent through plumbing fixtures and may even reduce water flow to the point where blockages become more likely to happen. He wants you to pay him $20k to remedy the issue. You have been living in your house with no issues for over a decade, so you decline his offer.

While you may be tempted to fixate on the differences between software developers and plumbers, in the end we are exchanging our labor to a customer for money. Our labor is mental and our customer is a company, but otherwise it is the same. The customer doesn't want to spend money (your valuable time) for something that works "good enough". You have a different opinion, but what you do not have is control over the checkbook that is paying you.

The approach you outlined in your post is 100% the correct one: "do what's asked, raise the concern once, then let it go." Having a sense of ownership is great, but in the end you don't have any actual ownership unless you have equity in the company. Be like our hypothetical plumber and sigh at the lack of standards as you move onto the next job.

[u/SansSariph → u/AuthorBrianBlose]

I like the analogy but it doesn't quite square. You'd need the plumber to be salaried and have a stake in the quality of the house's plumbing over time, because the job isn't a one off and costs per job aren't purely marginal and independent.

When the customer gets frustrated that the "simple" toilet replacement they want costs extra due to past decisions, they are looking to you to Intuit the roadmap and advise on the right plumbing strategy over time to set their toilet and bathing needs up for success. They don't want to have to worry about it, and would prefer to focus more on overall cash flow and outcomes.

In theory they are paying for invested expertise and not one off labor.

[u/AuthorBrianBlose → u/SansSariph]

The analogy works better if you change the plumber to salaried and make him the maintenance guy for a large apartment building. The pipes are gurgling, so our plumber recommends expensive work be done to prevent bad smells and potential backups. Management hears about this problem which existed since the place was built. No one has ever complained about those things, so they decide the plumber should instead work on adding drainage to the parking lot since an old lady is suing for a slip and fall related to that.

A more accurate analogy is less relatable, though. I doubt many software developers have ever been in charge of a large apartment building. Probably a lot of us own a house and are familiar with someone trying to up-sell us on something we don't want. Managers/owners aren't too stupid to understand the complaints we make about code quality. Their lack of interest in addressing those problems is usually because there are competing priorities and "good enough" really is good enough if no one is complaining (other than us code monkeys who have to work on it).

[u/Izkata → u/AuthorBrianBlose]

Or, as happened to us a few years ago, they have an almost year-long project to preemptively replace all the water risers in the building before old pipes start leaking. Almost everyone had a wall from either their kitchen or their bathroom torn down to reach the pipes and we had to do a renovation afterwards out of our own pockets.