Proactivity & Initiative

The Two Ingredients that Make the best Team Member

Over the years, I have come to appreciate the value of working with a proactive colleague over the past few years. There's nothing quite like it.

I was guilty in instances where I wasn't the proactive teammate I needed to be. I realized how many opportunities I missed just because of that. And not only that, but I feel sorry for the times I could have helped my team more.

And I’ve been on a quest to change that.

I'm increasingly starting to have proactivity as a trait rather than something that comes on and off. And that's because I found incredible satisfaction in working with people who cut through all the crap to get things done.

I have consciously made it a habit to exercise proactivity. And in any workplace, there're limitless opportunities to take initiative. Here are two examples of where I took the initiative at my new workplace.

First Case: The Abandoned Pull Request 

One of the many legacy services I stumbled upon in my first few months, I've found an abandoned PR that allows running the tests locally.

The project itself had no reliable CI, and no tests were written for the minor changes that needed to happen to it (the project is in a maintenance state but still needs minor changes from time to time)

Countless engineers have seen this PR and moved forward. But many others live with the scout boy mentality to make things around them better. In that case, I took it upon myself to make these changes happen.

Most of the heavy lifting was already done about a year ago. So I was lucky that all I needed was to complete and polish it to make it ready for release.

The Good Part: Increasing the reliability of legacy services is essential, and the work there can be noticeable too. Suppose it's your very first months in the company. 

Look at some low-hanging fruits like this. It'll allow you to pair with new engineers outside your team's scope, collect knowledge, and increase your reputation. 
 
This work can be done between your daily tasks; no need to dedicate a specific time block unless necessary.

The message you send here is that: You're someone the team can rely on and willing to do the work no one else wants. This alone can take you to places and increase your team's trust in you.

Second Case: Reviewing a PR on a legacy Service

Another quick example is when I reviewed a PR for another legacy service. Rules were not enforced for PRs on this service; tests are usually ignored.

I was reviewing the PR when I found new helper files are being created. I was asking if we could add tests to this file, and I got this response:

The PR author was nice and didn't mind writing tests. But there's a little pushback as writing tests for this service was not trivial.

So I did something I don't advise doing unless you communicate this correctly with PR authors, and it's that I pushed tests and small fixes to his branch. Be careful while doing so, especially with engineers that are not on your team. Ensure you communicate this correctly on the PR or your team communication channel.

And a good surprise? The tests revealed an error in the logic that was moved, exposing a wrong legacy way of reporting an error when it happens. So we got to fix it in that PR too.

During my time at the company, I have encountered numerous similar instances, and these are just two examples of many others.

Keep in mind that this approach helped me so much accelerate my learning. And it also got me to know many brilliant engineers in many different teams, which is helpful to me due to the nature of my role.

Being proactive will earn you a favorable impression and enhance your self-assurance and your team's trust. Such gains can unlock numerous opportunities; working with others will be like a breath. 

Conclusion:

In these past two use cases, I wasn’t obliged to take the extra mile in either of them or any others that I have taken and not mentioned here. It’s this proactive mindset that I learned from a lot of past amazing colleagues and now I am carrying with me

Somedays can be difficult, banging your head on the desk because of a problem you can’t figure out, or maybe countless meetings dragging you down, or just life happening.

I had these happen to me, and they were times when I wasn’t proactive about many things happening around me.

And that's okay; what worked for me was trying to make proactivity a merit of habit. So then it’s happening naturally, even after some setbacks. I don’t overthink it.

And so can you! If there’s any advice I can give to any new software engineer. It’ll be just that; Be proactive and take the initiative.