DEV Community

Discussion on: So You Learned React, and Now You Work with jQuery...

kodierkroete profile image
Steffen Frosch

We really do have a different point on view on that part. It's totally right that we are mostly hired to create business value.

And we should only do things that create business value. Getting more pace at the development process imho creates business value. If we talk legacy code it is not only about new features. If multiple contractors worked on a piece of software over multiple years things tend to have some ugly places. You could fight it with every bugfix or new feature again and again or you can make a difference.

And i git is a wonderful tool if you want to keep track of why something happend. And housekeeping and the work for an actual fix are two different things because you obfuscate your intent.

Imagine you're fixing a little bug. Let's say it took one line. Then because you're convinced that the code should be formatted as of current standards. You run a tool in your IDE and boom thousands of files reformatted (extreme case but gets my point accross). It get's really complicated to reason about the change and find the spot you actually changed.

At the end of the day it's about making your and the life of your coworkers easier. (More readability, safer code, etc). You are not obligated to do that and go the extra mile but in my opinion it is totally worth it.

Thread Thread
okolbay profile image

reformatting the whole codebase is definitely not something that should be shipped with one-line bugfix. neither it is something one person should author (as an idea, not as commit’s author)))
so codebase re-formatting is super specific edge-case. In most of day-to-day situations, however, its possible to make small steps. so small that they could be embedded into feature PRs )