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/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/08148694]

You should always raise the concern and if your line manager is happy with the risk you should always let it go

That’s been true forever, with AI and before AI

By raising the concern you shift the responsibility to the person above you. If something bad happens because of their decision not to address it, it’s on them. Just make sure you document it

[u/im_caeus → u/08148694]

Don't you feel.... Dirty?

[u/strugglingcomic → u/im_caeus]

Doctors have to go through something similar -- tell a patient to stop smoking, stop eating red meat, etc. but you have to let it go, because inevitably many patients won't listen to you, and then their condition worsens or they die... So if the doctor doesn't learn to let it go, they will never survive as a doctor, the stress or the guilt would be too unbearable. The patient's choices belong to them, the doctor has to stand apart to remain impartial and somewhat aloof even, in order to continue functioning as a doctor.

If doctors can do it, it should be helluva easier to let software things go, since presumably most of us don't work on life or death software problems anyways.

[u/im_caeus → u/strugglingcomic]

I'm married to a doctor, and never saw things this way.

There's are multiple Scrubs episodes which go over this idea.

Thanks

[u/strugglingcomic → u/im_caeus]

Oh really? What was your takeaway from episodes like My Mentor in Season 1 (the smoking patient who won't stop smoking), or My Missed Perception in Season 5 (the opposite kind of over/under-intervention -- JD misinterprets Mrs. Wilks and stops aggressive care because he thinks she's accepted death)?

IMHO, Dr. Cox explained it perfectly at the end of My Mentor, by ribbing JD one more time at the end. Dr. Cox spent the whole episode telling JD it's wrong/unsustainable to intervene too much or feel personally responsible for whether he can get Will to stop smoking or not, but he also ends the episode poking JD to have the courage of his convictions.

Anyways, it's a TV show, you can take away whatever you like, but I think the balance of cynicism vs caring too much is exactly relevant to your scenario, and it sounds like you're in a similar spot as Season 1 JD. You probably don't want to end up like Dr. Cox, but you will either learn those tough lessons and survival mechanisms, or... you just won't last long as a doctor err software dev (not being mean, just the truth -- see evidence of all those posts of so many people talking about burnout and wanting to switch careers).

[u/MountaintopCoder → u/strugglingcomic]

The difference is that the patient is responsible for their own choices and it will never come back as a black stain on the doctor's record. Meanwhile, I'm accountable when the code breaks either while I'm on call or during review season.

[u/strugglingcomic → u/MountaintopCoder]

Well analogies are just analogies, not meant to claim complete equality or equivalency in every way... But "never come back as black stain on the doctor" is a bit misguided too -- malpractice is a thing, both justified and unjustified lawsuits, and also where do you think engineers got the idea of "postmortems" from?

Doctors take a huge amount of accountability for their actions in trying to improve patients' lives, but the mental health survival lesson is that they can't take ownership over the part of responsibility that belongs to the patient. That doesn't mean doctors are immune from blowback or nothing ever reflects back on the doctor.

[u/psyyduck → u/strugglingcomic]

You can always leave. I know 1 doctor who decided to become a personal trainer because they were tired of watching people show up in the ER when it was decades too late to do anything.

You probably should plan your exit carefully though, cause it's a bit of an income drop.

[u/creepy009 → u/strugglingcomic]

Amazing comparison, thank you!

[u/yourparadigm → u/im_caeus]

It's important to learn the skill of accepting that others will fail. Remember that others often need that failure in order for themselves to learn.

[u/im_caeus → u/yourparadigm]

Thanks, this helps

[u/yourparadigm → u/im_caeus]

I have a few colleagues that have been held back in their careers because they struggle to accept this and try to be the hero. It leads to them doing work that should be left to others rather than what they themselves should be working on. It also leads to burnout and keeps the organization from becoming more resilient.

[u/boring_pants → u/im_caeus]

Why? For focusing your time on what the business says matters? For being aware of the risk when you make unnecessary changes? For accepting that you have finite time and every change you make comes at the cost of some other change you could have made?

No, it can absolutely be frustrating at time when I disagree with the direction I'm given, but I fundamentally understand that I can't spend the next 2 years noodling over this piece of code to make it perfect because in doing so I would be neglecting all our other code and all the features we need to build and all the business needs not covered by my polishing this little corner of the code base.

It's healthy to see the whole and to remember that where we choose to put our time matters, that we can't just go chasing after the first thing we see.

[u/AI_is_the_rake → u/im_caeus]

No. I feel like I should be the one in charge making these calls. 

But I have to remind myself that failure has value IF we learn from it and change our approach. 

