A Productive Engineer

January 10, 2020

TL;DR

Article Outline:

Introduction
Being busy is not being productive
Meeting
Processes over tools
Distractions

Over the years, I have noticed that I am most productive when I work from home or when I work after people leave or before people arrive at my workplace. This caused for a self-reflection and I began to ask the question; “why am I most productive during these times?”. After much thought, it has come down to: Meetings, Processes over tools and Distractions. In this article, I discuss my personal view and experiences of how this elements hinder productivity and in some cases proffer solutions that work for me. I hope you enjoy it.

Introduction

Software Engineers like to build stuff (cool stuff), use new technologies, pay technical-debt, make existing solutions faster, find new ways to approach existing solutions. All this and more are what makes a software engineer pumped up and ready to work every other day.

The reason we call them software engineers in the first place is because of their ability to solve simple and complex problems with software systems by applying software engineering principles to design, develop, maintain and test software systems.

One of the most difficult jobs in software engineering is tracking software engineers’ productivity, which is even more difficult is communicating their productivity to top management and business stakeholders. This is usually the job of an engineering manager.

It is easier to communicate to management that an increase in the marketing budget by 40% will increase the conversion, sign-up or app download rates by a certain percentage with the show of data and some predictive analysis.

In comparison, from an engineering manager’s perspective, how do they justify to management the need for an additional hire say a PHP engineer when there are already say 4 of such engineers on the ground? Considering the challenge in measuring the work output and productivity of the already existing engineers. There are data points and metrics to measure software engineer’s and engineering teams productivity and also communicate it, but, I would cover that in another series.

I have noticed certain practices at the workplace that stalls software engineers’ workflow thereby making them less productive. In the next sections, I will dig deep into these practices in more details.

Being busy is not being productive


“No thanks, we are too busy” Image credit - Google Images.

I bet you’vs seen a busy engineering team, but at the end of the week, there is nothing to show for their busyness. Don’t get it twisted, being busy doesn’t mean being productive.

I don’t think any software engineer leaves their home in the morning with the sole purpose of coming to work to faff. For this write-up, a productive software engineer is that software engineer that spends at least about 80% of their daily work time writing software the solves users problems in a better, faster and easier way. This always involves using certain tools to:

As a software engineer, after everyday work, I ask myself, was I productive today? and I can tell you for a fact that in the past 4 years I have only answered “yes” to that question 40% of the time. Below are elements that stand out and hinder me from being productive as a software engineer.

1. Meetings

Software craftsmanship requires that software engineers be in a certain flow within a certain period during the day or night, this flow is difficult to get into, but when you get in this flow, awesome things happen(at least for me). One common practice at the workplace that stops me from getting into the flow or takes me out of the flow is meetings.

And I am not talking about those meetings that are pre-planned(daily stand-up, refinement, retrospective and sprint planning); I am referring to those meeting that adds no significant value to your job as a software engineer. I mean those meetings someone from product asked you to join in case there is a technical question that needs to be answered. I am talking about those meetings you joined because you think you will miss out on crucial information if you don’t, a symptom widely known as FOMO

I often hear different companies argue that these meetings are not compulsory and you can choose to decline. What these companies don’t realise is the amount of time needed to reject or accept meeting invites and more importantly, the havoc caused by the noise and distractions from emails or push notifications as a result of this meeting invites. As you read on you will learn how I mitigate noise and distractions caused by emails and push notifications.

In my experience, the meetings described above is a symptom of not having technical product managers or technical team lead or engineering manager. If the product managers are not technical, then you need an engineering manager and maybe a technical team lead. The technical team lead is not always needed as a senior engineer in the team can always act in the same regard as a technical team lead. If the product managers are also technical, having an engineering manager is highly advised. And if for any reason you already have these roles filled within your team or organization and you still see this problem at large, then one of these guys aren’t doing their job.

2. Processes over tools

As I mentioned before, writing software that solves user problem in an easier, better and faster way always involves using certain tools. These tools are by far the most important aspect of shipping working software/product to the user on time. These tools are so important that some companies have dedicated teams that build tools to make software engineers life better. Some common name of such teams includes infrastructure teem, engineering productivity team as used by Google.

