Software Engineer Brag Doc Template (Free Markdown)
When review season arrives, most of us stare at a blank document trying to remember what we did in March. A brag document fixes that. It is a running, factual record of what you shipped, what it changed, and who you helped.
Below is a Markdown template you can copy in one click, a filled-in example using the XYZ formula, and the four habits that make the document worth keeping up.
# [Your Name] — Engineering Brag Doc ([Year] H[1/2])
Role: [Title] · Team: [Team] · Manager: [Name]
## 1. Summary
Two or three themes for this period, one sentence each.
- Theme 1:
- Theme 2:
## 2. Major projects and impact
Use the XYZ formula: Accomplished [X], as measured by [Y], by doing [Z].
### [Project name]
- Problem: What was broken or slowing the team or business down?
- What I did: What did you design, build, or decide?
- Impact (XYZ): Accomplished [X], as measured by [Y], by doing [Z].
- Evidence: Link to the design doc, PR, dashboard, or ticket.
## 3. Reliability and operations
- On-call and incidents:
- Performance or cost improvements (before → after):
- Tech debt paid down:
## 4. Leadership and glue work
- Mentoring:
- Code and design reviews:
- Hiring and interviews:
- Cross-team help:
- Docs, talks, and process improvements:
## 5. Feedback and learning
- Feedback I received (who, when, what):
- What I learned:
## 6. Next period
- Goals I want to be able to point to next time:How to use it (5 minutes a week)
Put it where you already work
Copy the template into the tool you already open daily: a Markdown file in your repo, Notion, Obsidian, or your notes app.
Log on Friday afternoon
Every Friday, add one or two bullet points under the right section while the week’s PRs and incidents are still fresh in memory.
Attach proof as you ship
When a major project concludes, write the XYZ impact line and attach one piece of evidence (PR link, Datadog dashboard, or RFC).
Curate for promo cycles
Before your self-review, promotion packet, or manager 1:1, scan from top to bottom and cherry-pick the 5 strongest technical narratives.
A filled-in example
Illustrative case showing the difference between a vague note and a clear, review-ready brag item.
"Improved the CI pipeline."
Why it fails: A reviewer has no context on what was broken, what you personally built, or why it mattered to business velocity.
Project: CI pipeline speed-up
Problem: Builds took about 25 minutes, so engineers waited or context-switched on every pull request.
What I did: Split the test suite into parallel jobs and added dependency caching.
Impact (XYZ): Cut median build time from 25 to 9 minutes, as measured over four weeks across a team of 12, by parallelizing tests and caching dependencies.
Evidence: Link to the pipeline Grafana dashboard and GitHub PR #412.
The strong version tells a promotion reviewer exactly why the work mattered,how you know, and where to verify it.
What to emphasize at each level
These are general industry patterns. Your company’s internal engineering career ladder is the ultimate reference.
| Level | What reviewers look for | What you should log |
|---|---|---|
| Junior | Reliable delivery and steep learning curve | Tasks completed independently, concepts learned, feedback acted upon |
| Mid-level | End-to-end feature ownership and code quality | Features owned from spec to prod, regressions prevented, testing standards raised |
| Senior | Architectural scope, multiplier effect & mentoring | Key system design decisions, junior pairing, cross-team unblocking, tech debt slashed |
| Staff+ | Organizational impact and technical strategy | Company-wide standards set, multi-quarter initiatives delivered, culture elevated |
4 habits of a brag doc that gets used
1. Log weekly, not quarterly
Five focused minutes on Friday afternoon beats spending an entire painful weekend digging through closed Jira tickets and git commits six months later.
2. Write outcomes, not just output
Merging a pull request is output. Dropping p95 latency, cutting AWS spend, or eliminating manual CS tickets is an outcome. Always emphasize what changed.
3. Track glue work on purpose
Code reviews, mentoring, incident triaging, and documentation rarely show up on sprint velocity charts, but they are critical for senior promotion packets.
4. Keep confidential details general
Write "Tier-1 enterprise customer" instead of exact names. Describe the architectural challenge and percentage metrics safely without exposing proprietary secrets.
Templates are easy to copy and hard to keep up.
Opening a blank file on Friday afternoon feels like homework, so the habit tends to fade. That is the exact problem WinStash was built to solve.
"fixed login timeout, paired with Alex on the db migration, on-call was quiet"
WinStash auto-transforms messy notes like this into:
- Weekly Sync for Slack
- XYZ Impact Brag Sheet
- STAR Stories for Resumes
Frequently Asked Questions
What is a brag document?
A running list of your accomplishments, the impact they had, and the evidence behind them. Julia Evans popularized the idea in her post on writing a brag document (jvns.ca).
How often should I update it?
Weekly is ideal, and every two weeks works. The shorter the gap between shipping code and logging it, the more specific technical details and metrics you retain.
Is a brag doc the same as a self-review?
No. The brag doc is the raw, ongoing record of everything you worked on. A self-review is a shorter, curated synthesis you write from it when promotion or review cycles arrive.
Can I include internal company details?
Keep entries general and always follow your employer's confidentiality policy. When in doubt, describe the architectural problem and the business outcome without naming sensitive customer names, internal servers, or proprietary IP.
Can I use it to prepare for job interviews?
Yes. Each project entry (Problem, What I did, Impact) maps directly to a Situation, Task, Action, Result (STAR) behavioral interview story.