[giansegato]

What you're saying and what the article is saying are two different things. The whole point of the article is not "Don't refactor code"; it's "Never fix a bug and refactor in the same pull request".

It's a matter of focus and intentionality.

[gonehome]

Yeah - it’s ship the bug fix, then do whatever refactoring. Just ship the bug fix first.

[mobiuscog]

And then the refactoring may never happen.

'Phase 2 never happens'

[gonehome]

Don’t do it at some later date, do it right after. Just ship the low risk fix first. Otherwise if you’re not careful phase 1 never happens either.

[VBprogrammer]

The obvious question in any organisation with a layer of project managers is how to explain that you've delivered the fix and you haven't moved on to fixing the next most important thing or adding some other new functionality.

Yes, that's probably a sign of poor project management or organisational brokenness. But it's also probably the reality for most people.

[iopq]

The bug fix might be the high risk change, since it's a hack on top of a hack that you think might cancel each other out

[mijoharas]

I just mentioned it in this comment[0] but I disagree with this premise too since sometimes it's more work to fix the bug without the refactor:

> It also misses the point that sometimes refactoring makes it _easier_ to fix the bug, and that a large part of fixing a bug is understanding exactly what's happening with the code, which refactoring can also make easier.

https://news.ycombinator.com/item?id=32749390

[iopq]

Shipped the bug fix that I don't understand. Something else broke, had to revert.

[shepherdjerred]

You’re right. My comment is a bit of a tangent into the idea of “what if I just did the bug fix to skip refactoring”.

I clicked on this article because it applies to me (I constantly yak shave), but I’m a bit disappointed with how terse it was.