Hacker News Reader

Comment by Chaebixi | Hacker News Reader

> Even if a developer is extending or modifying a messy part of the code that is rife with bad practices, don’t ask the developer to fix them in that pull request just because their changeset happens to touch the messy code.

I don't think that's good advice at all. If you touch messy code have a go at fixing it. If you don't you'll just end up with increasing tech debt.

View on HN

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.

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.

Campsite rule. We don’t insist that you make it good, but we do insist that you make it better.

Reply on news.ycombinator.com