How to Remember What You Did for a Performance Review (2026 Guide)

Keep a brag document and rebuild the gaps from your calendar, commits, tickets and activity history. If you code, WakaTime summarizes editor time by project, but its free plan keeps one week of history. On a Mac, ActivityWatch logs apps and window titles for free, Timing adds AI activity summaries from $9 a month billed annually, and Dayflow writes a free narrative timeline.

You want to walk into your performance review with a short, specific list: what you shipped, what you fixed, who you helped and why each of those mattered. What usually happens instead is a late-night self-review the day before it is due. The last six weeks are vivid. The first eight months are a blur. The project you led in February gets one vague line, and the incident you quietly cleaned up in May gets nothing.

You do not need a better memory. You need evidence. Your calendar, commits, tickets and documents already hold most of the year, and so does your Mac’s activity history if something was recording it. This guide shows how to mine each source and turn the results into a review you can defend.

Dayflow is our product. It appears in one step as one option among several, and there is a section below on where it is the wrong choice. The method behind the tool details is a comparison of vendor documentation: competitor details come from each vendor’s own pages on October 4, 2026, and Dayflow details come from version 2.2.0.

The short version

1. Get the review questions, the rating criteria and the exact period being reviewed.
2. Start a brag document today and add to it every week.
3. Rebuild the past month by month from your calendar.
4. Pull your commits, pull requests, tickets and documents for the period.
5. Fill the remaining gaps with activity history from your Mac.
6. Turn the raw list into three to five impact stories, each with evidence.

What you need before you start

• Access to your work calendar for the full review period.
• Access to wherever your work lands: a git host, a ticket tracker, a shared drive, a design tool, a CRM.
• Last cycle’s review and any goals you set. Reviewers often compare against them.
• One document for notes. Plain text or Markdown is fine.
• A couple of uninterrupted hours for the first pass.
• Optional: an activity tracker.

One limit applies to the tracker. It only records from the day you install it. It cannot recover March if you install it in October. That is the strongest argument for setting one up now, months before the next cycle.

If your company issued the Mac, check its policy on monitoring and screen recording software before you install anything in step 5.

Step 1: What does your review actually ask for?

Before collecting anything, find the form. Most review processes have a template with fixed questions, a rubric or leveling guide, and a defined window, such as the last two quarters or the calendar year. Write those down at the top of your notes doc. Every item you collect later should map to one of them.

Illustration: suppose the form asks for three things: your biggest contributions, how you worked with others, and one area to grow. The leveling guide for your role mentions scope, execution and mentoring. That gives you buckets to sort into: contributions, collaboration, growth, scope and mentoring. Anything that fits none of them probably stays out.

The mistake to avoid is writing a chronological diary. Reviewers read many of these in a short time. A month-by-month account forces them to do the sorting you should have done.

Step 2: How do you keep a brag document?

A brag document is a running list of your work and why it mattered, kept by you, for you. It is the habit that makes every future review easier. It is also the source that takes longest to build, so start it before you dig into the past.

Keep each entry to four parts: the date, what you did, why it mattered, and a link to evidence. Add to it on a fixed day each week, such as Friday afternoon, while the week is still fresh. If you want a structure, the daily work log template suits short daily entries, and the weekly status report template suits people who would rather write once a week. If you already send your manager a weekly update, the brag doc can simply be a trimmed copy of those.

Illustration of one entry:

• Date: week of June 8
• What: Rewrote the onboarding checklist after new hires kept hitting the same setup error.
• Why it mattered: New hires stopped needing a pairing session just to get set up.
• Evidence: link to the doc revision and the team thread where it was announced.

The mistake to avoid is logging only big wins. The items people forget at review time are the small, repeated ones: interviews run, docs reviewed, new teammates unblocked, on-call weeks. Write those down too. They often separate a solid review from a strong one.

Step 3: How do you use your calendar to rebuild the year?

For the months before your brag doc existed, your calendar is the best map. Walk through it one month at a time in week view, and note three kinds of events:

