Keep a Work Log: A Plain-Text Brag Document You Update in Two Minutes a Week

Keep one Markdown file for the year, add a dated heading each week, and write three or four bullets under it. That takes about two minutes, and it means you never reconstruct six months of work from memory at review time.

Quick answer: what a brag document is and why it beats memory

A brag document is a running list of what you did. Julia Evans describes it as something you keep so you can refer to it when performance review season arrives, because "what did I do in the last 6 months?" is a hard question to answer cold. Managers also can't advocate for work they don't remember, and a written list helps a new manager or a peer reviewer see your contributions quickly.

A work log is the same record with a different emphasis. The Pragmatic Engineer's work log guide says engineers who keep one find self-reviews and promotion cases take less time than without it, and that it makes it easier to decline new work because you can see your full workload. Treat the two names as one habit. The log is what you write weekly; the brag document is the same file when you read it at review time.

What belongs in it:

• Projects you worked on, your specific part, and the result
• Mentoring, helping others, and meaningful code reviews
• Design docs and documentation you wrote or reviewed
• Things you learned
• Talks, posts, and open source
• Fuzzy work, like improving how your team reviews code

Step-by-step: set up the file

Use a single plain-text file per year. A date-first file name sorts correctly in any file browser, so 2026-work-log.md is a good start. One file keeps search simple, and plain Markdown means it opens in anything, now or in ten years.

Start with a short skeleton:

## Goals for 2026
- Ship the billing migration
- Mentor one new teammate

## Log

Evans suggests one document per year, and notes that five to ten pages for a year of work isn't too much. Length is not the point. The habit is.

Step-by-step: a two-minute weekly template

Every week, add a new heading under ## Log. Use a week number so entries stay in order:

### 2026-W42
- Shipped: invoice export, cut p95 export time from 9s to 3s
- Helped: paired with Sam on the retry logic, reviewed 4 PRs
- Learned: how our queue handles backoff
- Wrote: design doc for the billing migration
- [ ] Follow up on export numbers after a month

Headings use one to six # characters followed by a space, and a task list item is - [ ] for open or - [x] for done, per the GitHub Docs on basic formatting syntax. Keep it to those two constructs and the file stays readable as raw text. If a follow-up has sub-steps, see how nested task lists handle indentation.

That last line matters. Evans recommends going back a few months later and filling in what actually happened after a launch. An open checkbox is your reminder. When the number comes in, tick it and edit the line above.

What to write down, and what to skip

Pragmatic Engineer suggests logging key code changes, code reviews, design documents, discussions and planning, helping others, and other time-consuming work with impact, such as postmortems. This is how you make invisible work visible.

Skip anything you wouldn't mention to your manager. If an entry takes more than a minute to write, shorten it. You can add detail later. You can't add an entry you never made.

Add numbers when you have them. Don't stretch the truth when you don't. Evans's advice is to make your work sound exactly as good as it is.

Common problems and fixes

You forget to update it. Put a recurring reminder on Friday afternoon, or tie the entry to something you already do, like closing your last meeting of the week. Evans notes some people update every two weeks and some prefer one long session every six months or a year. Pick the cadence you'll keep. Weekly entries are short, so they're easy to write.

The entries are vague. "Worked on the API" tells you nothing in March. Name the thing, your part, and the outcome, even roughly.

You don't know how to use it at review time. Read the log top to bottom once and group entries by theme: reliability, mentoring, a particular project. Themes become the story, and the bullets are your evidence. For a resume, the same material can feed a version you keep in Markdown and export.

Doing this with Carets

A work log is a good fit for a native Markdown editor because the whole system is one text file. Carets is a notes and code editor for iPhone, iPad, and Mac that handles Markdown and plain text, so you can add a Friday entry from whichever device is in your hand. Your files stay plain text, so the log is portable and future-proof, and files, projects, and tags let you keep the log next to the rest of your notes.

Open Carets, create 2026-work-log.md, paste the skeleton above, and write this week's entry.

Get Carets for iPhone, iPad, and Mac

Frequently Asked Questions

How often should I update a work log?

Pragmatic Engineer suggests recording key work items every week. Evans mentions updating every two weeks, or doing one long session every six months to a year. Pick the cadence you will actually keep.

What is the difference between a brag document and a work log?

They are the same idea with a different emphasis. A work log is the running record you add to; a brag document is that record organized for review time. One Markdown file can be both.

Do I need numbers for every entry?

No. Add them where you can, and come back to fill in outcomes later. Describe the work exactly as good as it was, no better.