5 ms·
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 p
by andy_ppp 4y ago
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.
- omgwtf1000 4y agoThis 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.
- andrewstuart 4y agoTrouble with this is you need to explain why you touched a bit of code unrelated to the current Jira ticket. And if you have to explain that alot then you become a problem to the team lead.
- schneems 4y ago“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
- dvtrn 4y agoIf 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.
- therealdrag0 4y agoI 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.
- di456 4y agoI'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.
- gedy 4y ago> 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.
- andy_ppp 4y agoWhat 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.
- BenFrantzDale 4y agoI 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!