What counts as an accomplishment for a software engineer?

I used to think accomplishments were the things you could put in a release note.

Shipped feature.

Closed project.

Big migration.

Something with a name, a launch date, and hopefully a graph moving in the right direction.

But that view is too small.

It misses the work that keeps systems healthy. It misses the decisions that prevent bad projects. It misses the mentoring, the debugging, the coordination, the “I fixed the thing before anyone noticed it was becoming a problem” kind of work.

And then review season arrives.

You open the self-review form and your brain gives you this:

I worked on the billing migration.

That is not useless, but it is not an accomplishment yet.

An accomplishment is not just the work you did. It is the work plus the change it created.

For a software engineer, an accomplishment usually has three parts:

1. What changed
2. Why it mattered
3. What evidence proves it

If you only save the task, you are saving the weakest part.

Let’s make this concrete.

A task is not the same thing as an accomplishment

Here is a task:

Refactored the checkout flow.

Here is the same work turned into an accomplishment:

Refactored the checkout flow by splitting payment, tax, and confirmation logic into separate modules, reducing checkout-related regressions from 6 in the previous release cycle to 1 in the next release cycle.

The second version is stronger because it has shape.

It tells me what changed. It tells me why the change mattered. It gives me a number that a manager can repeat in a calibration conversation.

This is the part many engineers skip.

We remember the task because the task was visible to us. The ticket. The pull request. The late afternoon debugging session. The Slack thread with too many replies.

But your review is not graded on how vivid the work felt while you were doing it.

It is judged on whether someone else can understand the impact later.

Feature work counts, but only if you keep the result

Feature work is the easiest category to recognize.

You built the onboarding step. You added the export. You shipped the dashboard. You implemented the integration.

But even feature work becomes weak if you only record the implementation.

Weak:

Built the new onboarding checklist.

Better:

Built the new onboarding checklist that guided users through API key creation, MCP client setup, and first memory capture, reducing setup questions in support from 12 per week to 4 per week.

The better version does not worship the feature. It explains the business or user change.

When you finish feature work, save more than the PR link.

Save:

• the user problem the feature addressed
• the before state
• the after state
• adoption, conversion, support, revenue, or usage signals
• the tradeoffs you made
• any follow-up feedback from users, support, sales, or your manager

You do not always need perfect metrics.

But you do need some proof that the feature mattered.

Reliability work counts

Reliability work often gets treated like maintenance.

And maintenance sounds small until it fails.

If you reduced alerts, removed flaky tests, improved deploy confidence, cleaned up a slow query, or made an incident less likely to happen again, that is an accomplishment.

Weak:

Fixed flaky tests.

Better:

Reduced checkout test flakiness by isolating payment-provider mocks and replacing shared test state, cutting failed CI retries from 18 per week to 3 per week.

Weak:

Improved API performance.

Better:

Reworked the report-generation query path, lowering p95 response time from 4.8s to 1.6s for large accounts and removing a timeout that blocked monthly review exports.

Reliability work is easy to understate because the best outcome is often silence.

No outage.

No angry support thread.

No rollback.

No “why is CI red again?” message at 6 PM.

That silence is valuable, but you need to translate it.

Save the incident notes. Save the before and after charts. Save the alert volume. Save the rollback count. Save the Slack message from the teammate who said the deploy finally felt safe.

Those artifacts make the invisible visible.

Technical decisions count

Sometimes the accomplishment is not the code.

Sometimes it is the decision that prevented months of bad code.

Maybe you pushed back on a brittle abstraction. Maybe you simplified a proposed architecture. Maybe you chose the boring database table instead of the exciting distributed system. Maybe you wrote the design doc that helped the team avoid a rewrite.

Weak:

Wrote design doc for notification system.

Better:

Wrote the notification-system design doc that aligned product, backend, and mobile on a single event model, preventing three parallel implementations and unblocking the Q2 release plan.

This kind of work is dangerous to forget because it rarely has a clean “shipped” moment.

There might be a document.

There might be a meeting.

There might be a comment thread where the important thing happened between lines 47 and 68.

Keep it anyway.

For technical decisions, save:

• the problem statement
• the options considered
• the tradeoff you recommended
• who needed the decision
• what the decision unblocked
• what risk it avoided

This is especially important as you move toward senior, staff, or principal expectations.

At some point, your job is not only to write good code. It is to improve the quality of decisions around the code.

Glue work counts

I know what you might be thinking.

“But I was just helping people.”

Yes.

And helping people can be leverage.

Glue work counts when it changes team output. Mentoring counts when it improves someone’s independence. Coordination counts when it removes ambiguity. Unblocking counts when it gives time back to multiple people.

Weak:

Helped junior engineers with code reviews.

Better:

Mentored two junior engineers through their first ownership areas by pairing on design docs and reviewing 14 PRs, reducing repeated review feedback and helping both ship independently by the end of the cycle.

Weak:

Coordinated with the platform team.

Better:

Coordinated the frontend and platform migration plan across three teams, resolving ownership gaps around auth redirects and keeping the launch on schedule.

Glue work becomes weak when you describe it as personality.

Helpful. Collaborative. Supportive.

Those words are fine, but they are not enough.

Describe the mechanism.

