Most work logs are activity logs: a list of meetings attended, tickets closed, messages sent. They are easy to write and almost useless later. Six months on, nobody needs to know that you joined a stand-up; they need to know why the migration was paused, which option was rejected, and what evidence settled the argument.
A work log that survives a job change records decisions, not activity. It takes about five minutes a day, fits in a plain text file, and becomes the most useful document you own when you are asked "why is it like this?" — in a review, an interview, or your own next project.
The five lines
Each day gets one block with five lines:
- Date and context. One line: the project, the phase, and anyone outside the team who is waiting on it.
- Decision. The one choice that mattered today. If there was no decision, write "none" and skip the rest. Not every day produces one; pretending otherwise turns the log into a diary.
- Alternatives rejected. What else was on the table, and why it lost. This is the line that saves you later, because memory rewrites rejected options as obviously bad.
- Evidence. The thing you checked: a benchmark, a customer quote, an error rate, a test run, a screenshot description. If the decision was a judgment call, say so and name the uncertainty.
- Follow-up. The next observable step, with an owner if it is not you. "Benchmark the batch path on the real export" is a follow-up. "Keep an eye on it" is not.
Five lines is a ceiling, not a target. A day with two decisions gets two blocks. A day with none gets a single line and no guilt.
Why decisions instead of activity
Activity is easy to reconstruct. Your calendar knows your meetings, the tracker knows your tickets, and the repository knows your commits. What none of those systems capture is the reasoning that connected them. The decision log fills exactly that gap, and it stays small because decisions are rarer than actions.
There is a second benefit: writing a decision down exposes weak reasoning. A choice that sounded fine in a meeting often looks thin when you have to write "evidence: because the vendor's page says so." The log is a daily five-minute review, not a formal document.
Storage that will survive
Keep the log in plain text or Markdown, one file per quarter, in a place you control. Not a proprietary notes app, not a chat channel, not a shared drive you lose access to when the contract ends. A folder of 2026-Q4.md files is boring in the best way: it opens on any device, diffs cleanly, and can be searched with grep.
Company policy matters here. Do not copy customer data, credentials, or confidential documents into a personal log. Write the decision and the shape of the evidence — "error rate dropped from 4.1% to 0.9% on the staging sample" — rather than the raw export. If the log must live on a company machine, keep a personal copy of only the parts you are allowed to keep.
The monthly review
Once a month, read the last thirty days and answer three questions in a short paragraph at the top of the file:
- Which decision would you make differently now?
- Which follow-up is still open, and is it still worth doing?
- Which recurring problem has no written decision behind it?
The third question is the valuable one. Recurring problems usually mean a decision was never made or was made implicitly. The log makes that visible.
Using the log in a review or an interview
When review season arrives, do not reconstruct the quarter from memory. Open the log and look for decisions with measurable evidence. A sentence like "moved the batch job off the shared queue after the p95 latency doubled; evidence: two weeks of timing data" is a better review item than any list of completed tickets, because it shows judgment rather than throughput.
In an interview, the same notes produce specific stories instead of vague ones. "We chose the boring option because the exciting one had a migration cost we could not staff" is a story about trade-offs. "I worked on the migration" is a job description.
What the log is not
It is not a performance record, a billable-hours ledger, or a place to vent. Keep it factual and short. It is also not a replacement for documentation: a decision that changes how a system works belongs in the repository's decision record or README. The personal log is where the reasoning survives long enough to be written down properly.
Start smaller than you think
The first version should be ugly. One file, five lines, today. Do not design a template, choose a tool, or set up a weekly reminder until you have written for two weeks. If the habit survives two weeks, it will survive a job change. If it does not, you have lost ten minutes, not a system.
The log is not about being organized. It is about leaving a trail that your future self can follow when the context is gone. Jobs end, projects get archived, and memory is generous in the wrong places. Five lines a day is enough to keep the reasons.