Comment by dml2135
1 year ago
I've become something of the guy that's the main code remover at my current job. Part of it is because I've been here the longest on the team, so I've got both the knowledge and the confidence to say a feature is dead and we can get rid of it. But also part of it is just being the one to go in and clean up things like release flags after they've gone live in prod.
I'm trying to socialize my team to get more in the habit of this, but it's been hard. It's not so much that I get pushback, it's just that tasks like "clean up the feature flag" get thrown into the tech debt pile. From my perspective, that's feature work, it just happens to take place after the feature goes live instead of before. But it's work that we committed to when we decided to build the feature, so no, you don't get to put it on the tech debt board like it was some unexpected issue that came up during development.
Curious to hear other perspectives here, I do worry that I'm a bit too dogmatic about this sometimes. Part of it maybe comes from working in shared art / maker spaces a lot in the past, where "clean up your shit" was rule #1, and I kind of see developers leaving unused code throughout the codebase for features they owned through the same lens.
I probably spend 30% of time on refactoring. Deduplicating common things different people have done, adding seperating layers between old shitty code and the fancy new abstractions, adding friction to some areas to discourage crossing module boundaries, that sort of thing.
For some reason new devs keep telling me how easy it is to implement features.
Really wonder why that is. The managers keep telling me that refactoring is a nice-to-have thing and not necessary and maybe we have time next sprint.
You just have to do it without telling anyone, it improves velocity for everyone. It's architecture work on the small scale.
On days I write code, I try to do one "cleanup" PR a day just to get myself warmed up. Sometimes it is removing a feature flag, sometimes it is rewriting a file to use some new standards like a better logger library or test pattern. None of this is ticketed work, and if something takes longer than ten minutes or so I drop it and work on whatever I was going to work on originally. Make (trivial) cleanups a fun treat and a break from real work and it is easier to get other people excited about them.
Of course, lately anything trivial I ask codex to do - but there is still fun in figuring out what trivial thing I should have it take on next.
Cleanup doesn't get me a raise or promoted. In a world with constant threats of layoffs, cleanup may even be penalized depending on what's rewarded. "Clean up your shit" doesn't work when my job is on the line.
It needs to be rewarded properly to be prioritized.
> I do worry that I'm a bit too dogmatic about this sometimes
I haven't seen a lot of other good suggestions for how to accomplish this, so maybe you're being just the right amount of dogmatic.
Cleaning up of feature flags was something that I excelled at failing to do. If you are the one cleaning them up, then you sir deserve a raise. Don't question it. It's a service.
> the tech debt board
Taking you to literally mean you have a separate board for tech debt, that's your problem right there.
Well, we prioritize amongst the tech debt on that board and then move it onto the main board for sprint, it's not like it's a completely separate process. Things do go there to die sometimes though.