How to keep a bug log while you code without losing your place

Every developer knows the moment. You are deep in one problem and notice another: a misleading log line, a function that will break on an empty list, a test that passes for the wrong reason. Fixing it now means losing the thread you are holding. Ignoring it means it is gone by lunch.

The answer is to write it down in one line and go back to work. The trick is making that so fast that it does not count as an interruption.

Do not open the issue tracker

Filing a proper issue is the right end state, but it is the wrong first step. A ticket wants a title, a description, a label, a project and sometimes a template. That is two minutes and a context switch, which is exactly what you were trying to avoid.

Write a line instead:

bug: parseConfig throws on empty file, should return defaults #bugs
smell: retry loop in sync.ts has no max, check #bugs

A prefix such as bug: or smell: and a tag are enough to sort later.

Capture without leaving the editor

The capture has to happen without taking your hands off the keyboard or your eyes off the code for more than a few seconds. A TODO comment in the code works for things that belong right there. For anything else, a global capture key is faster than switching windows.

In Jot, Ctrl + Shift + J opens a box over your editor. Type the line, press Ctrl + Enter, and focus goes straight back to the editor with the cursor where it was. Jot records which app was in front when you captured, so the line shows it came from your editor or terminal. If the shortcut clashes with one in your IDE, rebind it; choosing a global hotkey covers what to avoid.

Include the one detail you will forget

The line should include whatever you would not be able to reconstruct: a file name, a function, an input that triggered it, a ticket number. “Something weird with dates” is useless tomorrow. “formatDate shows 1970 when due_at is null” is a five-minute fix.

Triage at a natural break

At the end of the task, or the end of the day, go through the bug log:

• Fix now if it is small and in code you just touched.
• File a ticket if it needs one, now that you have the context and the time.
• Delete if it turns out not to be a bug.

This keeps the issue tracker clean, because only things you have looked at twice reach it.

TODO comments are not a bug log

TODO comments are good for notes that belong next to a line of code. They are bad as a list, because nobody reviews them, they survive for years, and they are invisible outside the file. If a TODO represents real work, put a line in your log too, so it has a chance of being scheduled. The broader habit is described in how to keep a work log on Windows.

Jot is on the Microsoft Store.

Jot is a quick-capture app for Windows: one hotkey, one line, back to what you were doing. What it is, or what is still unproven.