The Rational Software Engineer: A Guide to Work Time Organization

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.

Why workday structure is important

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.

Working hours

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.

Focused work

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:

• Skip meetings unless you are required there. As a rule of thumb: If you are not sure you need to be at the meeting - you don’t, Skip it. Yes, you will miss one semi-important once in a while, but you will save dozens of hours that are much more than enough to catch up. Also, there is a good way to detect a useless meeting. If there is no agenda and you don’t understand exactly what you are going to discuss, the time is likely to be wasted. So be careful with meetings, help others understand that you value your time and that they shouldn’t invite you to meetings that are not thought through or where you are not required to be at. This rule applies to you as an organizer: create a meeting plan, write a good agenda, invite necessary people, and write down a meeting summary.
  Warning - there are some meetings you don’t want to miss. E.g., if the CEO of your company wants to share something, you might consider attending - even if there is no agenda and nobody knows what’s gonna happen ( ͡° ͜ʖ ͡°)
• Notifications are evil in terms of focus and productivity. Turn off your phone notifications and put your phone away to get rid of the temptation of checking it. Let’s be honest, most of the notifications you get are not important and don’t require your immediate reply. Your friends can wait to answer whether you can join them at the bar, and a new breaking news title is just another clickbait.
• It’s important to create time to focus when you are not interrupted by colleagues either. A quick chat about a new version of Rust nightly and a very important question by a colleague that can be answered by googling for literally 15 seconds is not worth interruption and can wait until your break time. Book some time for your focused work in the calendar, turn on a “busy” status on Slack (or Do-not-Disturb alternative in your messenger), notify your team that you will be open for questions in an hour, or put a note on your head that you are busy. Do whatever it takes, but convey the information to others that you are not interrupted now. Some of the Extreme Programming proponents might disagree with this. Still, I believe that ad-hoc meetings or hanging on a Discord channel all day long for immediate communication are often likely to bring more harm than benefits, as they interrupt you. However, mind that if you don’t respond to people, you can block their work. There are situations when a person cannot progress without your input, and it is fine if you are interrupted in such cases. Also, if your role is the team's lead, team productivity is likely to be more important than your productivity. Being always available can be a valid option in such a case.
• You are most productive when you are fresh. Try to use this time for hard cognitive work. This study shows how our productivity declines with the time we work during the day. Therefore, the first working hours are likely to give the best output, use them wisely.
• Prioritize ruthlessly. Set up the tasks for a day you need to do, and follow the list. It can take just a couple of minutes to make it, but it helps track what you need to do and prioritize. If your activity does not contribute to accomplishing the daily tasks, maybe you are doing something unnecessary.
• Sometimes we feel that we have worked for a whole day, but when we are asked what exactly was accomplished, we don’t have a сlear answer. This can indicate that you were doing something non-essential - and there are opportunities to improve it. During the working day, you can write down what you were actually doing, how long, and why you switched to the other activity. Look at the “activity” report at the end of the day. Ask yourself whether you have been working on the stuff you should have, if there were immediate tasks, what they were and why they appeared, if you didn’t accomplish your task list, what hampered you in achieving it. You will likely find something you can eliminate to improve your productivity.
• If you find it difficult to keep track of your actions, you can install a tracking system on your machine - which would take screenshots every 5/10/20 minutes so that you’ll be able to look at the “report” after work and see your distractions.

Overtime, brrr, no thanks

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.

For example, since I finish at 4 pm, I tend to plan for 5 pm: booking a gym time, getting together with a friend, or booking a table at a restaurant. That ensures that I finish on time most of the days. Obviously, if I have to work overtime to fix the production that I screwed up myself, I can cancel my arrangement, but if it’s just a “very important” meeting on whether we should introduce a new JavaScript library to handle price formatting or write the functionality ourselves at 4:30 pm, then, sorry, but I am on my way to the gym.

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.

Rest for your own sake

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.

Combine different activities

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.

Education

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?

Work from home

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.

• Try to associate some space in our house with work. Dedicate a corner only for work-related activities; then, it can be easier to concentrate on work there and stop working when you leave it at the end of your working schedule. If you can afford it - set a dedicated room to be “the office”.
• Buy good work equipment. Make your workplace comfortable. While I don’t find it very necessary for myself, a lot of people say that a good table, chair and a couple of monitors are must-haves. Many companies have a special budget for setting up your workplace at home, so try it at least. Remember - your spine and eyes are your bread makers, just like fingers are for a pianist. Don’t go cheap on them.
• Try to meet your colleagues from time to time. Working alone can be socially challenging, and it’s easy to forget you’re working in a team. If it’s possible and you feel like that, try to meet your colleagues once every 2 weeks and spend some time together.

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.

Health is crucial for productivity

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.

Recap

Here is a short checklist of all the recommendations that have been mentioned in the article

• Try to aim for about 5 hours of pure coding if it's your main responsibility
• Keep good meeting hygiene, attend only required meetings
• Switch off unnecessary notifications during the work
• Book some time during the day for focused work when you are not interrupted
• Find your most productive working time and try to perform the hardest tasks at the time
• Record what you do during the working day for the future analysis
• Don't work overtime regularly
• Try to utilize "Pomodoro Technique" during focused work
• Use equipment that helps you to work comfortably
• Take care of your health to always have enough energy to be productive

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:

• The Rational Software Engineer: A Guide to Work Time Organization 
• The Rational Software Engineer: There is No Perfect Project
• The Rational Software Engineer: How To Be Passionate About Your Work [Part 1]
• The Rational Software Engineer: How To Be Passionate About Your Work [Part 2]
• The Rational Software Engineer: How To Find a Dream Job

Personal Acknowledgements

Thanks to all my friends who reviewed this article, especially Maksym Bekuzarov, for a thorough check and many useful insights.