• Recurring meetings that started or stopped. A new weekly sync usually means a new project. When it ends, the project probably shipped or was cut. Both are worth a line.
• One-off meetings you organized. Kickoffs, design reviews, postmortems and demos you ran are direct evidence of ownership.
• Time you gave to others. Interviews, mentoring sessions, onboarding buddy check-ins, talks you gave.

Illustration: in April you notice a recurring “Billing migration sync” that runs until mid-June, followed by a one-off “Billing migration retro” that you organized. That is a project with a start, an end and a retro. Now you know where to look in step 4.

The mistake to avoid is counting meetings as accomplishments. “Attended every design review” tells a reviewer nothing. Use the calendar as an index that points to the real output, then go find that output.

Step 4: How do you pull commits, tickets and documents?

Now pull the artifacts. For engineers, start with git. One command per repository gives you a dated list of your own commits for the period:

git log --author="you@example.com" --since="2026-01-01" --until="2026-09-30" --oneline

Your git host’s search for pull requests you authored and reviewed in the same window is often faster to scan, because PR titles are written for humans. Then do the same in your ticket tracker: closed tickets assigned to you, filtered by date.

If you write code, WakaTime can add a layer here. Its open source editor plugins record coding time per project, language and editor across 100+ editors, IDEs and terminals, and send it to a web dashboard. It also tracks AI coding usage, such as AI-generated versus human-written lines. Two caveats for review prep. It only sees work inside supported editors and terminals. And the free plan keeps 1 week of dashboard history, while full history requires Premium at $14/mo billed monthly or $12.83/mo billed $153.96 yearly. Unless you were already paying, it helps next year’s review more than this one.

For non-engineers, the equivalents are document revision history, files you created in the shared drive, sent mail filtered by project keyword, design files you own, and closed deals or tickets in whatever system you live in.

Illustration: the billing migration from step 3 turns up several merged PRs, a design doc you wrote, and a ticket where you documented the rollback plan. The design doc is the best evidence, because it shows the decision, not just the typing.

The mistake to avoid is reporting volume. Commit counts and ticket counts invite the wrong conversation. Pick the two or three artifacts that show judgment and link those.

Step 5: How do you fill the gaps with activity history on a Mac?

After steps 2 to 4 you will still have holes: weeks where the calendar was quiet and nothing shipped, but you know you were busy. That is usually investigation, debugging, reading, support and coordination, the work that leaves no artifact. An activity history is how you get it back, as long as something was recording at the time.

The tools here come in three shapes. For the wider field, see our roundup of Mac time trackers.

App and window logs. ActivityWatch records the active application, the window title and whether you were away from the keyboard. Browser extensions add the active tab title and URL, and editor plugins add coding activity. It is free and open source under MPL-2.0, runs on Windows, Mac, Linux and Android, and the vendor states all data stays on your own device. It lists no built-in AI summaries, so you read the timeline yourself. Our ActivityWatch vs Dayflow comparison goes deeper.

Automatic tracking with reports. Timing records time across apps, websites and documents on the Mac, down to specific URLs and Mail threads, and lists AI activity summaries on all plans. There is no free tier. Professional is $9 per month billed annually or $11 per month billed monthly, after a 30-day trial with no credit card required. The vendor says tracked times stay on your Mac unless you opt into sync. See our Timing comparison.

A written timeline. Dayflow records the screen at one frame every 10 seconds and has AI write each day into a readable timeline. For a review, the useful part is that the record is in sentences rather than app names, and you can export a date range as Markdown from Settings → Export (walkthrough: export your work history). The app is $0 and MIT licensed and needs macOS 14 or later. You choose where analysis happens: a local model through Ollama or LM Studio, your own cloud provider, or Dayflow Pro at $20 a month. The tradeoffs are laid out in local and cloud processing.

Illustration: your calendar and git history are blank for the second week of August. Your activity history shows most of that week in a vendor’s API docs, a support thread and a scratch branch. Now you remember. You were tracking down why a partner integration failed intermittently, and you found the cause. That is a review-worthy story with no artifact behind it.

