The bug report was simple enough. On the reports dashboard, if you changed the date range while a filter was already active, the page number didn't...
For further actions, you may consider blocking this person and/or reporting abuse
Nice debugging! It often happens that a bug fix I imagine as a small part of one file ends up being a large fix across many files. 😅
Thank you! 😊 That's the tricky part. Sometimes those extra changes are genuinely worth doing, but they don't always belong in the same fix. I've been learning to separate the two.
This is a great reminder that good refactoring is not always the same as doing every improvement you can see. I especially liked the distinction between fixing a real structural problem and using a bug fix as an excuse to redesign the whole feature. Keeping the larger rewrite in its own PR makes the reasoning and review much clearer.
For developers working through similar refactoring decisions, CodeArea.net can also be a useful resource for practical development workflows.
Thanks, Leonore! Really appreciate you taking the time to read the post and share your thoughts. Keeping a fix focused instead of turning it into a larger rewrite is something I pay much more attention to now. And thanks for sharing CodeArea.net as well.
Hi Shubhra, great post! As engineers, we always want to optimize and fix problems. Your post is a great reminder that it's better to slow down and fix what is needed before trying to make a bigger optimization.
Thank you, Shayan! That instinct is worth keeping, so I'm not trying to train it out of myself. What helped me was taking a moment to ask how long it would take to justify a change before shipping it. The two smaller fixes took a sentence each, but the server component rewrite took a paragraph, so I moved that one into its own branch. 😊
Shubhra, the “seven files for a bug that was missing one line” 😄 I think a lot of us have been there. It’s so easy to keep going once you notice other things, even when the original problem was already fixed.
Hema, exactly! 😊 The hardest part wasn't finding the original bug. It was knowing when to stop fixing things I noticed along the way. I've definitely learned that not every good improvement needs to go into the same PR.
The taxonomy you're building here is the useful one. Not 'scope creep happened' but 'which expansion was legitimate'.
Fixing the pagination reset, merging to a single source of truth for filter state, deduplicating the filter logic. Those are all load bearing changes. Each one closes a real failure mode. The line you draw is exactly right: the server component refactor is a different class of thing, because none of the existing bugs required it. It's an optimization dressed as a fix.
The hardest call in a diff like this is often not 'should I do this' but 'should I do this in this PR'. Which of those three expansions would you have split into a separate ticket if the codebase had a formal review process?
Thank you, Mudassir! Honestly, the pagination reset and the single source of truth for filter state wouldn't have been separate tickets for me, even with a formal review process. They were closely connected to the filter and pagination problems I was already investigating.
The duplicated filter logic is the one I'd have thought about splitting. It fixed a genuine client/server validation gap, so I can justify keeping it in the same PR. But it was a separate issue from the original pagination bug, and in a formal review process, I'd at least consider giving it its own ticket.
The server component rewrite was the clear one for me. It wasn't needed to fix any of the existing bugs, and the justification was increasingly about improving the code rather than addressing the reported problem. That's where I'd draw the line between a useful refactor and a change that deserves its own PR.
Nice write-up shubhra! ❤️
Thank you so much, Divya! ❤️ Glad you enjoyed it!