What is a brag document, and why every engineer needs one

A brag document is a running list of everything you've done that matters. Not your job description -- the actual work. The debug session that unblocked a team. The postmortem you wrote after the outage. The new hire you spent three hours with because they were about to quit. A brag doc catches all of it.

The reason you need one comes down to a single cognitive flaw: recency bias. When your manager sits down to write your review, they're working from whatever's most vivid -- the last two months, the visible wins, the meetings they attended. A year of good judgment collapses into a handful of recent memories, and if nothing dramatic happened in Q4, you're reconstructing from scratch.

Most engineers also make the same mistake with what they track. They record shipped features and closed tickets. That's table stakes -- it's in the commit history already. What's invisible is the support work: mentoring a struggling colleague, unblocking a stuck decision, catching the edge case in someone else's code review, staying on-call through a fragile deployment. This is the work that separates good engineers from great ones, and it never shows up in a ticket.

A well-kept brag doc changes how you show up in a review. Instead of saying you think you had a good year, you're reading from evidence: the exact date you rebuilt the release pipeline, the entry you logged when you caught the data-loss bug. There's nothing more persuasive than a claim with a timestamp you wrote yourself.

The format doesn't matter much. A text file, a Notion doc, a private journal -- whatever you'll actually use every day. The discipline is what matters: a five-second note at the end of a day beats a two-hour reconstruction session every time.

The common failure modes: logging only shipped work (capture everything that took effort or had impact, even if it doesn't map to a ticket); waiting until review season (by then half the detail is gone); being too sparse ("fixed bug" is useless -- "caught the data-loss bug in the migration review before it shipped to prod" is a story).

If you want the structure without the friction, Meritbook is the structured version of the brag doc: a private work log you can generate a review from, with tamper-evident timestamps so nothing looks backdated. But an honest text file is infinitely better than nothing. Start there.

More from Meritbook

• How to write a self-review that actually moves your rating

  Most self-reviews fail for the same reason: they describe what you did, not why it mattered.

• How to track your accomplishments at work (before you forget them)

  You already did the work. The hard part is proving it six months from now.