3 ms·

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 a

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 4y ago
Yeah - it’s ship the bug fix, then do whatever refactoring. Just ship the bug fix first.
- mobiuscog 4y ago
  And then the refactoring may never happen. 'Phase 2 never happens'
  - gonehome 4y ago
    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 4y ago
      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 4y ago
      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 4y ago
  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 https://news.ycombinator.com/item?id=32749390
- iopq 4y ago
  Shipped the bug fix that I don't understand. Something else broke, had to revert.
shepherdjerred 4y ago
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.

gonehome 4y ago

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

mobiuscog 4y ago
And then the refactoring may never happen. 'Phase 2 never happens'
- gonehome 4y ago
  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 4y ago
    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 4y ago
    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 4y ago
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 https://news.ycombinator.com/item?id=32749390
iopq 4y ago
Shipped the bug fix that I don't understand. Something else broke, had to revert.

shepherdjerred 4y ago

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.