this post was submitted on 15 Oct 2024
181 points (99.5% liked)
Programming
17189 readers
465 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
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...