Software engineer brag documents are living records of your merged pull requests, shipped features, and measurable impact, kept updated monthly so performance reviews and promotion packets write themselves instead of becoming a memory-scramble in December. Engineers need a different format than PMs or designers: the raw material is commits, PRs, and code review threads, not slide decks or campaign reports, so the collection method has to plug into GitHub directly.
- A brag document software engineer keeps updated monthly beats one written the week before a review.
- Pull Tally pulls merged pull requests by month, org, or repo, cutting the manual GitHub-search step.
- Quantify outcomes, not tasks: latency cut, tickets closed, review turnaround, not 'worked on backend'.
- Spreadsheets and GitHub filters work but require discipline most engineers don't sustain past month two.
- Update the document the week a PR merges, not the week the review is due.
Why brag documents matter for software engineers
Engineers lose credit for work that never gets written down in plain English. A merged PR that cut a database query from 800ms to 60ms reads as "fix N+1 query" in a commit message and disappears from memory within weeks. Managers writing performance reviews in 2026 are pulling from whatever engineers hand them — not re-reading six months of git history on their own time.
The format also protects against a specific failure mode in engineering careers: work that's technically significant but invisible in a standup. Cross-team unblocking PRs, infrastructure migrations, and code review comments that saved another engineer three days rarely surface unless someone tracked them as they happened. A brag document built from actual merged pull request history, not memory, is the only version that survives a review cycle intact.
Step 1: Collect every merged pull request first
Start with the raw list before you write a single sentence of narrative. Skipping this step is why most brag documents stall after one entry.
- Search GitHub with
is:pr is:merged author:yourusernameacross repos you contribute to - Check org-level repos separately from personal projects — they don't show up in the same feed
- Include PRs where you were the primary reviewer, not just the author
- Note the merge date, not the creation date — reviews reference when work landed
Step 2: Group entries by month, not by project
Reviews and promotion packets are read chronologically, so a document sorted by project forces the reader to reconstruct a timeline themselves.
- Bucket every merged PR under the month it landed
- Flag months with unusually high or low output — both need a one-line explanation later
- Keep a running total per quarter so a promotion packet can cite six or twelve months at once
- This is where manually searching GitHub starts costing real time once you pass 15-20 merged PRs a month — Pull Tally builds this monthly grouping automatically from your merged pull request history, by org or personal repo, without a spreadsheet
Step 3: Attach the "so what" to every entry
A line that says "refactored auth middleware" tells a reviewer nothing. A line that says "refactored auth middleware, cutting login latency from 1.2s to 300ms" is a brag document entry.
- Add the business or user-facing outcome, not the technical mechanism
- Cite the metric that moved: latency, error rate, ticket volume, deploy frequency
- Name who benefited: the team, the customer segment, the on-call rotation
- Skip entries with no measurable or observable outcome — cut count, not padding
Step 4: Quantify wherever a number exists
Engineers underuse numbers they already have sitting in dashboards, PR descriptions, or ticket systems.
- Pull request count and review turnaround time from your own GitHub history
- Performance deltas from APM tools if you have access (latency, error rate, memory)
- Ticket or bug counts closed, from Jira or Linear exports
- Lines changed is a weak metric on its own — pair it with an outcome or drop it
Step 5: Draft a one-page summary from the monthly log
No reviewer reads twelve months of raw entries. The monthly log is your source material; the summary is what gets handed over.
- Pull the top three to five entries per quarter, not every merged PR
- Group by theme if you touched multiple systems: reliability, performance, feature delivery
- Keep each summary bullet to one sentence with a number in it
- Cut anything already in your manager's 1:1 notes — a brag document supplements memory, it doesn't duplicate it
Step 6: Update it the week the PR merges
The single most common reason brag documents fail: engineers write them once, in a rush, right before a review. A brag document updated monthly across 2026 takes ten minutes each time. One written retroactively in November for a January review takes an afternoon and misses half the work.
- Set a recurring 15-minute calendar block at the end of each month
- Update it the same day you check whether performance goals are on track
- If pulling merged PRs manually is the bottleneck, that's the exact gap Pull Tally is built to close by summarizing GitHub activity automatically instead of re-running search queries every month
Comparison: how software engineers track brag documents
| Option | Best for | Key limitation |
|---|---|---|
| Spreadsheet or text file | Engineers who want zero setup | Entirely manual entry, easy to abandon by month three |
| GitHub search and filters | Engineers comfortable with GitHub's query syntax | No monthly grouping or summarization, slow past 15-20 PRs a month |
| Notion or Confluence doc | Teams already storing career docs in a wiki | Still requires copying each PR link and outcome by hand |
| Pull Tally | Individual developers who want merged PRs organized by month, org, or repo automatically | Covers GitHub activity only, not qualitative notes from meetings or 1:1s |
Verdict: a spreadsheet is fine for engineers merging fewer than 10 PRs a month. Past that volume, manual tracking is the first thing that slips, and Pull Tally is the faster path for individual developers who want their merged pull request history organized without building a tracking system from scratch.
Build your 2026 brag document faster
Browse and summarize your merged pull requests by month, org, or repo.
Common mistakes software engineers make with brag documents
- Starting the week before a review. A brag document written under deadline pressure misses half a year of context and reads like a resume, not a record.
- Listing tasks instead of outcomes. "Worked on the payments service" tells a reviewer nothing that a git log doesn't already show.
- Ignoring non-code contributions. Code review comments, mentoring, and incident response rarely show up in a PR list but often carry as much weight in a promotion packet.
- Ignoring closed-but-unmerged work. A PR that got reverted after a production incident still demonstrates judgment if the fix and rollback are documented honestly.
- Treating it as an annual document. A brag document updated once a year is a memory exercise; one updated monthly through 2026 is a record.
FAQ
What is a brag document for a software engineer?
A brag document software engineer keeps is a running log of merged pull requests, shipped features, and measurable outcomes, updated monthly instead of written from memory before a review.
How often should engineers update a brag document?
Update it monthly, the same week PRs merge. A document built retroactively in 2026 for a review cycle misses context that only exists right after the work ships.
What should go in each brag document entry?
Include the merge date, the project or repo, the outcome in plain language, and a metric if one exists, such as latency reduced or tickets closed.
Is a spreadsheet enough to track a brag document?
A spreadsheet works for engineers merging fewer than 10 pull requests a month. Past that volume, manual entry becomes the reason the document stops getting updated.
How is Pull Tally different from searching GitHub manually?
Pull Tally organizes merged pull requests by month, organization, or personal repo automatically, replacing repeated GitHub search queries with a single summarized view.
Should a brag document include code review contributions?
Yes. Reviews that caught bugs, unblocked teammates, or shaped architecture decisions belong in the document even though they don't show up in your own PR count.
What's the biggest mistake engineers make with brag documents?
Writing the document once, right before a performance review, instead of updating it monthly as pull requests merge throughout the year.
One last thing
The entries engineers forget most are the ones with no visible metric attached — a production incident stopped before it paged on-call, a migration that removed a recurring source of flaky tests. Those don't show up in a PR diff count, so they only make it into a brag document software engineer teams actually use if you write the outcome down the same week it happens, not months later when the detail is gone.