this post was submitted on 08 Jul 2026
49 points (98.0% liked)
Programming
27631 readers
225 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I had a senior early on in my career who took pride in producing the smallest diff possible to solve any given ticket and I thought it was so strange -- I'm already in the file, why not clean up a bit? In hindsight, they were entirely right, and I always regret doing just a little cleanup without it being strictly necessary.
You can have both. Just not in one MR. Do what is needed, push, branch off, do what is nice
Not if your team's policy is that every MR must be associated with a Jira ticket for a bug/feature and creating tickets for refactoring/cleanups is simply not done.
I just tag it with the same ticket I was working on when I discovered it needed cleanup. My logic is, it IS directly related to that ticket because that's when the file was being touched, which implies it's time is due to clean up some of its technical debt. Nobody's ever challenged it and I see other people doing similar things. It depends on the company culture, obviously, but it's not necessarily a no-go.
I’ve seen that before. It’s a self-destructive policy.
Usually it happens because there were multiple instances of such changes breaking stuff. Then QA team starts asking questions why are we breaking what's not broke. Also QA team works on Jira tickets, so if the change is not associated with relevant bug/feature then they won't know what needs to be tested and such breakage gets discovered too late.
Just make the ticket. Be the change you want to see.
Or, as suggested, just attach it to the ticket you were working on like it’s an omnibus.
Devs can't create tickets themselves either. Sneaking it with your "official" work is the only way.
Red flag right there. Devs can and should be able to make tickets.
Agreed.
I’m also a fan of Kent Beck’s “make the change easy, then make the easy change”.
i.e. Do one PR that changes the code’s design but not its behavior, in order to make the next feature easier to implement. Then do another PR that changes just the behavior but not the design.
This way, you get earlier feedback on refactors and you keep behavior PRs small so you reduce the likelihood of the scenario where “we really need to ship this feature but it’s tied to this massive refactor that isn’t quite right”.
(Note that this is just for the case where a feature genuinely requires a refactor. If it’s just “boy-scouting”, then order shouldn’t matter but you should still keep them separate.)
I'm so, so guilty of this. But that's also because I've inherited a codebase that's almost comically badly structured and every file I open is a new outrage.