Don't be mistaken, your contributions graph doesn't tell the full story

ยท 1 mins read ยท ย Management

I see people sharing proudly their Github contributions graph to demonstrate their hard work. This definitely speaks volumes for their work-ethic and their mentality.

For sure this is something they have every right to brag about publicly but on the other hand this does not tell us actually the full story.

Don't be mistaken, your contributions graph doesn't tell the full story

# I know how important this might be

Personally speaking, I have done exactly the same in the past and I can understand how important this might be for them. It was really important for me too.

30 records per day was a good day, 50 was a successful one and so on. I was really proud of myself for such days while a day with less than 5 or 10 records, was a day I had to try harder. Simple as that.

Why? Because the activity graph was poor and I wanted others to look up to me and say that this is a really hard-working and respectful person.

Guess what? It worked. I got the acceptance and the knowledge I asked for, I evolved and yada yada.

# The other half of the story

At some point though, I started to realize that all this doesn't tell the whole story about me and my daily workload . Many duties of mine or things I was working on were not calculated in there. In fact, I couldn't even make them fit somehow no matter how much I wanted to.

Let's see some examples, so you can get a better picture:

  • prepare important architectural changes and solutions
  • create design documents
  • do some serious RnD regarding challenging requirements or features
  • keep an eye on latest technologies in order to come up with fresh ideas
  • create small proof of concepts that other engineers can use and build on top of them
  • invest some personal time on junior engineers development
  • do some pair programming with other teammates to demonstrate some patterns and alternatives
  • create a handbook so that new team-members can have a smooth onboarding process
  • establish an internal styleguide with some best practices and well-defined patterns to facilitate other developers
  • develop a design system by working closely with the UI / UX team
  • prepare an informative presentation for your team or even the whole firm about something really important you have been working on
  • prepare and attend efficient interviews
  • arrange and run effective 1-1s regularly

...and many more ๐Ÿ˜‰

# People and Architecture

As you see, most points have to do with other people progress and development, so they are not about ourselves. The rest relate mostly with critical architectural decisions, so they affect again a group of people or even more than one teams of developers.

These two pillars are rather important since they define the companies themselves and play a huge role in their success.

Can we showcase the effort people put in these by using the contributions graph? Hmmm, probably not, right? ๐Ÿ˜ธ

That said, the contributions graph definitely tells a story but not the full one. The more experienced and impactful we become, the more we deal with things that cannot fit in there, especially when it comes about influencing and leading other people. Cheers!!

Newsletter

Get notified about latest posts and updates once a week!!