Action Needs Taking

What taking action looks like in software engineering life.

The single most common trait amongst impressive people I have met, is one. 
Massive inclination towards action. 

This sounds vague, but it really isn’t. It can be made very specific.
What is the smallest step I can take towards solving a problem? Do that. And do it now.  

Since this does not come naturally to me, I am actively working on it. These are my reflections on how it has played out in my engineering life so far.

Small actions lay the land

I need to make changes in critical code I haven’t written. I jump straight into the code. I create new types and methods. I only add signatures, no implementation. I find the areas affected. (Beware of things the compiler can’t catch. But this is for another post.) With the knowledge gained, I adjust my work or start from scratch. This was an exploratory session that shed light on the path.

Honestly, that’s what I do now. Previously, I would explore the codebase and take notes on the affected pieces to craft a “thoughtful” solution. I procrastinated on thinking about the thing, instead of doing the thing.

Small actions bring quick wins

Merge requests were piling up. The daily open MR count was ~40 and that was not good. We had feature dedicated reviewers, code owners and a code-review channel. But that didn’t cut it. 

I created a script that would query the GitLab API, get open MRs, sort them by days open, arrange them by reviewer and mention people to take action.

That may sound cool but it wasn’t. It took me way too much time to do it. I wanted to build a full solution, so my mind postponed starting on it.

This is how I would do it now:
Minimum action: Spend 5 minutes daily to check the MR status and mention people. This would start solving the problem day one and it would help me understand the domain better.
Next action: Create a script doing the basic thing.
Next action: Use the feedback loop to improve the script.

Actions set the tone

One day the biggest business opportunity arrived. The company needed to move fast. Requirements were vague. Changes were needed from the backend. Not much that we (the mobile team at the time) could do. 

The department lead gathered us in a room. He said “We go to the meeting room, laptops out and we start coding right now". We added the feature flags we would need. We created the dev environment settings (test accounts etc). We added the first mocks to explore the components affected. We even started on the expected UI changes.

That set the tone for the whole team. Needless to say, this feature was one of our greatest success stories.

Action needs taking

Another team needed to enhance their API for a new feature. The workflow was complex, they were busy and they were delaying it. It’s on them, right? Well, we cared about advancing it. And all we needed was a contract. The rest we could handle with our mock setup.

I checked the API they had already, and considered how to extend it. I came up with the method definitions and created a sequence diagram to communicate the flow. I arranged a meeting to address any questions. Then, I asked them to either go with it or make concrete suggestions. They left the contract almost intact and we moved forward. 

Recently, I heard this quote and it stuck with me. 

The work needs doing.
It doesn’t care about who does it.

Indeed. Action needs taking.