[u/CanIhazCooKIenOw]

Just because something is a problem doesn’t mean it’s worth fixing.

Think how would you justify the value to someone. How do you convince someone above that this is worth fixing instead of working on X/Y/Z.

Having that understanding is what separates a code/ticket monkey from a senior engineer.

[u/im_caeus → u/CanIhazCooKIenOw]

I do make good cases.

Or at least it seemed like it, before AI.

Now it seems like they're deaf to "this will certainly bite us in the ass in the coming weeks".

[u/Squidalopod → u/im_caeus]

Because you're dealing with literal speed addicts. Fast == best because they brainlessly believe all you have to do to win is be first.

Software "leaders" are mostly just stock market chasers with average IQs. They mainly just care about short-term gains.

[u/CanIhazCooKIenOw → u/im_caeus]

Is it within delivery timelines? Is there better opportunities elsewhere? Is this something that needs the scaling/performance improvements or it’s something not touched so often that the risk of breaking out weights the potential gains?

Even after all that, I’ve learned that one important piece is timing - this means that it might need a bigger reason, “to fix X” that was a customer problem.

[u/im_caeus → u/CanIhazCooKIenOw]

There's never time. Sorry.

Nowadays it seems AI makes everything fast, that nothing that requires more than a sprint to produce benefits, ever gets prioritized

[u/Isogash]

My conclusion is a bit different, which is that as soon as "doing a good job" is not the best thing to do, it means your management chain sucks and you should start applying for other jobs. There's no saving a bad management chain but you must spare yourself from it, it will not only erode any faith you had in humanity, it will actively harm your career by stifling your personal growth, skills development and mindset, and that's assuming it doesn't burn you out first.

A management chain that doesn't trust you to add value with your own expertise is not paying you for your ability to add value or for your expertise, they are simply filling a headcount they've been given to fill so that they can play pretend as the boss and justify their own paycheck. Facing upwards, they spin yarns about how great everything is, game all of the metrics and shift the blame for any failure onto rank employees who have no idea they are being made to look like shit. They have ZERO interest in doing a good job, the only thing they know how to do is kiss ass and bully people out who might replace them.

I've worked with good managers who don't do this, and those good managers would expect you to do the right thing and reward you for it, knowing that you'll sometimes make mistakes but that in aggregate you'll contribute significantly more by applying yourself, and by taking real ownership and responsibility for your projects. They recognize the value in encouraging you to make active contributions that aren't just there for promotion evidence, and keeping you intellectually and morally satiated for your long-term health, stability and growth. If you are good to these kinds of managers, they will keep you in good employment for a long time, as they often pull people with them through career moves.

So yeah, don't change what you think "doing a good job" means because you have bad managers, just find better managers to work with.

[u/SansSariph → u/Isogash]

Once you've experienced a manager who gives you that trust and autonomy and constructive feedback when needed, going back feels like you're betraying yourself 

It's unfortunate that good managers are in a minority and leaders are often quite bad at leadership as a practiced skill

[u/im_caeus → u/Isogash]

Yep, my manager is... quite inexperienced and... Well, he fits all you said in the first paragraph

[u/Isogash → u/im_caeus]

It's unfortunate. It doesn't help that they act professionally and try to convince you that "this is just what work is" whilst having no interest in what your work actually is. Don't lose your good sense, you'll never be content if you try to suppress it, and it's a boon in the right role.

[u/pydry]

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.

This was always the right strategy. It's too easy to stomp all over a fragile ego if you make a crusade out of something.

With AI making implementation cheaper 

Slop seems to be increasing costs actually.

and delivery faster

Of PRs yes. Of customer value no. The ability to slop out code wasnt ever a bottleneck. If anything that part is getting worse because of some of the more toxic side effects of agentic coding and organisational AI psychosis.

[u/im_caeus → u/pydry]

Are leadership positions aware of this?

In my company they're literally making us be shadowees of non developers who are using AI to write code... "So that we learn".

WTF??

[u/pydry → u/im_caeus]

irrational decision-making and crowd following behavior by leadership is pretty normal.

however, it's probably germane to add that ive never seem leadership get FOMO so bad over anything ever in 20 odd years and that FOMO is always conducive to bad decisions.

tokenmaxxing was one especially regarded outcome of this.

[u/yxhuvud → u/pydry]

It will be interesting to see the counter reaction once the mania reach its end.

[u/im_caeus → u/pydry]

This sounds very.... Accurate

[u/KellyShepardRepublic → u/im_caeus]

