DEV Community: Atul Sharma

Self-Reflection and Impact

Atul Sharma — Sat, 10 Oct 2020 01:14:26 +0000

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!

Git better with fixups

Atul Sharma — Thu, 18 Jun 2020 01:29:55 +0000

Intro

By now I'm sure many of you are familiar with the Github Flow.

Before I introduce some clever git commands to help maintain a clean git history, it's helpful to review some good git principles.

5 rules to Git Better

If that link is not available the 5 rules are:

Make commits as small as possible
Write meaningful commit messages
Rebase always
Don’t squash everything
Commit instead of commenting out

Alright, now that we have that out of the way let's look at a common situation.

Let's assume the following as a starting point for the suggested workflow in this post:

Preconditions

You want a clean Git history

You don't want to rewrite your git history consistently

Situation

# coding the component

$ git commit -m "add some component"

# missed an edge-case

$ git commit -m "fix missing null check"

# add component to service

$ git commit -m "add component to service"

# updating the component after service tests found a bug

$ git commit -m "fix component due to silly bug"

$ rubocop

# fix linting errors

$ git commit -m "fix linting errors"

# team members do a code review on the PR / MR

$ git commit -m "fixes based on PR comments"

Now this history isn't uncommon (in fact I can't think of many PRs of real substance that don't go through something like this).

This will result in a Git history that looks like this

fixes based on PR comments
fix linting errors
fix component due to silly bug
add component to service
fix missing null check
add some component

But is that really reflective of the work? We don't want the commit history to be littered with "fix linting" commits.

This is actually representative of the work.

add component to service
add some component

Solution

Let's go about these "fixes" in a different way.
We'll use the familiar command git commit but with an interesting flag called (appropriately) fixup.

# coding the component

$ git commit -m "add some component"

# missed an edge-case

$ git commit --fixup <COMMIT HASH OF THE COMMIT "add some component">

# add component to service

$ git commit -m "add component to service"

# updating the component after service tests found a bug

$ git commit --fixup <COMMIT HASH OF THE COMMIT "add component to service">

$ rubocop

# fix linting errors

$ git commit --fixup <COMMIT HASH OF THE COMMIT "add component to service">

# team members do a code review on the PR / MR

$ git commit --fixup <COMMIT HASH OF THE COMMIT "add component to service">

Now if we look at the git log we'll see

fixup! add component to service
fixup! add component to service
fixup! add component to service
add component to service
fixup! add some component
add some component

Instead of regularly committing (and also writing a commit message) we use the --fixup flag to create fixup commits.

Now, before merging the merge request, we issue an interactive rebase with the --autosquash flag.

Note:

GitLab marks MRs that include fixup commits as WIP, so
merging is prevented if you haven't squashed.

$ git rebase --interactive --autosquash \
  <COMMIT HASH OF THE COMMIT "add some component">~1

We'll enter interactive rebase mode with the relevant commits already marked for fixup:

fixup afa6970 fixup! add component to service
fixup 1da5d7c fixup! add component to service
fixup c998b08 fixup! add component to service
pick d9731b5 add component to service
fixup 33d6080 fixup! add some component
pick 73e8a6a add some component

The resulting Git history looks like this:

add component to service
add some component

The final result is a very consistent and readable Git history, where every other developer knows what happens, without knowing about every bug on the journey to this final code.

Summary

In summary, the following two Git commands are necessary to make use of the Git fixup workflow:

$ git commit --fixup <COMMIT THAT NEEDS FIXING>
$ git rebase -i --autosquash <FIRST COMMIT THAT NEEDS FIXING>~1