Yes, this. Refactor first to make the upcoming change easier and cleaner, not after. Don’t ask for permission, don’t even call it refactoring or cleanup. Just call it working on the feature, because that’s what it is. Don’t let non-engineers tell you how to engineer.
I do this too, but I realize I’m privileged to be able to. In past jobs people actually would get pissed at me for doing it. I had a manager have a really shitty talk with me about it once. I’d guess a lot of people have bad experiences like that
If higher-ups complain about intempestive code refactoring, it’s always a good idea to stop for a moment and to start becoming less trigger-happy with refactors. It’s OK to take some time to determine what actual value refactors bring to the project in tangible terms - intuition is not enough. Convincing a critical manager is a good start, because their tolerance for programmer bullshit is low if they don’t actually write code.
Very often, and this is especially prevalent among junior programmers who care about what they do, the reasoning for refactoring turns out to be something along the lines of “I don’t like this” or “I read some cool blog article saying things should be done that way”, without any care about whether or not the change in question is actually improving anything, or, if it does, if the improvement is worth the degradation in terms of quality (new bugs)/maintainability (added genericity making the code more difficult to understand, cryptic features of the language being used that make it hard to understand what’s going on, I’m sure there’s other examples…)
The problem is you often get in cases where the developer cannot back their intuition that something is actually harmful with facts. When it’s not just pure bikeshedding about code they don’t like and falsely claim to be a ticking timebomb, they fail to weigh the risks of leaving slightly offputting code in the codebase against the risks associated with significant code changes in general, which, even with tests, will still inevitably break.
Developers of all sorts tend to vastly overestimate how dangerous a piece of code may be.
To be clear, while I’ve seen it with other developers, I’m still guilty of this myself to this day. I’m not saying I’m any better than anybody.
It’s just that I’ve seen how disruptive refactoring can be, and, while it is often necessary, I thought it would be important to mention that I think it should be done with care.
If you can convince a manager with rational arguments in terms of product quality, it can be a good way to make the case for a refactor, because your manager probably won’t be impressed by arguments about unimportant nuances we developers obsess about.
Yes, this. Refactor first to make the upcoming change easier and cleaner, not after. Don’t ask for permission, don’t even call it refactoring or cleanup. Just call it working on the feature, because that’s what it is. Don’t let non-engineers tell you how to engineer.
Yes, this! I rarely ask for permission on that sort of thing. I’ll just do it as part of my work and see if anyone calls me out on it.
I do this too, but I realize I’m privileged to be able to. In past jobs people actually would get pissed at me for doing it. I had a manager have a really shitty talk with me about it once. I’d guess a lot of people have bad experiences like that
If higher-ups complain about intempestive code refactoring, it’s always a good idea to stop for a moment and to start becoming less trigger-happy with refactors. It’s OK to take some time to determine what actual value refactors bring to the project in tangible terms - intuition is not enough. Convincing a critical manager is a good start, because their tolerance for programmer bullshit is low if they don’t actually write code.
Very often, and this is especially prevalent among junior programmers who care about what they do, the reasoning for refactoring turns out to be something along the lines of “I don’t like this” or “I read some cool blog article saying things should be done that way”, without any care about whether or not the change in question is actually improving anything, or, if it does, if the improvement is worth the degradation in terms of quality (new bugs)/maintainability (added genericity making the code more difficult to understand, cryptic features of the language being used that make it hard to understand what’s going on, I’m sure there’s other examples…)
The problem is you often get in cases where the developer cannot back their intuition that something is actually harmful with facts. When it’s not just pure bikeshedding about code they don’t like and falsely claim to be a ticking timebomb, they fail to weigh the risks of leaving slightly offputting code in the codebase against the risks associated with significant code changes in general, which, even with tests, will still inevitably break.
Developers of all sorts tend to vastly overestimate how dangerous a piece of code may be.
To be clear, while I’ve seen it with other developers, I’m still guilty of this myself to this day. I’m not saying I’m any better than anybody.
It’s just that I’ve seen how disruptive refactoring can be, and, while it is often necessary, I thought it would be important to mention that I think it should be done with care.
If you can convince a manager with rational arguments in terms of product quality, it can be a good way to make the case for a refactor, because your manager probably won’t be impressed by arguments about unimportant nuances we developers obsess about.
The joy begins when you know you should refactor the whole project from the ground up…