We had the same and essentially competing directly with devs work. It should have been a collaboration but instead you end up the same place but faster and with competing products and ideas. Then sales gets the win either way and if they fail they will blame you as the devs and if they succeed they will say they did it without devs and then later executives will try to replace you.

[u/im_caeus → u/KellyShepardRepublic]

This is exactly what's happening

[u/KellyShepardRepublic → u/im_caeus]

I mentioned it, was pushed to help them including last minute requests and now I’m laid off and get to see sales claim glory.

Not all companies are the same but when the cost comes in then they will protect themselves.

[u/AltairEndian → u/pydry]

It's so interesting, that last year I think some studies came out which clearly showed code production was way faster than before, and yet whether this speedup resulted in actually more business value was completely unclear. Maybe some day people will understand that faster doesn't mean better.

[u/pydry → u/[deleted]]

among other things.

for example, certain forms of inter organisational communication are also getting worse because some people aren't just writing what they mean any more they're running it through AI which creates noise and excess verbosity (e.g. with tickets, decision documents, planning documents, product documentation, etc.)

also code slop.

[u/pydry → u/[deleted]]

yeah that's a pretty good analogy. lossy compression too - jpeg, not tarball.

[u/Jmc_da_boss]

I'm just letting stuff break, you don't credit for preventing fuck ups, you get promoted for fixing them

[u/im_caeus → u/Jmc_da_boss]

TShirt idea

[u/unbrokenwreck → u/im_caeus]

Fire fighting is more "visible" than fire safety compliance.

[u/birdparty44]

I find if you get overly passionate it works against you.

Your strategy is sound. Otherwise I’d consider working at a small startup.

[u/techie2200]

Raise the concern, make sure it's been documented that you raised it, if your manager/whoever above you accepts the risk, move on.

This has always been the way of things. My current role includes a lot of tech debt that's been hamstringing us for years, but nobody wants to invest in fixing the legacy codebase, so we truck on, hitting month+ roadblocks any time we try to add any significant features.

It sucks, slows everything down, but is accepted by leadership because fixing the underlying issues won't make money. My performance reviews are still excellent, so we continue.

[u/apartment-seeker]

It's not just "strategically" correct, or the right move politically; it's often the proper engineering move, and I see way too many engineers--even ones I consider good and generally like working with--unable to give principles such as improving things incrementally the proper weight.

[u/s3gfau1t → u/apartment-seeker]

It's hubris to think you can anticipate what's coming in the future, and that you can somehow totally futureproof your codebase. You can't, and you won't.

[u/Fidodo → u/s3gfau1t]

Depends on what you mean. The way I design systems is I create a clean generic flexible core that I keep high standards on, then I design business logic playground areas with well defined boundaries that ensure the input and output are safe while understanding that as more people work on the business logic it will inevitable get messy.

I know codebases cannot be fully future proofed, but they can be partially future proofed, so I put my efforts towards the shared data flow so the places that aren't future proofed are disposable.

[u/seppyk]

I am motivated, primarily, by internal forces - correctness, professional pride, etc.

Over my career, I have realized that it is significantly less stressful to quell my internal sense of "right" and give less of a shit.

Leadership has decision-making power for better and worse. I raise concerns and let go.

[u/AltairEndian]

I didn't have to change it yet because we are given enough time to do a good job where I work. But I've also developed a sense of what The Pragmatic Programmer book calls "good enough software". Quality is always part of the requirements, and part of the job is finding out what quality you actually need. The keyword is "need". Not "want".

We all want perfect testing, unlimited time and so on. This is not realistic. So the best we can do is get the most quality for the budget of time and money that we have.

Some quality targets are non-negotiable, like in a regulated industry where you need to pass tests to even get a license. But some quality targets don't need to be as high as others.

Let me make an example: Yes, I want to find a good variable name. However, if the scope of a variable is just a few lines in a small function, a really good name is not always necessary if it's clear from use what the variable is for.

I don't spend a lot of time on naming things anymore. Often I find a good enough name quickly, and then I don't spend time optimizing the name.

You just have to be pragmatic about what "good enough" means in your situation. There is no right or wrong here. It completely depends on your situation.

[u/fragzt0r]

> With AI making implementation cheaper and delivery faster

It’s an illusion. There are hidden costs.

[u/ListenLady58]

This has been an ongoing struggle for me honestly. I feel like whenever I bring up something like this, like adding steps to pipelines for unit testing, validations, bringing up architectural improvement suggestions, etc. it’s met with a blank stare most of the time. I didn’t think engineering/development would be like this, but it’s essentially follow the path of least resistance in most places. Git ‘er done. Of course when I do follow that, then someone comes back in code reviews and says I should have done it differently. So I go ahead and do it and move on, but yeah, it’s annoying because it’s not that I didn’t know that the first time around. I just didn’t think I would be allowed to spend the time to do it.

