“Now if you feel that the bare minimum is enough, then okay. But some people choose to [commit] more and we encourage that, okay?”

- Mike Judge, Office Space

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.

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.

> Trouble with this is you need to explain why you touched a bit of code unrelated to the current Jira ticket.

If anyone questioned me like that, I'd leave that company, that's kind of ridiculous.

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.