You17:40
Done: copied production data to staging. Decided: invoices first, because the reports depend on them. Next: run the migration on staging.
A work log is a short, dated note you write at the end of each work session: what you did, what you decided and what comes next. Next week it tells you where you stopped, and at review time it shows what you got done.
Updated 4 November 2026
See the templateA record of what you did and decided, in the order it happened, with the next step at the end.
It isn’t a timesheet. You don’t log hours; if you bill time, keep a time tracker alongside it.
Copy this into each new entry and delete the lines you don’t need.
Done: Decided (and why): Stuck on: Next:
Put the date at the top if your tool doesn’t add it. There’s no line for the project, because each project gets a log of its own.
A filled-in entry, from a developer’s log:
Done: product search answers in 120 ms on staging; tests pass. Decided: index titles only for now, because full text doubles the index. Stuck on: “Müller” doesn’t match “Muller”. Next: try the accent filter on the staging index.
The best moment is right before you move to something else, while the detail is still in your head. By evening you remember what you did, but not what you were about to try, and Next is the line you need on Monday morning. More on coming back: how to resume a project after a break.
One sentence is enough: “Stopped here: the migration runs on staging; next, the two failing reports.”
A single log for everything turns into a list where three projects interleave. Keep one per project, so each reads as one story and its last entry is always where that project starts again.
If you work on one project at a time, one daily log is enough. With several, a short entry in a separate “Week” log can list what moved in each.
When a decision changes, write a new entry that says so and why. When someone asks in March why you dropped the second payment provider, the answer is there with its date, next to what you knew at the time.
On Friday, read the week’s last entries in each project and write three lines:
Shipped: Learned: Next week:
Those three lines are your status update. Over a year they add up to a record of your work for a performance review or a brag document. In nearly 12,000 diary entries from 238 employees in seven companies, Teresa Amabile and Steven Kramer found that progress in meaningful work, even in small steps, mattered more to people’s days at work than anything else (The Progress Principle).
Your workspace starts empty.
Work
Written before moving to the next project.
You17:40
Done: copied production data to staging. Decided: invoices first, because the reports depend on them. Next: run the migration on staging.
Stuck on is the line you need tomorrow.
You18:05
Done: the migration ran. Stuck on: the invoice and revenue reports show different totals. Next: compare the two report queries.
A decision, with its reason. Waiting
You16:20
Decided: run old and new billing side by side for one cycle, because finance wants to compare the invoices. Stuck on: waiting for finance.
Friday’s three lines.
You17:55
Shipped: the staging migration. Learned: the revenue report counts refunds twice. Next week: production, once finance agrees.
Claude Code and Codex are the names of their owners. ThreadPage is independent and not affiliated with or endorsed by them.
Mostly the name. A work log tends to be short and factual; a work journal leaves more room for reflection. The template works for both.
As short as it can be while you’d still understand it in a month. Two to five lines is typical.
One per session if you switch projects during the day; a day spent on one project needs one entry.
Share the weekly three lines, and keep the raw log for yourself.
No. A timesheet records hours. A work log records what happened, what you decided and what’s next.
Free in your browser. No account needed to start.
Before you switch, one line: stopped here, next. When you come back, the thread’s last note says where to start.
Free nothing to set upYour repository’s pull requests file themselves into a thread of their own. You note what git can’t see, and at review time your agent drafts from both.
Pro pull requests and agents