Template · Brag doc

Brag doc template for developers.

A brag doc is a running list of the work you did, written as it happens. It's not for showing off. It's for the week your self-review is due, when you remember the last month and forget the first five.

Copy the template below into whatever you already use for notes. One line per thing, added the day it happens.

The template

Brag doc · [your name] · [period, e.g. H2 2026] Goals for this period • [what you and your manager agreed you'd focus on] Shipped • [what] — [what changed, before → after] — [link to PR, ticket or doc] Fixed and improved • [incident, bug, slow build, flaky test] — [what you did] — [result] Helped others • [who] — [how: review, pairing, onboarding, unblocking] — [what it led to] Decisions and design • [decision] — [options you weighed] — [why this one] Learned • [skill or system] — [where you used it] Recognition • [kudos, thank-you note or shout-out, with date and who said it] Didn't go to plan • [what happened] — [what you changed afterwards] Waiting on • [what you need] — [from whom] — [asked on: date, times asked]

A filled-in example

Half a year for an iOS engineer, cut down to a few lines per section. The project, people and numbers are made up.

Shipped • Offline sync for Recipe App 2.0 — failed saves 4.1% → 0.6% — SYNC-142 • Moved recipe images to the new CDN — first image load 1.8 s → 0.7 s on 4G Fixed and improved • Crash on launch for older devices — found the migration bug, added a test — crash-free users 99.1% → 99.7% • CI build 22 → 9 minutes by caching dependencies Helped others • Neha — paired through her first on-call week — she ran the next incident on her own • Reviewed 120+ pull requests, mostly Sync SDK Decisions and design • Staged rollouts for sync changes — weighed feature flags vs. phased release — phased release needs no extra code Recognition • Ravi, 14 Aug: "the sync migration was the calmest launch we've had" Didn't go to plan • First sync rollout went to everyone at once; after two crash reports I moved us to staged rollouts Waiting on • Server team: retry header for uploads — asked 3 Sep, 10 Sep, 17 Sep

Keep it up in five minutes a week

  1. Write the line the same day. Half a sentence is enough. You can tidy it on Friday.
  2. Add the number on Friday. Look up the before and after while the dashboard still shows it. "Faster" won't survive review week; "22 → 9 minutes" will.
  3. Link the evidence. A PR, ticket or doc next to each line saves an hour of searching later.
  4. Keep the misses. One honest "didn't go to plan" line reads as judgement, and you'll want it for the growth section.
  5. Note who you helped. It's the part of your work that leaves the least trace in tools.

What doesn't belong

Meetings you attended, tasks with no outcome yet, and anything you'd be uncomfortable reading aloud to the person it's about. If a line only says you were near the work ("worked on", "involved in"), rewrite it as what you did and what changed.

From brag doc to self-review

When the review is due, paste your lines into the free self-review generator. It sorts them into impact, collaboration and growth and marks every line that still needs a before and after. For the shape reviewers look for in your role, see self-review examples for 10 roles.

Or let it keep itself

Sill keeps this record as you work. On the Mac it reads your local git history (commit messages and times, never code). On iPhone, iPad and Mac it records the tasks you finish, the releases you ship and the follow-ups you send, with receipts like day 6, asked 3× for the things you're waiting on. Sill Pro's Review generator turns months of it into a draft per project, and where Apple Intelligence is available it writes the draft on the device. Commits come only from the Mac app. The last 7 days are free; longer periods need Sill Pro, an optional paid upgrade.

Get Sill on the App Store — for Mac, iPhone, iPad and Apple Watch. The daily standup and its set-time reminder are free.