I call this “fighting the good fight”. Hardly anywhere will prioritise making your life better, I say don’t tell them and sneak in tidy ups and refactoring as part of every task. Essentially a codebase is either getting better or worse over time, I prefer to work towards improvement rather than ossification.
Having said that in some places and on some days (and working with some people) I don’t always have perfect energy for the fight.
I agree with you in principal. But it’s not “sneaking”. You are a professional, there’s no shame in doing the job right. Imagine if bridge-builders felt like they had to “sneak in” using the proper concrete setting schedule!
If I had to justify myself every time I took the basic initiative of fixing errant, problematic or poorly performing code just because it wasn’t ordained and blessed for me specifically I am out the door SO fucking fast…
Happy to have discussions and elucidate to others the change, and make whatever documentation necessary available, but if some leader somewhere things I’m a “problem” for merely having done the work…okay, let me solve that problem too: bye.
That’s an environment with serious trust issues manifesting as micro-management and I’ve got a severe case of post-micromanagement-stress-syndrome.
I think where the valid problem is in terms of priority.
Sometimes engineers “feel” the need to refactor something that’s not related to a high priority project and end up burning days as they weren’t experienced/competent enough to really know where that string they pulled lead and got stuck fixing newly failing tests etc. and in the examples I have in mind the context isn’t the usual “product feature must deliver pressure”, it’s actually pure engineering project, where we had to rearchitect a system before our scaling hit a brick wall, so interesting engineering work by engineers for engineers and still some folks just chase squirrels.
I totally love the freedom I’ve enjoyed to fix things at my discretion in my career, but not everyone is good balancing the time/place or “picking your battles” and sometimes you gotta reign it in in others or the stuff that needs to get done won’t be.
What is and isn’t related to the ticket is debatable but your assumption that refactoring always goes outside of the bounds of the ticket is extreme. Another one of my sayings is that software engineers (humans?) find it really difficult to differentiate their opinions on things from facts.
I've had one team member push back more than others.
One solution has been to do a 1:1 screen share with someone else who has more context or feels the impact of the changes more in their day to day, and work with them to get more constructive feedback and to approve the PR.
This is the approach I take too. I’ll refactor code / UI cleanup in the area I’m working in. Sometimes QA complains if they review commits, but I’ve never had to revert changes because of it.
Having said that in some places and on some days (and working with some people) I don’t always have perfect energy for the fight.