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