The mistake to avoid is pasting the raw output. Hours in an app are not impact, and AI summaries can miss or misinterpret work. Use the history to jog your memory and find dates, then confirm each item against something real before it goes in the review.

Step 6: How do you turn the list into impact stories?

You now have a long, messy list. Cut it to three to five stories that map to the buckets from step 1. For each one, write four short parts:

1. Context: what problem existed and why it mattered to the team or business.
2. Your part: what you specifically did, in the first person.
3. Result: what changed, with a number only if you can point to where it came from.
4. Evidence: one or two links.

Underneath, add a short list of smaller items such as interviews, mentoring, on-call and documentation, so the glue work is visible without crowding the main stories.

Illustration: “Context: the partner integration failed intermittently and support was escalating it every week. My part: traced it to a retry bug in our client, wrote the fix and a runbook. Result: the escalations stopped after the fix shipped. Evidence: PR link, runbook link, support thread.”

The mistake to avoid is blurring “I” and “we”. Credit the team for team outcomes, but be precise about your own part. Your manager, and anyone calibrating ratings across teams, needs to know what you did, and vague plurals hide it.

Then close the loop for next year. Keep the brag doc going weekly, and if you run a tracker, skim its history before each entry. Remembering what you worked on covers that habit in more detail.

Doing it by hand vs with a tool

Approach	Effort	What you get	Cost
Manual: brag doc, calendar, git and tickets	High at review time unless you keep the doc weekly	Artifacts and dated events; nothing for unrecorded investigation or support work	$0
Start/stop timer app	Ongoing: you start and stop a timer for every task	Hours per task, only for tasks you remembered to label	Varies by app
WakaTime (coding tracker)	Low after plugin install	Coding time per project, language and editor; AI coding usage	Free plan with 1 week of dashboard history; Premium $14/mo billed monthly or $12.83/mo billed $153.96 yearly
ActivityWatch (automatic tracker)	Low after install; you read the raw logs	App, window title, away status and, with extensions, URLs; stored locally	Free
Timing (automatic tracker)	Low after install	Apps, websites, documents and URLs, with AI activity summaries	Professional: $9 per month billed annually or $11 per month billed monthly; 30-day trial
Dayflow	Low after install; check the AI summaries	Written daily timeline from screen frames; Markdown export	$0, MIT licensed; optional Pro at $20 a month

Again, Dayflow is our product. Every tracker in this table only covers the period after you install it, and none of them replaces steps 1 to 4.

Common mistakes

• Starting the week it is due. By then your only sources are the calendar and git. Start the brag doc the day after this review, not the day before the next one.
• Mixing the brag doc with private notes. Write it so you could paste any line into the review. Keep venting somewhere else.
• Treating tracked hours as performance. A tracker answers “what was I doing that week”, not “was it good”. Use it as an index.
• Forgetting glue work. Interviews, mentoring, code reviews, on-call and documentation rarely show up in commits. Scan your calendar specifically for them.
• Trusting AI summaries without checking. Any AI-written timeline can mislabel work. Confirm each item against an artifact.
• Installing a recorder on a work Mac without checking policy. Some employers restrict screen recording or monitoring software, even when the data stays local. Our piece on time tracking without surveillance covers the distinction.
• Inflating numbers. If you cannot show where a figure came from, describe the change in words instead.

Where Dayflow is the wrong pick

• You mostly write code and want coding metrics. WakaTime wins. It breaks down time by project, language and editor, and tracks AI coding usage across tools such as Claude Code, Cursor, Copilot and Codex. Dayflow’s output is a written timeline, not a coding-metrics dashboard.
• Your work machine is not a Mac, or runs macOS older than 14. Dayflow is Mac only and needs macOS 14 or later. ActivityWatch runs on Windows, Linux, Android and Mac.
• Your employer does not allow screen recording. ActivityWatch’s listed tracking is app names, window titles and away-from-keyboard status, which may fit a stricter policy. Check with IT either way.
• You bill hours or need team reports. Dayflow has no invoicing, payroll approvals, team reports or website blocking. Timing offers billing status tracking, customizable reports with rounding, a GrandTotal invoicing integration depending on plan, and shared projects for teams on its Connect plan.
• You want no AI in the loop. Dayflow’s timeline is written by AI. ActivityWatch lists no AI summaries and gives you the raw log.