Who was blocked? What changed after you got involved? What decision became clearer? What rework disappeared? What did the team ship faster because you connected the dots?

That is where the accomplishment lives.

Debugging counts

Debugging is one of the easiest accomplishments to lose.

You spent two days chasing a bug through logs, feature flags, a stale cache layer, and one suspicious deploy from last Thursday.

Then you fixed it.

The incident disappears.

Everyone moves on.

By review season, your memory has compressed the whole thing into:

Fixed production bug.

That is not enough.

Better:

Identified a stale cache invalidation path that caused duplicate invoice emails for enterprise accounts, shipped a fix, and added regression coverage that prevented the issue from recurring in the next 6 weeks.

For debugging work, save the trail:

• symptoms
• affected users or systems
• root cause
• how you found it
• fix
• prevention
• follow-up test, monitor, alert, or runbook

The “how you found it” matters more than engineers usually admit.

Debugging shows judgment. It shows system knowledge. It shows calm under ambiguity. But only if you record the evidence before the details fade.

Process improvements count

Process work can sound like bureaucracy.

Sometimes it is.

But sometimes it is the highest-leverage engineering work in the room.

If you improved deploys, reduced review wait time, clarified ownership, removed repeated manual work, or made onboarding easier, that can be an accomplishment.

Weak:

Improved release process.

Better:

Reworked the release checklist and ownership handoff, reducing average release prep from 2 hours to 35 minutes and removing the recurring dependency on a single senior engineer.

Notice the difference.

The better version does not say “process” as if process is automatically good. It shows the cost before and the cost after.

That is the standard.

If the process improvement saved time, reduced errors, improved confidence, or removed a bottleneck, write that down.

What should you save as evidence?

Do not wait until you have a perfect accomplishment sentence.

That is the trap.

Save the raw material first. You can turn it into a polished bullet later.

Useful evidence includes:

• PRs with meaningful implementation or review discussion
• design docs and decision records
• incident reports and postmortems
• before and after metrics
• dashboards, alerts, or support-ticket counts
• launch notes
• customer or stakeholder feedback
• Slack threads where a decision was made
• code review comments where you changed the direction of the work
• mentoring notes and examples of someone becoming more independent
• 1:1 notes where your manager called out impact

You do not need to store confidential details to keep useful evidence.

You can redact customer names, exact revenue, secrets, internal URLs, and implementation details that do not belong in a personal system. What matters for your career record is the shape of the impact.

For example:

Improved report export performance for a large enterprise account after the monthly review workflow timed out.

That is usually safer than:

Fixed /internal/customer/123/reports?token=... for Acme’s $842,000 renewal meeting.

Same accomplishment direction. Much better boundary.

A simple test

When you are deciding whether something counts as an accomplishment, ask this:

Did my work change the state of the system, the product, the team, or the decision?

If yes, it probably counts.

Then ask:

Can I prove the change later?

If the answer is no, save the evidence now.

That evidence does not need to be perfect. It just needs to be real enough that future-you is not forced to reconstruct the story from vibes.

The pattern to use

If you want a practical format, use this:

Changed X by doing Y, which created Z.

Example:

Changed deploy confidence by adding smoke tests around the billing flow, which reduced failed production deploys from 3 in May to 0 in June.

Or:

Changed onboarding speed by rewriting the API key setup guide and adding validation states, which helped new users complete their first memory capture without support.

This is close to the X-Y-Z style I like because it forces the work to answer a real question:

What changed?

If you cannot answer that yet, do not panic. Capture the artifact anyway.

The PR. The doc. The metric. The decision. The support thread. The feedback.

You can shape the sentence later.

Quick examples

Here are a few categories worth tracking.

The exact numbers will depend on your work.

But the shape is always the same: before, action, after.

FAQ

What are good accomplishments for a software engineer?

Good software engineer accomplishments include shipped product changes, reliability improvements, performance work, debugging, technical decisions, mentoring, process improvements, and glue work that changed team output. The important part is not the category. The important part is whether you can explain what changed and why it mattered.

Do software engineer accomplishments need metrics?

Metrics help, but they are not the only proof. You can also use before and after examples, incident notes, stakeholder feedback, reduced manual work, fewer repeated questions, faster reviews, clearer ownership, or avoided risk. Perfect metrics are useful. Real evidence is more important.

Is helping teammates an accomplishment?

Yes, when it changes the team’s output. Helping is stronger when you can show the mechanism: someone became more independent, a project got unblocked, review feedback stopped repeating, a decision became clear, or multiple people saved time.

What should I save for my performance review?

Save the raw evidence behind the work: PRs, design docs, incident notes, metric screenshots, launch notes, feedback, Slack decisions, code review comments, and short notes about what changed. You can turn those into polished self-review bullets later.

The real point

Your accomplishments are usually bigger than your ticket list.

They are hidden in the problems you prevented, the systems you made calmer, the teammates you unblocked, the decisions you clarified, and the evidence you forgot to save.

That is actually why I started building careercraft.ing.

Not because engineers need another place to write polished career prose.

Because by the time we sit down to write the prose, the source material is already gone.

So start smaller.

When something meaningful happens, save the raw evidence.

Future-you can turn it into a self-review, promotion packet, resume bullet, or manager update.

But only if present-you keeps the proof.