Editorial illustration of an open notebook on a desk showing weekly bullet entries flowing into a longer paragraph, with small post-its scattered around — the brag-document workflow.

Self-Review Examples for Software Engineers (Brag-Doc Method)

Your self-review is the only document at calibration that you control. Your manager walks into that room with whatever they can remember plus whatever you handed them. If you wrote a half-page of vague adjectives the night before it was due, that's the evidence on the table.

This guide is for the engineer writing their own self-review. (If you're a manager writing reviews for your engineers, the sibling piece on performance review examples for software engineers is the one you want.)

The durable hook here is the brag-document method — capture weekly, categorize, quantify, cite. Below: examples by level, plus one full raw-notes-to-finished-review transformation that most write-ups skip.

Key Takeaways

Your manager forgets roughly the last three to six weeks of your work; recency bias is structural, not personal. Counter it with a brag doc you append to weekly.

Strong engineer self-reviews follow a four-part pattern: situation, action, measurable result, citation (PR, ticket, doc, incident).

"I don't have metrics" almost always means "I haven't looked." Proxy signals — PRs merged, reviews given, incidents resolved, mentees onboarded — count.

Junior, mid, and senior+ self-reviews differ in scope and artifact type, not in honesty. Calibrate examples to the level you're being reviewed at.

Why your manager doesn't see most of your work

Most engineering work is invisible by default. The PRs you reviewed at 11pm, the production incident you quietly resolved before the on-call escalation fired, the migration doc you wrote that prevented six future bugs — none of it shows up unless someone surfaces it. Usually that someone is you.

This isn't a story about bad managers. A typical engineering manager runs 6–10 reports, sits in roughly 15–25 hours of meetings a week, and writes reviews for everyone in a compressed two-week window. By the time they sit down to draft yours, they're working from memory of the last sprint or two. That's recency bias in performance reviews, and it works against you specifically when your biggest impact landed in Q1 or Q2.

The fix isn't to schedule more 1:1s. It's to write things down as they happen, so your self-review is a retrieval exercise — not an act of creative writing under deadline.

The brag-document method

The brag doc is a private, append-only log of your work. The name comes from Julia Evans' widely shared post; the practice predates it by decades under other names (work journal, accomplishment log, evidence file). It's the durable system underneath every good engineer self-review.

What to capture (weekly, 10 minutes)

Open the doc every Friday. Add bullets under the current week with five categories:

Shipped — features, fixes, infra changes, docs, migrations. Link the PR or ticket.
Reviewed / unblocked — meaningful code reviews, design reviews, pairing sessions, questions answered in Slack threads.
Incidents and saves — production issues you caught, root-caused, or mitigated. Link the postmortem or incident channel.
Influence — RFCs written, decisions you swung, new patterns adopted, junior engineers you mentored.
Growth — talks given, courses finished, scary thing you tried, new system you learned.

Don't write prose. Write artifact-linked bullets. "Shipped — flaky retry logic in checkout-service, PR #4821, cut checkout 500s from 1.2% to 0.1%" is enough. Future-you will thank present-you.

Categories that match every review rubric

Most engineering rubrics rate the same dimensions under different names: technical execution, scope and impact, collaboration, and growth. The brag-doc categories above map cleanly onto all of them. When self-review season starts, you're not inventing — you're filtering an existing list against the rubric.

Quantifying impact when you "don't have metrics"

The "I'm not on a numbers team" excuse almost always falls apart on inspection. Proxy signals are everywhere:

PRs merged, PRs reviewed, average review turnaround
Bugs filed vs. bugs closed; incidents you owned or co-owned
Build time before / after; flaky-test count before / after; p95 latency before / after
Docs you authored that others link to; design docs you reviewed
Engineers onboarded; questions answered in #help channels
Estimated hours saved across the team by a tool or script you wrote

If you can't pull the number, estimate it and say so. "Saved roughly 30 engineer-minutes per deploy, ~12 deploys a week, ~6 hours/week reclaimed" is stronger than a vague claim of "improved developer experience."

Self-review examples by level

The patterns below show what a finished paragraph looks like at each level. Tone is confident, evidence-led, not boastful. Each line follows the same shape: situation → action → measurable result → cited artifact.

Junior engineer (0–2 years)

In Q1 I owned the migration of our notification service from the legacy SQS consumer to the new EventBridge pipeline (RFC #218, PR #4612–#4631). I scoped the work with my tech lead, broke it into nine smaller PRs to keep each reviewable under 300 lines, and shipped without a rollback. Post-migration, retry storms during partial outages dropped from a weekly occurrence to zero over six weeks (dashboard: notifications-eb-prod). I asked for code review on every PR and incorporated feedback before merging — review-cycle time stayed under 24 hours. Growth area: I want to get faster at writing the migration plan itself; I leaned heavily on my tech lead for the rollback design and want to draft the next one independently.

What makes it work: a real artifact (RFC and PR range), a quantified outcome with a citation (the dashboard), and a specific, honest growth area instead of a generic "improve communication."

Mid-level engineer (2–5 years)

This cycle I led the checkout-service reliability push (objective CKO-2026-Q1). I root-caused a long-running flaky-retry bug that had been mis-tagged as "flaky tests" for three quarters (incident IR-4471, postmortem linked), shipped the fix in PR #5018, and added regression coverage. Checkout 500s dropped from 1.2% to 0.1% of requests and held through the spring sale (Grafana board: checkout-prod, week-over-week panel). Beyond the fix, I rewrote the on-call runbook and ran two game-days; the next two on-call rotations resolved similar alerts without paging me. I also reviewed 47 PRs this cycle (median turnaround 4 hours) and mentored two new hires through their first production deploys. Growth area: I want to get better at writing design docs before I have a working prototype — my instinct is still to code first and document second.

What makes it work: leadership scope is explicit ("led the push"), the impact has a clear baseline and a sustained result, and the mentorship and review work isn't buried at the bottom.

Senior+ engineer (5+ years)

I owned the platform reliability portfolio this year (OKR PLAT-2026). The headline result: p99 API latency dropped from 840ms to 310ms across the three highest-traffic services, and the platform met its 99.95% availability SLO for the first time in eight quarters (board: platform-slo-2026). Most of the leverage came from work I didn't write the code for — I authored RFC #241 on standardizing our retry-and-timeout patterns, drove it through three rounds of review with the four affected teams, and partnered with the SRE lead to migrate the highest-risk services first. I wrote the migration runbook that every team used; four engineers shipped their service migrations using it without needing pairing time from me. On the people side, I ran the senior-engineer hiring loop, mentored two engineers through promotion to senior, and gave a tech-talk at our internal conference on retry semantics (recording in #eng-talks). Growth area: I'm strong at unblocking individual teams but want to invest more in cross-org influence — I'd like to lead one company-wide initiative outside the platform org next year.

What makes it work: the impact is portfolio-scale, the leverage shows up as other people shipping (not just your own PRs), and the growth area names a real next step rather than a fake weakness.

From brag doc to finished self-review: a full worked example

Most write-ups stop at the polished paragraph. The interesting part is the transformation. Here's a mid-level engineer's raw weekly notes for one focus area, and the self-review paragraph that comes out of them.

Raw brag-doc notes (across 11 weeks)

Wk 6  Shipped — PR #4980 fix to retry logic in payments. Flaky for ~6mo.
Wk 7  Incidents — IR-4471 retry storm during stripe outage. I was on-call. Wrote postmortem.
Wk 8  Reviewed — RFC #233 from B on circuit-breakers. Pushed back on default 5s timeout (too aggressive for batch jobs). They updated.
Wk 8  Shipped — PR #5018, real fix for the retry bug (not just the patch). +regression tests.
Wk 9  Influence — wrote runbook for payments on-call. Tested it w/ A during game-day.
Wk 10 Growth — read "Release It!" ch 5-7 on stability patterns.
Wk 11 Reviewed — 9 PRs this week. Median turnaround 3h.
Wk 12 Incidents — IR-4503, similar pattern in notifications. Coached J through it, didn't take over.
Wk 13 Shipped — extracted retry helper into shared lib (PR #5142). Used by 3 services now.
Wk 14 Influence — A and J both said the runbook made on-call manageable for them.
Wk 15 Numbers — checkout 500s: 1.2% -> 0.1% sustained 6 wks. Confirmed in Grafana.
Wk 16 Growth area — caught myself wanting to fix IR-4503 instead of letting J do it. Need to keep stepping back.

Polished self-review paragraph

This cycle I led the resolution of a long-standing reliability issue in the payments retry path. The bug had been mis-tagged as "flaky tests" for three quarters; I root-caused it during IR-4471 while on-call, shipped a patch (PR #4980), and followed up two weeks later with the real fix and regression coverage (PR #5018). Checkout 500s dropped from 1.2% to 0.1% of requests and held for six weeks (Grafana: checkout-prod). I then extracted the corrected retry logic into a shared library (PR #5142), which is now used by three services. Beyond the code, I wrote the payments on-call runbook and ran a game-day with a teammate; when a similar incident (IR-4503) hit notifications six weeks later, I coached a newer engineer through the response rather than taking it over, and they resolved it without paging me. PR review throughput stayed strong (median 3-hour turnaround). Growth area: I noticed my instinct during IR-4503 was to jump in and fix it myself — getting more comfortable letting others lead the response is what I want to work on next.

Every claim in the paragraph traces back to a specific bullet in the raw notes. There's no invention, no inflation. The work is the same; the retrieval is what changed.

Common self-review mistakes

A few patterns show up over and over when engineers under-sell themselves:

Adjectives instead of artifacts. "Strong technical contributor" means nothing. "Shipped PR #4821 cutting checkout 500s 92%" means something.
Burying leadership in the last paragraph. Mentoring, reviewing, runbooks, and RFCs aren't side activities — they're often where senior engineers create the most leverage. Lead with them.
The fake weakness. "I work too hard" reads as evasive. A real growth area names a specific next skill ("write design docs before prototyping") and signals self-awareness.
No baseline. "Improved API latency" is unfalsifiable. "API p99 dropped from 840ms to 310ms" is reviewable.
Skipping the boring wins. The deprecation you finally finished, the on-call rotation you covered, the dependency upgrade nobody else wanted — these often matter more at calibration than the splashy feature.

A note for managers reading this

If you're a manager and you're nodding along, you already know the asymmetry: your engineers carry the burden of remembering their year, and the ones who remember best aren't always the ones who shipped the most. PerfCopilot does for managers what the brag-doc method does for engineers — evidence in, draft out — pulling from the signals you already generate (PRs, tickets, 1:1 notes) so the review reflects the whole cycle, not the last sprint. More on the manager side here.

Frequently Asked Questions

How long should a software engineer self-review be?

Most rubrics ask for 300–800 words per competency, totaling roughly 1,500–3,000 words for the full self-review. Quality beats length — a tight 1,500 words of cited evidence beats 3,000 words of adjectives every time. If your company has a word limit, respect it; trim adjectives first.

What if I genuinely had a quiet quarter?

Be honest and specific. "This quarter I focused on stability work and learning the new ML platform; my biggest shipped item was X" beats inflating five small fixes into headlines. Managers respect calibration; they distrust spin. Use the growth section to name what you're investing in next.

Should I copy my self-review from previous cycles?

No, but you should reuse the brag doc. Last year's review paragraphs are dated; last year's PR links and incident numbers are still real evidence. The format can stay consistent across cycles — that consistency actually helps your manager and skip-level scan your file.

How do I write a self-review if I'm being put on a performance plan?

Stay factual, cite artifacts, and avoid defensive framing. The self-review is part of the formal record; vague self-criticism will be used against you, but so will vague self-defense. State what you shipped with evidence, acknowledge the specific gaps your manager has raised, and propose concrete next steps with measurable check-ins.

Is it okay to disagree with my manager's rating in my self-review?

Yes, but in the self-review draft your case with evidence rather than rebutting a rating you haven't seen yet. If a calibration disagreement happens later, the cited PRs, dashboards, and docs in your self-review are what you'll point to. Save the disagreement conversation for the review meeting, not the document.

Conclusion

The engineers who write the strongest self-reviews aren't the ones with the best memory or the best vocabulary. They're the ones who kept a brag doc open in a tab all year and spent ten minutes on Friday adding bullets. The self-review then becomes a filtering exercise: pull the strongest items, group them by rubric category, write each as situation-action-result-citation, and end with a growth area that sounds like a real next step.

Two things to do this week: start the brag doc (one file, append-only, five categories), and back-fill the last quarter from your Git history, ticket tracker, and Slack search. By the time your next review cycle opens, retrieval will be cheap — and your self-review will read like evidence, because it is.

Sources

Julia Evans, "Get your work recognized: write a brag document," retrieved 2026-05-19, https://jvns.ca/blog/brag-documents/