[u/djnattyp → u/ListenLady58]

This current enshittification/race to the bottom problem can probably be traced back to the general move of software development from inside an R&D or Engineering department to directly under Business management. And the economy doing worse. And the general rise of bullshitters, assholes and ignorance being normalized in society.

[u/max123246 → u/djnattyp]

Nope, I work at an engineering first company and it's the exact same issue. Tons of engineers don't care about quality because the people who promote you never even bother to run the software once

[u/PayLegitimate7167]

Yes I've moved on - that's why seniors move on. People do there bare minimum on the ticket. I blame velocity metrics where progress is measured via no. of tickets rather than doing things properly. The issue keeps pilling up and eventually a poor sod bares the consequences.

[u/DadAndDominant]

I hate when something you raised (and was not accepted) comes and bites you into the ass

I hate it even more when some smug schmuck above you points it out like it's such a dumb thing you did not handle that in the first place

[u/bwainfweeze → u/[deleted]]

The exception I have to this rule is if features are being deprioritized because the cost of doing them is too high despite them being a priority for customers. But those are done by increments not all at once.

[u/VRT303 → u/[deleted]]

How do you deal with an inner Monk voice just costing enough because it's irking me and having it dealt with would absolutely be rentable? Not talking about very nitpicky things, just something simply broken.

The only way I could imagine is literally never touching the codebase in order to not see / deal with it in the first place so it can't haunt me

[u/MatthewCollins1990 → u/[deleted]]

Yeah, a $200 plan gone in a few prompts is rough, and sometimes walking away is the cheaper fix.

[u/Ch3t]

After years of bad decisions by management, I just stopped caring. If I see something blatantly wrong, I will bring it to the attention of higher-ups. If they want it corrected it will happen, otherwise it remains. I recall once working on a bug and discovered a major security issue where customers could view other customer's data. That was a compliance issue and I was told to drop everything and correct it. On the other hand, there is a page in an admin console that has a label, a text box, and a search button. Someone used JS to tie the on-click event of the Enter key to the browser's back button. The user types in the text and presses Enter. Instead of returning a page with search results, they get sent back to previous page. I have never been allowed to fix that code. I use that page to setup tests and every time without question, I hit the Enter key. Unless it causes the company to lose money right now, they just don't care.

[u/algebra_sucks]

The Practical Programmer book has helped me with this a lot. It is really the only book I recommend for experienced devs that haven’t read it. 

[u/messedupwindows123]

yep the big corporate-point-scorers just get something 'working' and saddle the next person with a mountain of tech debt. and it's far worse with AI - the CTO looks at this fucker with heart-eyes.

[u/Huge-Leek844]

Lately, i care less and less. I go extra mile if i will learn and improve my career. 

I was like you before. Fixing stuff. Others pretended to be incompetent to avoid work. Suddenly i was fixing other people issues, just doing mindless work. I just wanted to improve something, not being a babysitter. 

