“Fixing small bugs feels like rearranging deck chairs on the Titanic”

You fix the bug, but the system still feels brokenYou find a naming inconsistency, a missing error case, a loop that could be tighter. You fix it in forty minutes and open a PR. But as you wait for review, something whispers that this one patch changes almost nothing. The architecture still creaks. The database still has no indexes on the most-queried columns. The auth layer still copy-pastes secrets into logs. You are rearranging deck chairs while the ship rolls. So you close the PR, and the forty minutes sit in your head as wasted motion.

Small improvements feel like complicity with the wreckThe inherited system has visible, systemic problems. And when you fix only the small bugs, you appear to accept the wreck. Other engineers point at the architecture and ask why you do not fix it. You defend the current design because admitting it is broken feels like admitting you should have rewritten it weeks ago. The small fix becomes evidence that you are not doing enough, and doing anything smaller than a full rebuild starts to feel like enabling the decay. So you aim for the grand rewrite instead—and the small bugs never get fixed at all.

One surgical fix proves you know the differencePick one small bug that has no architectural dependency. Fix it completely. Write a test. Send the PR without mentioning the system's larger state. The point is not that this fix is enough; it is to establish in code and in your own thinking that you can tell the difference between a surgical improvement and a rewrite fantasy. Over three months, ten such fixes add up. They are not the ship being salvaged; they are evidence that you understand what you own and what you do not.