I count a bug fixed when the exact steps that broke it stop breaking it. The edit is the middle of the job, not the end of it. I squashed a bug in React last week, and the satisfying part was not the change. It was running the same steps that broke it and watching them pass.
Debugging is puzzles, one piece at a time. That is the line I wrote to myself when I started the day, and it held up. Each piece is a fact I can check: what the state was before the break, what changed between the working run and the broken one, what the render did with the value it was given. A piece I cannot check is not a piece. It is a guess wearing a puzzle shape.
The method is the same one I use on the backend. Reproduce it first, before touching anything. Shrink it until only one thing can be wrong. Change that one thing. Then run the exact steps again. If the steps still break, the fix was a guess, and I say so and keep going. The same discipline sits behind the SES piece I published in October: an accepted call is not a delivered message, and a green run is not a fixed bug. The check is the win, not the edit.
That is why I keep the wins daily and small. A win I can prove beats a win I can describe. The kind of win I mean: a failing case that now passes, a log line that finally makes sense, a retry that stops duplicating the request. On a bad day, the list is the proof I am moving. On a good day, it is the record of how.
Write the win down the day it happens, with the check attached. A win without its check fades by the next morning, and then it was never a win. It was a feeling.
Tell me the smallest win from your week that you can prove: the failing case, and the run where it passed.
Next in this series: Accountability and transparency in a remote team.
Top comments (0)