Hacker News Reader

Comment by CrystalLangUser | Hacker News Reader

Not necessarily. If said refactoring requires very little work, then sure. But, as it often is the case, refactoring often takes a fair bit of work and probably more than expected. Thus, it is out of scope of the original PR/branch.

If the PR is for adding a feature, then focus on that. Refactoring is better served by having its own dedicated focus and branches, respectively.

View on HN

People who keep getting deflected from fixing deeply troubling problems with the code tend to become unpleasant to be around after a while.

Edit: people who enjoy the status quo like to argue about doing it later and it can be exasperating and also a challenge to filter the people making a helpful objective decision from an obstructionist one.

As someone else said, it’s best to dig into a problem when you’re already there instead of having to come back.

There's little more irritating then pointing out something is going to bite you in the ass if not fixed, have it declared out of scope, and them be blamed when, as you predicted, it comes around to bite you in the ass. Especially when it makes it look like you're some amateur-hour bozo to a third party.

There is a spectrum. I find that when a side-refactor is too much work to tack on a ticket, it's helpful to instead ask for some smaller improvement that can help with cleanup in the future. E.g. add a line of logging that could prove down the line that a particular piece of code is not used, or switch to using a new field to let someone else delete the deprecated one later more safely.

Exactly. This is not “unhelpful”. It is good engineering practice, tempered by other good engineering practice.

Reply on news.ycombinator.com