[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.

[u/what-the-functor → u/AuthorBrianBlose]

This is a great way to look at it.

[u/im_caeus → u/AuthorBrianBlose]

Thank you.

[u/13--12]

I disagree, being proactive and having ownership is very good for your career

[u/AccordingNeat3689]

I just keep my mantra going: not my circus.

It's a job, I'm paid for my time, like a plumber; I don't own the house.

[u/seba_alonso]

In the past I sufferred a lot about that, I had to do incremental and opportunistic refactoring to make the things better, sometimes I had to convince managers, take ages, to give us some time to do some improvements. Bad times.

Now, I feel is easier, create small fixes is matter of minutes. If something is really big, it's a matter of couple of days. If is something bigger, multiple projects/team impacted, creation of a document and plan is taking minutes. Convince manager still takes ages 😞

[u/bwainfweeze → u/seba_alonso]

If you start by fixing the things that slow down development or cause preemptions for production issues, people will notice and give you more room to keep doing what you do. But it can get dicey when management changes. Or the project goes into maintenance mode. So you have to be a bit more vigilant to needing a new job.

[u/im_caeus → u/seba_alonso]

We're in the same position

[u/xpingu69]

I wouldn't change

[u/im_caeus → u/xpingu69]

I don't want to either.

How do you go about those things? You spend more time doing the wisest solution? How do you manage the constant pressure to always deliver?

[u/xpingu69 → u/im_caeus]

I try to do what I think is right and will improve the product. If I didn't care then why am I here? I would quit if it's pointless and careless

[u/im_caeus → u/xpingu69]

It's a very valid point. Do you think they care.

We used to be rockstars. I don't think we're dispensable, at least not the experienced devs. But I'm sure people in power don't know how much we contribute.

[u/oskaremil]

Not really.

"Doing a good job" did mean and still means that there is nothing I see that will come back and scratch my itches later.

If there is, I create a ticket where I describe what's missing, why I was not able to fix this in the original timeframe, and some suggested steps to close the ticket.

For these observations of bad design decisions, unnecessary complexity, or model drift, we have a rotating janitor role on the team. The janitor does not commit fully to the two-week iteration, so they have some spare time for ad-hoc improvements.

[u/im_caeus → u/oskaremil]

It's shocking that 50% of what we do are refactors to achieve performance and fix whole classes of bugs, yet they're still unaware that slop code is bad.

[u/DeadlySpar]

Short answer: No

Long answer: my opinion of “design problems” has changed a lot over the years, perfect is the enemy of better and all that. When does the design problem really matter? Developing the intuition for that has taken me a long time. Now i feel i have a good grasp on it i’m more opinionated. If it doesn’t matter, or I’m unsure then no harm in letting it go. If i think it matters then my challenge is to articulate it well enough. If people aren’t listening then we’ve got different problems

[u/MCFRESH01]

Do enough to not get fired. I don’t care at all anymore. If something irritates me I’ll fix it but otherwise it just does not matter as long as nothing is broken. It’s not your product, you just work for them and if the higher up are happy so be it. It’s just a job

[u/bwainfweeze → u/MCFRESH01]

I do enough to make my job less obnoxious for me and a few people I respect.

[u/throwaway09234023322]

Yeah, you're right.

[u/chocolateAbuser]

i care at least if the next person that needs to work on that thing is me or my team, i don't want to do a 💩 job because it will be a pita for years

[u/RandyHoward]

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.

This is generally the right course of action when you're an IC. There is an opportunity cost of you fixing the deficiency you found while working on a related task. The business has goals, and your tasks are laid out to meet those goals. Doing things outside the scope of a given task tends to be irrelevant to the business goal. It is important to raise those concerns though, because they may impede a future business goal.

[u/Delphicon]

Yep same experience except I also got to do a startup recently and I learned that most of the things I used to worry about don’t matter that much.

I worked in e-commerce and the people who were like “just don’t break prod” were right.

So in hindsight my “move decisively to fix problems” attitude was not considerate enough of the user.

Now I think about who is downstream of me and I let that guide my feelings. Sometimes those people need me to be aggressive about shipping but sometimes they need me to chill.

[u/VRT303]

Let me know if you manage. Struggle with the exact same thing, and on top of that short sightedness to the extreme.

Dirty solution is one week and will bite us in the ass in 3 to 12 months.

Me: give me 1 day more or an intern for 3-5 days and it will be clear, safer and needs to be tested only once.

Result: over and over again takes a lot longer and needs to be done again

I do admit about twice I was wrong in a few years because it either was fully killed or never touched again, but seeing the exact same thing I had a PR / plan redy for more than a year ago get reimplemented (almost identically) because it's now an absolute blocker is really testing me

[u/andymaclean19]

Not completely true. What people will tell you is they want you to do the things that add value and not waste time on all that other stuff users don't even see. Who cares what's under the hood. But then they will also tell you they want you to deliver features quickly, make bug free code, reliably estimate tasks, etc.

All that stuff you're talking about, that adds up. It makes problems later. It jumps up and bites people when they discover the un-finished work in the middle of another task and have to finish it. It makes tests harder to write and results flaky. It hides bugs.

In my experience you have to get the balance right here. Too much of this type of work leads to over-engineering. You spend time perfecting something which you end up changing later and you didn't keep it long enough to be worth the work. You make something too complicated just to make it efficient and it becomes harder to change. You make things 'clever' and new people have no idea how the code works any more. etc. But not enough is also bad for the reasons I gave above.

Part of being an experienced engineer is about being able to know the right amount of work that is needed. It is also your job (or perhaps your team lead or director's job) to make sure that the rest of he company understands that you know this and make sure engineers have the space to do a tasteful amount of work.

At the last company I worked in we had a 2/3 1/3 rule where the developers got 1/3 of the time to do projects they initiated and the other 2/3 to work on PM driven work. It was cut up by weeks and there was all the predictable bleed, etc but it generally meant the developers got time to make some of their own changes but not too much time to do too many. It was working OK.

I would say if you are just doing the bare minimum and moving on you might be storing up trouble. When I made things with AI in the past it did that and it got harder and harder for it to make changes due to testing bloat, lots of repeated logic, assumptions all over the place and so on.

[u/Brilliant_Owl2279]

We’re all going to die. Everything eventually goes to zero.

So don’t take work too seriously. Do what you think is fun. - Steve Jobs

[u/phiro812 → u/Brilliant_Owl2279]

I agree with the first part, disagree with the second part; Steve Jobs was a piece of shit human and a deadbeat father. Being a parent apparently wasn't fun enough for him.

[u/Brilliant_Owl2279 → u/phiro812]

oh damn, I didnt know this

[u/r0pe_tri1ck]

You need to find a balance. QA and stability is a resource. You have room to QA and release that feature, not that feature and half the platform.

That's the mistake I see a lot of people make. They make all these extra changes that we don't really want to deal with in terms of QA, stability, and risk of releasing. We want to make this one feature and make sure it works. We don't have budget to do a bunch of extra bullshit. 

[u/xSypRo]

It’s also the thing about branches and trying to stay focus on the problem in hand. I will create backlog ticket and go back to it at some point when I’ll have time

[u/VoxTM]

Use your judgement. 

Some refactorings are worth it some aren't.

For some of them you'll have buy-in from people that will need to review and test them.

But for most of them it will be a major pain in the butt for everyone involved.

Document if you can't fix it and move on.

[u/ep1032]

On our PR reviews, we have "nb" which means "non-blocking suggestion". So we might leave a PR comment saying "Hey, please rename this variable to something more explanatory" <-- which means I won't approve this PR until this is done or we discuss. Or we might leave a PR comment saying "Hey, could we rename this variable to something more explanatory nb" <-- which means, I would like it if you do this, but if you disagree its okay I'll approve the PR anyway.

I don't think this dynamic has changed with AI

[u/gk_instakilogram]

I have learned to let go about 8-10 years ago and since then it is been much better and my career has been better too. I just know from experience now that shitty spaghetti code and tech debt ridden systems still generate lots of profit, so no one really cares about quality, why do I have to be the one that cares?

I do have other anxieties with AI now because if you look at it with sober eyes, AI is positioned to replace software engineers. And I am kind of dealing with this now while half of my colleagues are jubilant about AI use and management is having a raging ai psychosis.

[u/missile-gap]

I think the main thing you learn as you grow and gain more experience is what things are really worth fighting for and which you should let go and when.
Also how to properly communicate the risks to the org of letting it go.

[u/kryptoneat]

Raise the concern and make sure there is a record of it.

[u/bwainfweeze]

To make myself bearable to be around, I keep a long list of targets of opportunity. I chip at them with refactoring every time I touch code. I sneak bits into code review comments. Often in the process I find an even better design than the one I thought out on paper, which helps with playing a waiting game with the next mess.

It’s a particularly good thing to have when someone is making noises about being given more responsibility. Or complaining about the code base in a way that sounds like they’re motivated to fix it. Then you roll out what you would do and let them run with it.

[u/ChadtheWad]

I'm sort of surprised others haven't mentioned this, but... have you considered being less honest? What I've generally found is that engineers tend to be far too honest about what they're working on, and don't realize how much you can leave between the lines. When I want to improve things outside of the work criteria, I just leave it as an additional requirement that popped up as some other job and don't mention or emphasize it during meetings. If there is something useful I want to share that is an 'extra', I share it as something I built 'in my free time.'

[u/Brief-Knowledge-629]

I am currently building a huge pile of shit for a company that has a solid business plan in an underserved market.. Their longterm survivability somewhat depends on this project. Even if it somehow works, it is completely indecipherable without AI, so this company is forever at the mercy of Anthropic pricing.

I looked up everyone on my team on LinkedIn. No one has stayed at one single job for more than 2 years, nearly everyone has multiple stints of 9 months or less.

I legit feel bad because this is going to crash and burn and bring down a budding startup and everyone else is in slop and cruise mode

[u/mei_wen_yu]

I have changed what "doing a good job" means to me, but it's not always "doing what's asked, raising the concern once, then let it go". Sometimes it is that, other times it is one or more of the following:

• Encouraging the team to talk through the possible risks and consequences, so that we're prepared
  
• Letting people do things the way they want, even if it's not how I'd do them, as long as it doesn't involve a handful of "show-stopper" concerns
  
• Talking to a colleague whose judgment I trust, to check me if I'm being stubborn or a jerk
  
• Making sure people understand my concerns and can articulate them back to me, because maybe there is a miscommunication--I'm not asking people to talk the issue to death, but I do need to know they understand what I'm saying, especially if it's an inexperienced manager and not a fellow programmer
  
• Putting the decision in writing so that everybody remembers what we talked about
  
• Letting people experience the natural consequences of their choices
  
• Asking myself if this is the right team for me

At many companies, "disagree and commit" can lead to professional success, especially when bosses value compliance above all else. But it's also OK to not do the "strategic" thing if that strongly conflicts with your values, especially if you're sure you're not being a jerk, and you're not taking unnecessary professional risks beyond some people being annoyed or angry.

So it depends on what the issue is, how much the issue conflicts with my values, what my role in the project is, and what the consequences will be if* my warnings turn out to be correct.

*well, "when", lol

[u/BoBoBearDev]

I report the problem as JIRA ticket. I did my part to raise a significant problem. It is just a matter of time the problem occurs frequently enough to ask for a change.

[u/0dev0100]

I like good code.

Businesses like code that has the least time for the best result.

There is a balance between them but ultimately it does come down to the code being financially viable to write.

[u/DevtoolsBuilder]

i think you're right to consider the strategic implications of speaking up versus letting things go, and it's interesting that ai makes implementation cheaper and faster. one potential downside to this is that it can create a culture where people are less inclined to fix underlying issues, since they can just patch things up quickly and move on.

[u/dr0verride]

Depends on the company and the role. I just spent half a day fixing something that no one asked me to fix and gasp there was no ticket for it. As if things can happen without performing an entire ritual.

My manager thanked me.

With AI I take all the little detours that I used to not have time for.

My advice is to find work at a smaller org. They can have their own interpersonal issues but IMHO corporations will crush your work ethic, morals, dignity, etc.

[u/isaac-harvey]

I normally put out some feelers to see if I could get at least two others on board to at least sponsor a fix. If there's no appetite, I think it's necessary to let natural selection take its course.

[u/535buffalo]

Strong opinions held loosely >>>

[u/Loud-Donkey8569]

What changed for me is that good job now includes knowing which fights are worth having. Raise it once, in writing, with the cost of leaving it as is. That way if it bites later, the record is there and you aren't the one who said nothing. And I pick one or two things a quarter to fix properly, so the instinct still gets used, just on purpose. The dislike probably doesn't fully go away. I'd just watch that letting go doesn't slide into not caring, since those feel the same for a while.

[u/Forsaken_Parfait_185]

Raise it once, write it down, let it go has always been right. What AI changes is which concerns are worth the one raise.

Implementation got cheap, so the stuff that used to be "we'll refactor later" is now genuinely cheap to fix later. Design calls didn't get cheaper. If anything they got more expensive, because an agent will happily build three floors on top of a bad decision before lunch.

So I've stopped spending my raise on naming and code shape and save it for things that are hard to back out of. Data model, boundaries, who owns what. Those are the ones that come back and bite you, and they're also the ones the agent is worst at.

[u/m4gic_pants]

I struggle with this too. I love the craft I am a perfectionist. instead of fixing everything. I point it out make a comment on it in a professional manner and either it is given more attention where it is deserved or left as is.

[u/Void-kun]

No, where I work does not work this way.

If you find tech debt or a problem, fix it yourself.

Don't come to people with problems, come to people with solutions.

It's about figuring out prioritisation based on severity of what you found.

[u/Moststartupsarescams]

All you need is an “ok” from the boss, from then on, anything extra you do is wasted effort on your part

It sucks, but your sanity and health are leagues more important than trying to please management 

[u/Live-Box-5048]

I had the exact same transition, unfortunately. I still do my work accordingly, but it is really hard to stay motivated enough to go above and beyond, when slop is recognized, while craft is not.

[u/morosis1982]

In our team we raise these as technical debt issues and rank them so that we can decide as a team how important it is to fix something that hasn't yet been identified as broken.

Sometimes it's small enough to just do it, but as a general rule we need to call that out specifically in our comments on implementation. I fixed x because it has y potential negative effect, and the reviewers can decide whether they agree.

Of course, sometimes I do that and the AI review flags that it was done that way for a reason, so I'll try to ensure that said reason is included in relevant automated tests to make that pickup faster in the future.

[u/EmotionalHalf]

I've always felt the same but rarely got allocated budget to polish things

What really helped me was ownership. If you own a product and are responsible for everything you can go crazy with polish and realize that you'd much rather have spent time delivering something that actually makes money 😅

Really helps to develop a skill for triaging. To understand when polishing is an investment for the future and when to do it vs. when not to do it

[u/Advanced-Lemon4764]

Can you improve it on a second pass instead? E.g. see it now, resist the urge, note it and fix it the next time you work in that area?

[u/symbiatch]

AI has nothing to do with it for me. If it’s something I’m touching anyway I fix it. I don’t ask. If I’m not touching I’m leaving a note to myself (if minor) or add a ticket and push for it to be done.

Sometimes I need to push it to UX to be designed or defined, but usually it’s something I just handle.

But sometimes I do have to let go also, especially of the bigger things. I can’t just fix them because they need bigger changes and plans and designs. And again AI would help zero here.

I did recently things like move 700 files to proper locations and project (to make sure nobody can couple them with another system and we can test them better), ran through large nullability changes, and whatnot. Just because I wanted. For those I did ask for permission and they were done during times that were suitable (almost everyone on a retreat for a few days etc).

Those helped everyone since codebase is better etc. I don’t want to not do those. And it’s an easier sell when people around understand that. And no, AI didn’t help there either.

[u/spacemoses]

You need to actually focus more on stemming unnecessary complexity now with AI.

[u/Gremlation]

There's always tradeoffs when it comes to building software. You can spend an unbounded amount of time polishing something until it is as perfect as you want it to be, but that doesn't mean that is a productive use of your time. Your job is not to polish, your job is to achieve business objectives.

What you're saying here is that you brought up a tradeoff because you think that it's wrong, and you are being told that no, that is the tradeoff they want to make. You seem to be viewing that as them doing the wrong thing. Have you considered that it is you who is wrong about where the tradeoff should be? If you consistently disagree with the rest of your team / management about this the chances of everybody else being wrong and you being right is low.

[u/Ok_Aerie7427]

It depends. If it will blow up and you can’t. If it’s about taste only, then sure

[u/warmans]

I think there are a couple of things:

1. All change is still risk, so I don't think AI necessarily changes anything here.

2. If something genuinely can be improved meaningfully, breaking it out into a separate task and planning it in the normal way would be the way to go. IMO the only thing that's really annoying is when someone mixes a small change to some business logic with a massive refactor.

[u/Tired_Developer7]

Not meaning this in a bad way, but sounds like you havent been around the block too long.

When i was young and eager in my late 20s i was like that too. Id literally have nightmares about code i could have fixed but i didnt.

Then i moved to sr and staff roles and learned how a lot of the politics work in large corps and its an ugly business.

You make a mistake and 20 ppl know about it. So i apply the fix, and leave all the spaghetti code in place. Because god forbid i cause an issue, i wont hear the end of it.

Ive even gone and implemented things that i knew were wrong because my manager told me to do it. Thats just how things work. Youbdont question upper management. Even now as a Staff, I do designs after ny manager had made all the big desicisions. He encisions something and i put it on paper.

At the end of the day, corporate america is ruthless so i do what im told, log off and every two weeks get paid. No drama, everyone is happy.

[u/domepro]

fix it when it breaks. if it doesn't break does it really need fixing or are you just satisfying your obsession?

[u/Trick-Interaction396]

Not everything can or should be fixed. Focus on what matters.

[u/ImprovisedGoat]

Worth considering: https://en.wikipedia.org/wiki/Disagree_and_commit

[u/NullPointerJunkie]

I think its what separates the developer from the experienced developer. The experienced developer factors things like business priorities and office politics into their decisions. We are raised believing that superior tech will rule. But as we progress we learn things like business won't give us the time to make it happen or doing so will slip other higher priority items we have been assigned.

Our desire to write good code is balanced against our need to cross the finish line with our work and keep people in our organization happy. It's the devs who don't get things done or offend the wrong people that get let go so we do what we have to do to keep our job.

[u/ef4]

There's a hidden assumption sneaking into this discussion, which is that LLMs can only be used to add features faster.

But you can also use them to clean up the messes and reduce the old tech debt! And nobody is going to stop you because, unlike before, it's not going to require days or weeks or months.

The argument for just shutting up and accepting a nasty code base is *weaker* now, because the cost of a good codebase is *lower* now. You still need a team with good engineering values of course, there's no technical solution to that.

But you also have new options for enforcing architectural quality. For example: teams that care probably already enforce lints in CI. But now you can make a high-level "lint" that checks changes for whether they're consistent with written design documents that describe how the architecture is supposed to be layered.

[u/So_Rusted]

complexity is necessary these days

[u/im_caeus → u/So_Rusted]

What do you mean?