Senior Software Engineer at Mercell Holding AS
I am a software engineer who geeks on learning, using a scientific approach to solve problems, and optimizing my performance. As a software engineer, I often tried to understand how to optimize my productivity - I wanted to get more work done without having to do more work.
And I feel like I’ve gained some insights into this topic, which may be useful for others. In this article, I will share my thoughts about what’s important in a good work time structure while providing media/scientific sources and jokes whenever I can.
This is the first article in "The Rational Software Engineer" series. I will cover more topics related to optimizing personal processes, education, career paths, and how to be passionate in a software engineering context.
There are many things that contribute to how productive I am as a software engineer: how long I work, how focused I am, how often I take breaks and how I spend them - and so many more. If I structure my day well, it can improve my productivity, whereas losing control over one aspect can lead to noticeable degradation in my productivity. So let’s figure out what a “nicely structured workday'' actually is.
Typically, we spend 8 hours per day at work. Some of the time goes to meetings, checking emails, lunch, making coffee, and such. Writing code for 8 hours per day is not very realistic.
I have seen very few individuals who manage to do it for so long while keeping productivity high. On the other hand, anyone who tried to code for 8 hours a day straight (especially without breaks) could tell how exhausting that was. This is the reason why there are ongoing attempts to reduce the working hours in some countries. This one is a promising recent result from reducing working hours to 35-36 hours per week in Iceland.
This leads us to a question - How much time do we expect from a software engineer on writing code?
Most of my colleagues told me, on the best days, when they are not distracted, they can write code for a maximum of 4-6 hours. Some managers (usually the inexperienced ones) could get a panic attack if you told them that their most productive developers write code for only 4 hours per day. “What the hell do they do then?!” - they might ask.
Be considerate with your manager’s mental health and don’t share this information with them: most of the people under their supervision actually do even less than that!
On average, only 39% of the time at work is spent on actual work, and it still doesn’t mean that a person spends this time efficiently.
Personally, I try to aim for 5 hours of focused work per day. If I have a stand-up meeting and a short lunch break at home, my working day can be as short as 5.5 hours. I feel great after such days since my output is good, and I have plenty of leisure time afterward. But remember - it only works with 5 hours of focused work. Otherwise, you can work for more than 10 hours and produce less output anyway.
However, I don’t tend to work for 5.5 hours per day as I try to be engaged with other activities besides writing code and attending the daily stand-up meeting. If I have some additional important calls, read some professional literature, participate in knowledge sharing sessions, and exercise during the lunch break, my working day will typically last around 8 hours.
By “focused work”, I mean: I do the essential stuff, and I work with a lot of concentration.
If we don’t have enough discipline (most of us don’t) and have many distractions (most of us do), we tend to spend time on non-essential stuff. This study suggests that checking news websites, browsing through social media, and chatting with colleagues typically consume 2 hours of an employee's working time. As well as that, 1 in 3 people reports that they spend 2-5 hours per day on meetings where they don’t accomplish anything.
As I aim for maximum productivity, there are ways to decrease context switching with distractions and increase focus time. I will go into detail about them here:
Not only do we produce much less output during working overtime, but it is also connected to health risks, dissatisfaction at work, fatigue, and stress levels. As well as that, if you work for more than 55 hours per week, productivity drops so much that putting in any more hours is almost pointless, according to the study from Stanford University. In other words, working more hours results in diminishing output. Personally, If I work focused for more than 6 hours a day, my mind starts to be blurry, and the harder I push myself to continue working, the more demotivated I feel.
However, we all know that sometimes crunch times happen. Working longer hours to meet the release deadline, fixing a critical bug on production that affects users, having a late and urgent meeting - all of that can happen sometimes, and it can be a valid reason to work longer sporadically. The most important part here is “sporadically”.
If there is always a crunch before every release, most of your production releases cause bugs that you must debug late at night, and you have late meetings 3 days per week, which means that the processes suck. Work on the processes!
For example, once I was on a project where a lot of microservices were connected in a single pipeline in an “Event-Driven Architecture” manner. Once we deployed one microservice, we had to test the whole pipeline end to end as it was the only way to make sure everything works together.
As a few teams worked simultaneously, the shifting contract between microservices was a common point of failure (this process needed improvement, but it was harder to fix). If we encountered a broken pipeline after release, we would first do a revert of the last commit and deploy it again to minimize the downtime and investigate what was wrong. Waiting for the CI/CD to finish, testing the pipeline, making another revert commit, to be sure. All of that took more than an hour and would constantly make me state longer than I wanted at work.
Eventually, I spent 2 days writing the first e2e test that would run before deployment. After that, I never needed to wait and check the pipeline manually after release - I knew that if there was an error, it simply wouldn't be deployed. The process was improved, the end of my workday got to be predictable again. I’ve seen a lot of situations where overtimes could be mitigated by process improvements.
What about “work from home” and “work overtime”? It can be even harder to control that you don’t work overtime. I’ve seen plenty of developers say something like this:
“It feels like I don’t work from home - I live at work. There is no clear separation between home and work anymore”.
One good recommendation that prevents me from getting into a loop of constant overtime work is to make plans right after your working hours.
And there is one small but important point: If I work for 12 hours per day, I simply cannot do other enjoyable activities. And I bet you want to live life besides the job too.
If you aim for 5 hours of focused work per day, it doesn’t mean you should do it all in one sitting. In fact, you should take breaks, and pretty often, as it helps to stay productive longer. A famous Pomodoro Technique can help you to be more productive. Cycles of Work of around 50 minutes followed by a rest for about 15 minutes is a good start.
If you find it hard to concentrate for 50 consecutive minutes, you can try a free app called “Forest: stay focused” or some alternative. “Forest” turns off phone notifications and adds gamification to the process. I used it for a while and then stopped as I noticed I don’t have much problem concentrating for 30-50 minutes on my own. Also, I don’t typically track the time of 1 “cycle” of work and rest and take a small rest whenever I feel like it. This works for me, but maybe it will be easier for you to do it in a more controlled manner.
Try to choose a rest-activity that is different in nature from your main work. Writing code during work time and reading documentation during rest time is exhausting as they are both cognitively hard tasks. However, small exercise, meditation, a walk, some singing or playing musical instruments, and small talk generally help me get back to work with a lot of energy.
It’s not always about writing code. There are a lot more activities that you can do at work, and I find it more productive and entertaining to combine them. Writing code for 5 hours per day can yield good output, but if I work like that for 5 days per week, I can get bored.
I enjoy the days when I can write code for 3-4 hours and spend 3-4 hours writing articles, mentoring, interviewing, education, knowledge sharing, and many other activities. Being involved in different activities also promotes me to feel more satisfied with my work in general. So if you feel bored writing code, try to pick up something new. You can find it entertaining.
New knowledge is important for every profession, but it’s even more crucial for software engineers. Our field is constantly expanding, and if you don’t want to be left on the curb, you should keep up and try to gain new knowledge whenever and wherever you can. Education is worth a dedicated article, but it’s partially connected to work time structure.
Dedicate time for education during a workweek. 3-5 hours per week should be a good start - and feel free to book this time in the calendar as you don’t want to be interrupted during the process. If there is no common practice in the company to have dedicated time for education, try to discuss this idea with your manager. It’s not as difficult as it sounds =) And If they disagree, maybe it’s time to dust off your CV?
The Covid pandemic brought us a very interesting implication: many people started working from home and adapting to new work routines. It was a positive change for some. Others complain. There are a few useful things you should keep an eye on when you work from home.
I would prefer a hybrid work plan - where I can exercise, take shower, cook, rest and avoid distractions at home much easier. Also, I save at least an hour on commuting. On the other hand, I feel a little bit more motivated at the regular office. So try to take the best from each of the worlds if it is possible in your circumstances.
Last but not least, Health. Health is the foundation where everything starts. It’s impossible to be productive if you have a headache, right? If I don’t eat well, stop exercising for a while, have a challenging emotional situation, or have a bad sleep, my productivity plummets.
To be at my peak productivity during the day, I adopted better sleep hygiene, started exercising more, lost an excessive amount of body fat, changed my diet to a much healthier one, started meditating, keeping a diary, and working at a standing desk from time to time. All of that is essential for me to feel well and be most productive.
On the other hand, many developers I talk to neglect these staples of productivity and well-being. It’s not a guide about a healthy lifestyle, but if you feel that you are slack most of the time, you want to fall asleep after 2 hours of work, and you stopped seeing your knees behind your belly, it’s a good moment to get your shit together.
Exercise, keep a good diet, adopt good sleep hygiene and sign up for a visit to a physician, psychotherapist, nutritionist, and personal trainer if you need professional help or don’t know what to start with.
Here is a short checklist of all the recommendations that have been mentioned in the article
I listed down most of the work-life rituals I find useful for myself, but I would also like to hear what contributes to your productivity. So feel free to share in the comments or reach me on LinkedIn.
This article is a part of the "The Rational Software Engineer" series. It covers topics related to optimizing personal processes, education, career development, and being passionate in a software engineering context:
Thanks to all my friends who reviewed this article, especially Maksym Bekuzarov, for a thorough check and many useful insights.
Create your free account to unlock your custom reading experience.