Now, with the level of importance these tools have, one would expect engineering teams to invest time and other resources into the building, buying or leasing the best tools needed for the job, but surprisingly that is not the case as a lotThis is based on engineering teams I have personally encountered and not any publicly available data. of product and engineering teams have now replaced those tools with processes.

A classic and maybe very popular example is release management. Today one would assume that shipping tested and working software should be as easy as merging to a master branch but consider this real-world scenario I personally encountered.

Scenario

Max a mid-level software engineer, picks a task with the highest priority from the backlog, he completes the implementation in 2 days and makes a pull request (PR) against a branch called test. At this stage other software engineers start reviewing the pull request for code and implementation quality, consistency with products coding standard and many other reasons. The pull request is accepted and changes are deployed to the test environment. The quality assurance team(QA) now takes over to do some manual testing, Max gets lucky and his implementation is accepted by the QA. Now you are probably thinking finally, we are going to ship this feature to the customer, sorry to disappoint you, we are not.

The next step is for Max to make another PR to a branch called stage which from an argument I have been made to understand is an integration branch. Luckily for Max, no code review is needed at this step, but he has to merge and deploy to the stage/integration environment. After deploying to the integration environment, the QA takes over to do another round of testing, if all is good they give an okay to ship the changes to the customer. This makes it the 4th day since Max first interacted with the task.

Unfortunately for Max, it is now 5 PM and release would have to wait till the following day, poor customers, I bet you also feel for the customer as much as I do. But there is hope, the release would happen the following day. Oh wait, the following day is Friday and this particular engineering team has a no Friday release policy (😀). Well, it is what it is, they can’t risk making production changes on a Friday, there is a lot of what if; what if the release fails and we need to roll back, what if the release breaks another feature and we only detect this over the weekend. Our poor customers will have to wait until Monday.

Finally, its Monday, and we are able to release the working software to the customer. This scenario probably sounds made-up but it is not as I experienced this firsthand. For this scenario, below are some things I think could have been done to improve the development process for the engineer and reduce the time taken to ship working software to the customer.

3. Distractions

Often have I heard the phrases, “I am more productive in the morning”, “I am more productive at night”, “I am more productive from home” etc. After asking myself and a few other engineers, I realize one common theme with the engineers that make these comments. These engineers are either not distracted during this period, or they have fewer distractions during this time.

Researchers at the University of California, Irvine, found after careful observation that the typical office worker is interrupted, on average, every 3 minutes and 5 seconds. And it can take 23 minutes and 15 seconds just to get back to where they left off. If you have 8 working hours in a day, removing compulsory and pre-planned meeting and lunch, you probably have 6 hours in total to do real work. If you get distracted for at least 6 times during those 6 hour period you end up with having less than 4 hours to do real work as the half of the time was probably spent getting back into the zone.

I categorise distraction into two forms; direct and indirect distraction.

Direct Distraction

Direct distractions are those distractions that are primarily created by the software engineer or those they have 100% control over. All form of communication falls into this category, IM, slack, emails, and social media. This services or tools themselves do no harm, distraction is mostly caused by how we use them. Below are ideas on how to reduce distractions caused by how we use these tools or services.

Indirect Distraction

Indirect distractions are those distractions that I cannot control. Distraction from colleagues falls into this category. Think about the way most offices are set up. In an open floor plan, where everyone can see one another. it’s easy for someone to walk by and ask, ‘Got a minute?’ right when you’re about to get into the zone, and we all know a minute is never just a minute. I haven’t found a solution that works for me to avoid this kind of distraction, but, thankfully trivago where I work at the time of this writing, has this concept of focus rooms that tackles this problem.At trivago, the focus room is where you go if you want to get work done and avoid distractions from colleagues because it has strict rules like:
1. You are not allowed to speak to one another or make any kind or noise.
2. No one is allowed to pull you out unless there is an emergency.

Meetings generally also fall in this category. In my first point above, I discussed how meetings can hinder one from optimum productivity. Meetings are very difficult to control, especially when you are not the one setting up the meeting. However, there are things you can do to get the most out of your days while attending only relevant meetings and staying productive.

In conclusion, focus is an habit that needs to be built and exercised, it does not come naturally. I hope after reading this article, you can start to exercise some of the points outlined above for yourself and gain more productive hours in your workplace.

A Productive Engineer - January 10, 2020 - Oshomo Oforomeh