this post was submitted on 15 Oct 2024
185 points (99.5% liked)
Programming
17188 readers
471 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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...)