The Rational Software Engineer: a Guide to Work Time Organization

Who I am and why I wrote this article

I am a software engineer who geeks on learning, using a scientific approach to solve problems, and optimizing my performance. During my work 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 insight into this topic, which may be useful for others as well. 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.

Why workday structure is important

There are a lot of 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 correctly it can improve my productivity greatly, whereas losing control even over one aspect can lead to noticeable degradation in my productivity. So let’s figure out what a “correctly 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 that manage to do it for so long while keeping productivity at a high level. 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 leads us to a question: how much time spent on actually writing code do we expect from a software engineer? Most of my colleagues told me that, 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 with them the following information: 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 afterwards. 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 the following thing: 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 we have a lot of distractions (most of us do) we tend to spend time on non-essential stuff. The 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 say 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 in the next few paragraphs.

• 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 as well: create a meeting plan, write a good agenda, invite only 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 for an 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 to be interrupted now. Some of the Extreme Programming proponents might disagree with this, but 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 other people’s 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 lead of the team, 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 to keep track of what you need to do and what to prioritize. If your activity right now does not contribute to the accomplishment of the daily tasks, maybe you are doing something unnecessary.
• Sometimes we have a feeling 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 be an indicator 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, for 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 to achieve 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 and dissatisfaction at work, and 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 at the same time the shifting contract between microservices was a common point of failure (this process needed improvement too, but it was a harder one to fix). If we encountered a broken pipeline after release, we would first do a revert of the last commit and deploy it once again to minimize the downtime and investigate what was wrong. Waiting for the CI/CD to finish, testing the pipeline, making another revert commit, Waiting for the CI/CD to finish, testing the pipeline again 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 would be deployed. The process was improved, the end of my workday got to be predictable again. And 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 on the lines of “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 make some plans 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 simply 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 a bit bored. I enjoy the days when I can write code for 3-4 hours and spend 3-4 hours on writing articles, mentoring, interviewing, education and educating, 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 either. If there is no common practice in the company to have dedicated time for education, try to discuss and promote this idea with your manager. It’s not as difficult as it sounds =) And If they don’t agree, maybe it’s time to dust off your CV?

Work from home

The Covid pandemic brought us a very interesting implication: a lot of 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 like both the regular and home office and I would prefer to combine them. 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, I enjoy talking to my team in person; and some activities like workshops, interviews, mentoring sessions, and knowledge sharing sessions are done more efficiently in real life. 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, a lot of developers I talk to neglect these staples of productivity and well-being. It’s not a guide about a healthy diet, 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. If you lack some of the basic things, I’m sure you will see a good boost in productivity and work satisfaction once you start working harder on them.

Conclusion

There are a lot of things that play a vital role in how productive with work time structure you can be as a software engineer. I listed down most of the things 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 in DM.

Personal Acknowledgements

Thanks to all my friends who pee-reviewed this article and especially to Maksym Bekuzarov for a thorough check and a lot of useful corrections.