How to Write a Self-Review When You Cannot Remember What You Did All Year

Self-review season is here. You open the form. You stare at the blinking cursor. And you realize you cannot remember what you did for the last six months.

You know you were busy. You remember some vague sense of shipping things, sitting in meetings, and fixing fires. But when it comes time to list specific accomplishments with measurable impact? Your mind gives you nothing useful. Maybe a project from last month. Maybe that one big launch from three months ago. Everything before that feels like a fog.

You are not losing your mind. You are experiencing something predictable, well-documented, and fixable right now, even if you never kept a brag doc. (And if you want to prevent this next cycle, tracking your accomplishments throughout the year makes the reconstruction work optional.)

Why your brain is working against you

This is not a personal failing. It is how human memory works.

Murre and Dros (2015), replicating Ebbinghaus's original forgetting curve research, confirmed that people lose roughly 67% of newly learned information within 24 hours. Within a week, that number climbs toward 90% for material you have not revisited. Your brain does not treat daily work as something worth storing in long-term memory. It was busy doing the work, not cataloguing it.

This is compounded by recency bias. A survey by Engagedly found that 78% of managers admit their performance reviews are influenced by what employees did in the last month rather than the full review period. The same bias hits your own self-evaluation. When you sit down to write, your brain hands you the last four to six weeks and shrugs at everything else.

The result: you undercount your accomplishments by a wide margin. Maintenance work, smaller bug fixes, cross-team collaboration, mentorship, and the slow grind of keeping systems running all vanish from memory first.

The 90-minute reconstruction method

You do not need a brag doc to write a strong self-review. You need a systematic process for excavating the digital breadcrumbs you have already left behind. (If you want to prevent this problem next cycle, the brag doc template for software engineers gives you a low-effort system that takes two minutes per week.) Set aside 90 minutes, open six tabs, and work through each source below.

Source 1: Your pull request history

Your git history is the most reliable record of what you actually built. Open your team's repository and filter PRs by your name for the review period.

• Scan PR titles for patterns: what kinds of problems were you solving?
• Look at PR descriptions for context you wrote at the time (past-you was more detailed than present-you remembers)
• Pay attention to large PRs and to clusters of small PRs that add up to a bigger story
• Note any PRs where you reviewed others' work, especially if you caught significant issues

Write down every PR that represents meaningful work. Do not filter yet. Capture everything.

Source 2: Your ticket history

Open Jira, Linear, Asana, or whatever your team uses. Filter by assignee (you) and the review period. Sort by completion date.

Tickets tell a different story than PRs. They show:

• Projects you owned end-to-end
• Bugs you triaged and resolved under pressure
• Spikes and investigations that informed team decisions
• Work that never resulted in code (design docs, architecture decisions, vendor evaluations)

Many engineers forget that investigation and decision-making count as accomplishments. If your spike prevented the team from building the wrong thing, that is high-impact work.

Source 3: Slack and messaging history

Search your Slack (or Teams) messages for the review period. Look for:

• Threads where you answered technical questions from teammates
• Channels where you shared updates on projects you led
• DMs with your manager where you discussed progress or decisions
• Messages where someone thanked you or flagged something you did

Slack is where informal mentorship, cross-team collaboration, and incident response live. None of it shows up in git logs. Search your own messages for keywords like "shipped," "fixed," "resolved," "launched," "decided," and "updated."

Source 4: Your calendar

Open your calendar and scroll through the review period month by month. Look for:

• Recurring meetings you owned or facilitated
• Interviews you conducted (each one is 45-60 minutes of company contribution)
• Presentations you gave to stakeholders
• Onboarding sessions where you helped new team members
• Incident bridges you joined

Your calendar shows the work that has no artifact. If you spent 30 hours interviewing candidates over six months, that is a real contribution your self-review should reflect.

Source 5: Documents you created or edited

Search Google Docs, Notion, Confluence, or your team's wiki for documents you authored during the review period. Filter by "owned by me" or "created by me."

Design documents, RFCs, postmortem write-ups, runbook updates, and architecture proposals are all evidence of senior-level thinking. They also tend to be the work you forget fastest because the document feels like a means to an end, not an accomplishment itself.

Source 6: Team retrospectives and standups

If your team keeps retro notes or standup logs, skim through them. These capture what felt important at the time, including projects and problems that may have completely left your memory.

Also check if your team published any sprint reviews, demo recordings, or quarterly summaries. Your name might appear in contexts you have forgotten.

How to turn raw evidence into self-review language

After 90 minutes of excavation, you should have a messy list of 15 to 40 items. Now you need to shape them.

Group by impact category

Sort your raw list into three to five buckets. Common categories for engineers:

• Technical delivery (features shipped, systems built, migrations completed)
• Reliability and operations (incidents handled, monitoring improved, on-call contributions)
• Team multiplier work (mentorship, code reviews, onboarding, process improvements)
• Strategic contributions (design docs, architecture decisions, cross-team alignment)

Grouping reveals your story. If half your list falls under reliability, your self-review should lead with how you kept critical systems running, not apologize for not shipping enough features. The software engineer self-review guide covers how to structure the final write-up once you have your evidence sorted.

Rewrite each item with the impact formula

For each significant item, apply this structure:

What you did + why it mattered + what the result was

Before: "Migrated the payments service to the new API."

After: "Led the payments service migration to the v3 API, reducing payment processing latency by 40% and eliminating the most common source of on-call pages for Q3."

The difference is context and measurement. You do not need exact numbers for everything. Directional impact ("reduced," "eliminated," "cut in half") is better than no measurement at all.

Do not undercount maintenance work

Engineers consistently undervalue the work that keeps things running. But reliability, operational improvements, and technical debt paydown are exactly the kind of work that gets overlooked in calibration if you do not write it down.

If you spent two months stabilizing a flaky service, say so. If your on-call improvements reduced page volume for the team, quantify it. If you upgraded a dependency that had been blocking three other teams, name the teams.

The work that felt boring while you were doing it is often the work that has the highest organizational impact.

The 30-minute assembly

With your categorized, rewritten evidence in hand, assembly is straightforward.

1. Open with a one-paragraph summary stating your top two or three contributions for the period. This is the sentence your manager will copy into their calibration notes, so make it count.

2. Dedicate one section per category. Lead each section with your strongest item. Support with one or two additional examples. Three to four well-documented wins per category is more persuasive than eight thin bullet points.

3. Close with growth areas you are already addressing. Every self-review asks about development areas. Name one or two things you are actively working on, framed as forward motion, not confession. "I am building deeper expertise in distributed systems design, starting with the caching architecture project I proposed for Q2" reads better than "I need to get better at system design."

How to prevent this next time (without it feeling like homework)

The fastest prevention method takes less than two minutes per week. Every Friday, write down three things you shipped, solved, or contributed to. That is it. A bullet list in a notes app. A pinned Slack message to yourself. A recurring calendar reminder with a text box.

You do not need a formal brag document. You do not need a template. You just need a weekly habit of writing three bullets before you forget them. Six months from now, when the next self-review form opens, you will have 75 or more data points instead of a blank page.

---

Stop scrambling every review cycle. CareerClimb logs your wins all year and helps you turn them into self-review evidence automatically, so you never face a blank form again.