Self-Reflection and Impact

As a software engineer/developer, it's very easy to get caught in the day-to-day tasks, and to not spend time reflecting on accomplishments and growth.

There are a lot of disruptions that happen in a day between email/Slack, attending planning meetings, and triaging production issues. When none of those are occurring, a lot of time is spent on the craft of software engineering.

But how can you accurately articulate the progress you've made? Can you identify your areas where you've made great strides, and identify which ones you'd like to tackle next?

This is where writing an annual accomplishments document can come in handy.

I've found it's useful to reflect every 3-4 months or so on accomplishments since the context is still recent, but enough time has passed for impact to be visible.

A bonus of frequent reflections, is that there's no scramble to remember everything you've accomplished.

Sample Accomplishments Document

Major Projects

Lead/Champion

• Project X

  • Built functionality X with help from Sarah, Jane, and Tom
  • Involved at conception, design, stakeholder feedback, etc.
  • Metrics (more on this later)

• Project YYZ

  • Worked with John to see this project through
  • Contributed items 1, 2, 3 to the project
  • Metrics (see a trend?)

Contributor

• Minor feature 1
• Minor feature N

Production Issues Identified/Resolved

• Identified issue X that was affecting customers and came up with resolution by creating some thoughtful solution
• Started seeing performance degradation and solved by some advanced technique

Customer Escalations

• Major customer was experiencing issue ABC and helped jump on a call with them to help resolve

Mentorship

• Started working with Mandy
  • She started by working on smaller items but now is contributing at the same level as other members.

Self development

• Read books X,Y,Z
• Applied knowledge of that when building ....
• Attended conference on and shared discoveries with team

Note

Some things are obviously not the responsibility of a junior engineer like mentorship, or being the lead on a major feature.

But looking at these gives you an idea of what a more experienced engineer is probably doing. This can help frame a discussion with a manager to understand what you need to do to get to work on these types of things and achieve career goals and aspirations.

Metrics

All software engineers (ideally) build important things. But how important? What impact is that feature having?

When an individual is trying to get promoted or seek greater compensation, the first thing a manager will gauge is the person's impact. And how will you stand out from others?

Obviously with enterprise software it's a bit harder to gauge "impact", but with SaaS products, there's typically a data team. Any credible SaaS company will have a process/team to measure just about anything.

If nothing else you can contribute to that team by helping out. You can learn about how data is analyzed at a company, and that could be a form of impact itself!

I helped out the data team once for a couple of days, and by the end I was creating my own dashboard to track a number of my team's features using tools like Mode, Looker, and Snowflake.

Here's a sample of a couple of metrics I've used in recent years:

- Increased the number of things in a batch by 150%

- Reduced number of failures with partner X by 90% through better retry mechanisms and error handling

- Partner integration is now moving Y Million USD monthly, resulting in savings of 50% over old partner 

  -- Annualized savings of X hundred thousand dollars
  -- N payments are 1-2 days faster versus old partner

- Automated reconciliation process for X.  
  -- Saving X hours/day of manual work for finance team

- Enhanced reconciliation process by migrating it to use the data warehouse, thus reducing load on replica system.

- Feature X is now being used by 10,000+ customers with over 100M in gross volume this year.

- Improved performance of processing critical system event:
  -- Optimizing database query by X percent
  -- Caching data in an in-memory store 
  -- Increased durability of event using queueing technology 

Notes

It's always good to show an example of how these improvements are manifested in a system. Have a local example to show your database speedup.

Or if you are fortunate enough to work somewhere that uses APM tools like Datadog or New Relic, then most of this is discoverable for you and a breeze to show off!