Work Log

A work log records attempts, observations, and decisions as work proceeds. A few columns are a useful starting point, but include enough detail to understand what was tested and why an option was kept or rejected. Record the accepted rule’s assumptions and test evidence as well as failed attempts.

Rejected attempts help avoid repeating work, but do not prove the remaining choice correct. For a remainder-based duration rule, record both the failed alternatives and the evidence supporting an under-24-hour, fixed-clock assumption. If that evidence is missing, mark the rule as conditional rather than validated for every trip.

Record the things that are expensive to recover: the exact error text, the input that triggered it, the versions in play, the source of any rule you adopted, and the decisions you made about ambiguous cases. Avoid recording what the code already says. Anything a reader would otherwise have to reconstruct by rerunning the work belongs in the log; anything they can read in one line of source does not.

Move lasting decisions into code comments, tests, and change records so they remain available with the implementation. A human work log explains reasoning and decisions; program logging records runtime events and can supply supporting evidence, but does not replace that explanation. Keep credentials and personal data out of shared records.

References: Python logging, how to create a minimal reproducible example. See it in use in Researching Errors and Organizing Analytical Work.