The bottom line

Start a brag document today, whatever else you do. For the review in front of you, rebuild the year from your calendar first, then from commits, tickets and documents, and use step 6 to cut it down to a few stories with evidence.

For next year, add a recorder so the quiet weeks are not lost. WakaTime fits if your work lives in an editor. ActivityWatch fits if you want free, local raw logs or work across operating systems. Timing fits if you want polished reports on a Mac and can pay for them. Dayflow fits if you want a free written timeline you can export as Markdown, with the option to keep analysis on your Mac. Any of them will find the dates. Writing the review is still your job.

Frequently asked questions

What should I put in a brag document?

Each entry needs four things: the date, what you did, why it mattered, and a link to evidence such as a pull request, doc or thread. Include small, repeated work like interviews, code reviews, mentoring and on-call shifts, not just launches. Write it so any line could go straight into a self-review, and update it on the same day each week while the details are fresh.

How far back should I look when preparing for a performance review?

Cover the exact window your company reviews, which is usually stated on the form, such as the last two quarters or the calendar year. If it is not stated, ask your manager. Also reread last cycle's review and goals, because reviewers often compare against them. Older work belongs in the review only as context for something that landed inside the window.

Can I see what I worked on months ago on my Mac?

Only if something was recording at the time. Your calendar, sent mail, git history and document revision history go back as far as those services keep them. Activity trackers such as ActivityWatch, Timing and Dayflow store history from the day you install them, so they cannot recover earlier months. If none is running now, set one up for the next review cycle.

Is WakaTime better than Dayflow for a developer's performance review?

For coding metrics, yes. WakaTime breaks coding time down by project, language and editor across 100+ editors, IDEs and terminals, and it tracks AI coding usage. Dayflow writes a prose timeline of your whole screen, which covers meetings, docs and debugging outside the editor, but it is not a coding metrics dashboard. WakaTime's free plan keeps 1 week of dashboard history; full history requires Premium.

Does Timing have a free plan?

No. Timing lists no free tier. It offers a 30-day trial with no credit card required, then Professional at $9 per month billed annually or $11 per month billed monthly, Expert at $11 per month billed annually or $14 per month billed monthly, and Connect at $16 per user per month billed annually or $20 per user per month billed monthly. It runs on Mac only.

Is it OK to run an activity tracker on a work laptop?

Check your employer's policy first. Some companies restrict monitoring or screen recording software on company devices, even when the data never leaves the machine. ActivityWatch states data stays on your device, Timing stores tracked times locally unless you opt into sync, and Dayflow keeps recordings on your Mac with a local AI option. If the policy is unclear, ask IT before installing anything.

How do I write impact statements for a self-review?

Use four short parts: the context and why it mattered, what you personally did, what changed as a result, and one or two links as evidence. Write in the first person and credit the team for shared outcomes. Include a number only if you can show where it came from; otherwise describe the change plainly. A few strong stories read better than a long list.

Can AI write my performance review for me?

AI can help you find and summarize what you did, but it should not write the final review unchecked. AI summaries from tools like Timing or Dayflow can miss or misinterpret work, and they cannot judge what mattered to your team. Use them to jog your memory and locate dates, confirm each item against a real artifact, and write the impact in your own words.

Does Dayflow send my screen recordings to the cloud?

Recordings and the timeline are stored on your Mac. Where analysis happens depends on the mode you pick. Local AI through Ollama or LM Studio keeps screenshot analysis on-device. Your own provider receives selected screenshots under its own terms. Dayflow Pro processes selected screenshots in the cloud and, under the privacy policy, deletes them after processing while possibly retaining Activity Data for sync.