Why should one want to have a working day organized? Why isn't it satisfying "to simply do what's necessary"? Sometimes it's possible, usually when there are quite a few tasks, and you don't need to communicate with someone else. Most of the time, there is an overwhelming amount of what you need to do, and you'd better know how to balance this. An organized working day helps you do this. Also, some health-related things do not look important today. But many years later, you'll be grateful for the past yourself for taking them into account.
This article describes the employee's standpoint, but it applies to an entrepreneur, student or anyone wishing for a productive working day.
Organizing a working day has worried me since the first day of my programming career. I wanted to be a productive engineer who shows impressive performance and steadily climbs on a career ladder. Things didn't turn out the way I expected: I could program at a good pace, but there were not many tasks. My productivity didn't look good to the one deciding about my raise. This fact doesn't diminish the benefits of a thoroughly organized working. It warns you that you must also search for a place where your efforts will bear fruits.
Starting From the Very Basics
Let's look at the most primitive view of a day organization. Now we work 8 hours per day. Our thanks to the labor movements of the past!
─┬─────────────────────────────────────────┬─
9:00 AM 5:00 PM
│ WO-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-O-RK │
─┴─────────────────────────────────────────┴─
Let's decipher the scheme. Here we can see 8 hours of uninterrupted work. The image depicts you sitting in front of your computer at 9:00 AM, opening your code editor, never leaving your desk, closing the editor at 5:00 PM and going home. Does it look like a long-term working solution? I won't say so. Let's at least add lunch.
─┬───────────────────────────────────────────────┬─
9:00 AM 6:00 PM
│ WO-O-O-O-O-O-O-O-RK LUNCH WO-O-O-O-O-O-O-O-RK │
─┴───────────────────────────────────────────────┴─
Now we have 4 hours of uninterrupted programming, 1 hour of lunch, and 4 hours of continuous programming. What a strange thing, this programming without interruption. Why do we want it? Do we want it?
The Fallacy of the Need To Work All the Time
I think asking to work for all the paid minutes looks quite natural from the employer's standpoint. The idea is simple: "I pay you for 8 hours, please, work all the time so that I don't pay for your leisure time". In the industrial world, the approach name is "resource utilization maximization".
Primitive employer's logic wants employees to work all the available time without interruptions because "more work will lead to more results which would be cheaper eventually and bring more money". People familiar with the Theory of Constraints or aware of the systems thinking know that the desire to do so is a fallacy. The idea is that usually, a single machine doesn't do the end-to-end production from getting the user request to satisfying it. Building the details for a hundred cars to minimize costs isn't very logical for achieving the goal when the whole factory's order is to produce ten cars.
We could apply the same logic to intellectual workers. If you are a product owner, coming up with ten experiments doesn't make sense if your team can cope only with three of them. It doesn't make sense for a back-end developer to produce many server upgrades when your front-end part can support only a few. Insisting on uninterrupted work won't provide any business advantages.
We won't go further with this view as it makes us think of balancing efforts inside the company and moves us away from individuals. Let's come back with the knowledge that usually, there is no business sense in working all the time.
As a Human, I Need To Think of My Long-Term Needs
Let us also consider the following: as a human, you have your interests, which usually conflict with a poorly settled working environment. The good part is that humane working environments do not have this conflict with personal goals.
You might think you should work long hours to satisfy the company's goals. The unpleasant thing is that your efforts, with a significant probability, would be wasteful due to the ineffectiveness of our companies nowadays. You'll also harm your health, family relationships, existing or potential, and professional growth. Maybe you'll gain a career advantage, but this is also not that probable.
Let's first cover the physical aspects. Sitting for a long time brings you closer to death. Quoting "The Healthy Programmer" book:
A study from Australia found that each hour of daily television-viewing is associated with an eleven percent increase in mortality risk from all causes, regardless of age, sex, waist circumference, and physical-activity level.
Consider this when doing the programming marathons for your new startup. You'll succeed with a 20% probability, and with 80%, you'll fail (Buongiorno, signore Pareto!). In any case, you'll harm your health. The solution to this significant risk is straightforward: every 1 hour, stand up and have a 5-minute walkaround.
─┬─────────────────────────────────────┬───────┬─
0:00 0:55 1:00
│ WORK │ BREAK │
─┴─────────────────────────────────────────────┴─
Here is how our working day transforms when we switch from WORK to WORK & BREAK (W&B on the scheme).
─┬───────────────────────────────────────┬─
9:00 AM 6:00 PM
│ W&B W&B W&B W&B LUNCH W&B W&B W&B W&B │
─┴───────────────────────────────────────┴─
Adding More Italian Complexity
We can go even further here. You might have heard of the Pomodoro technique by Francesco Cirillo, which proposes breaking your activities into 25-minute intervals (pomodoro) with 5 minutes breaks. During these breaks, you can do some useful activities which could mitigate the following risks in your life:
- Back issues,
- Wrists issues,
- Eyes problems,
- Dehydration.
I use the exercises and recommendations for "The Healthy Programmer" book. I won't provide descriptions of back and wrists exercises, but I will add some information about my eyes' care and water consumption practices.
After each pomodoro, I have a notification reminding me to concentrate on something distant for 30 seconds. E.g., a building in front of my house. This practice is my interpretation of the 20-20-20 rule:
Every 20 minutes, focus on something 20 feet (6 meters) away for 20 seconds.
I've adjusted it to fit the Pomodoro usage.
During this 5 minutes break, it's also a good idea to sometimes have a glass of water. First, you'll need to walk to get it. Second, it'll make you wake up soon, whether you want it or not.😄
Here is a quote from "The Healthy Programmer":
That's why the NIH (National Institute of Health) recommends the 8x8 rule: eight 8-ounce glasses of water each day. 12 After a full day of work no one can ever remember if they're drinking the seventh or eighth cup of water. Break it down however you'd like, but try to get 64 ounces each day.
If you like programmer's classics, here is a quote from "Extreme Programming Explained" on the very same topic:
Pair programming is tiring but satisfying. Most programmers can't pair for more than five or six hours in a day. After a week like that, they are ready for a relaxing weekend away from work. I keep a bottle of water beside me while I pair. It's good for my health and I'm eventually reminded to take a break. The breaks keep me fresh for the whole day.
Let's stop mentioning different books for a while and examine my practice. I'm not fond of water that much, but I like tea. Furthermore, I'm not a fan of bagged tea. On top of that, I enjoy a feeling of little everyday discovery. If you are like me here, consider a so-called gunfu teapot. It's great for making a cup of fresh tea just in time:
Unfortunately, I haven't found a relevant article to provide a link to, so please at least see these images. You can imagine the mechanics of tea brewing. When brewed, which usually takes 10-15 seconds, the tea goes down, leaving the brew so it no longer loses its taste. After some time, you can return with a new portion of hot water to make tea once again.
I haven't discovered a health-related reason to do the break every 25 minutes instead of 55. Any approach provides a pleasing effect you might haven't yet thought of: time zoning. We'll discuss this exciting effect later. For now, I want to add that 25-minute periods provide you more flexibility than 55-minute periods.
My congratulations! At this point, we have a working day that takes care of our health.
Creating a Schedule With Pomodoros
You might also have heard of the 15-minute interval after four pomodoros' streak. I don't use it. It conflicts with my pomodoro schedule. This rarely known approach is from the "The Pomodoro Technique" book. You can find it in the chapter dedicated to the timetable. The idea is to predefine the pomodoros (P#N on the image) and not do it on the go. Here's how my timetable looks:
─┬───────────────────────────────────────────────────────────────────────────────────────┬─
9:00 AM 6:00 PM
│ P#1 P#2 P#3 P#4 P#5 LUNCH(1H) P#6 P#7 P#8 P#9 P#10 COFFEE(½H) P#11 P#12 P#13 P#14 P#15 │
─┴───────────────────────────────────────────────────────────────────────────────────────┴─
I'll transpose the scheme, so it would be easier to perceive. Please remember that every P#N includes a 5-minute break after 25-minute work.
─┬──────9:00 AM──────┬─
│ │
│ P#1 │
├───────────────────┤
│ P#2 │
├───────────────────┤
│ P#3 │
├───────────────────┤
│ P#4 │
├───────────────────┤
│ P#5 │
├───────────────────┤
│ LUNCH │
├───────────────────┤
│ LUNCH │
├───────────────────┤
│ P#6 │
├───────────────────┤
│ P#7 │
├───────────────────┤
│ P#8 │
├───────────────────┤
│ P#9 │
├───────────────────┤
│ P#10 │
├───────────────────┤
│ BREAK │
├───────────────────┤
│ P#11 │
├───────────────────┤
│ P#12 │
├───────────────────┤
│ P#13 │
├───────────────────┤
│ P#14 │
├───────────────────┤
│ P#15 │
│ │
─┴──────6:00 PM──────┴─
At this very moment, you might think that the picture is clear. You need to replace all P#N with CODE, and the happiness is here. Yes, this sounds pleasurable, but it is far from reality. First, we'll map our meetings and routine activities to the schedule. I work as a team leader and a software development process architect, and here's how the daily schedule looks for me:
─┬──────9:00 AM──────┬─
│ │
│ DAY PLANNING │
├───────────────────┤
│ NOTES REVIEW │
├───────────────────┤
│ P#3 │
├───────────────────┤
│ P#4 │
├───────────────────┤
│ EPICS REVIEW │
├───────────────────┤
│ LUNCH │
├───────────────────┤
│ LUNCH │
├───────────────────┤
│ TEAM STANDUP │
├───────────────────┤
│ P#7 │
├───────────────────┤
│ P#8 │
├───────────────────┤
│ PROJECT STANDUP │
├───────────────────┤
│ P#10 │
├───────────────────┤
│ BREAK │
├───────────────────┤
│ P#11 │
├───────────────────┤
│ P#12 │
├───────────────────┤
│ P#13 │
├───────────────────┤
│ P#14 │
├───────────────────┤
│ P#15 │
│ │
─┴──────6:00 PM──────┴─
There are some omissions, but you can understand the idea: something happens every day, and I shouldn't consider the time dedicated to these activities as free. You might feel worried that only 25 minutes × 10 pomodoros = 250 minutes = 4 hours and 10 minutes of "real" work left for me. Don't worry too much: according to the research, we are productive only for 3 hours per day.
After routines mapping, we know how much spare time we can use on our major activities. Let's fill all the blocks left with lovely coding activities. If you don't code but do other knowledge activities, think of them here instead of coding.
─┬──────9:00 AM──────┬─
│ │
│ DAY PLANNING │
├───────────────────┤
│ NOTES REVIEW │
├───────────────────┤
│ CODING │
├───────────────────┤
│ CODING │
├───────────────────┤
│ EPICS REVIEW │
├───────────────────┤
│ LUNCH │
├───────────────────┤
│ LUNCH │
├───────────────────┤
│ TEAM STANDUP │
├───────────────────┤
│ CODING │
├───────────────────┤
│ CODING │
├───────────────────┤
│ PROJECT STANDUP │
├───────────────────┤
│ CODING │
├───────────────────┤
│ BREAK │
├───────────────────┤
│ CODING │
├───────────────────┤
│ CODING │
├───────────────────┤
│ CODING │
├───────────────────┤
│ CODING │
├───────────────────┤
│ CODING │
│ │
─┴──────6:00 PM──────┴─
I hope you work on meaningful and manageable chunks of work. Otherwise, you can discover yourself in an infinite loop of never-ending actions. Maybe you'll enjoy it for a while, but you'll probably want some results. We need a sense of completion.
─┬──────9:00 AM──────┬─
│ │
│ DAY PLANNING │
├───────────────────┤
│ NOTES REVIEW │
├───────────────────┤
│ TASK#X │
├───────────────────┤
│ TASK#X │
├───────────────────┤
│ EPICS REVIEW │
├───────────────────┤
│ LUNCH │
├───────────────────┤
│ LUNCH │
├───────────────────┤
│ TEAM STANDUP │
├───────────────────┤
│ TASK#X │
├───────────────────┤
│ TASK#X │
├───────────────────┤
│ PROJECT STANDUP │
├───────────────────┤
│ TASK#Y │
├───────────────────┤
│ BREAK │
├───────────────────┤
│ TASK#Y │
├───────────────────┤
│ TASK#Y │
├───────────────────┤
│ TASK#Y │
├───────────────────┤
│ TASK#Y │
├───────────────────┤
│ TASK#Y │
│ │
─┴──────6:00 PM──────┴─
What's wrong with this schedule? It's fragile as you haven't left any spare time for unplanned work, and it will appear. I suggest leaving a few pomodoros empty. Who knows what the new day will bring us? We need to add robustness to our daily schedule so it won't fail from the tiniest unexpected request. Something new can arise at the meeting, so it might be reasonable to leave some time there to handle the unexpected:
─┬──────9:00 AM──────┬─
│ │
│ DAY PLANNING │
├───────────────────┤
│ NOTES REVIEW │
├───────────────────┤
│ TASK#X │
├───────────────────┤
│ TASK#X │
├───────────────────┤
│ EPICS REVIEW │
├───────────────────┤
│ LUNCH │
├───────────────────┤
│ LUNCH │
├───────────────────┤
│ TEAM STANDUP │
├───────────────────┤
│ P#7 │
├───────────────────┤
│ TASK#X │
├───────────────────┤
│ PROJECT STANDUP │
├───────────────────┤
│ P#10 │
├───────────────────┤
│ BREAK │
├───────────────────┤
│ TASK#Y │
├───────────────────┤
│ TASK#Y │
├───────────────────┤
│ TASK#Y │
├───────────────────┤
│ TASK#Y │
├───────────────────┤
│ P#15 │
│ │
─┴──────6:00 PM──────┴─
If nothing unusual happens, continue working on the TASK#X and TASK#Y. Please have one more look at the empty slots after the meetings. Meetings are the source of new information which can change our plans. I treat the open slots after them as the braking path.
Handling the Nature of the Tasks
I don't remember if I've ever written about this in my previous articles, but I think of the "when it will be done" question asked by a manager as one of the most awkward questions. We are in a problem-solving business here, and any non-trivial task requires an unknown amount of work. So, the most honest response to the question is: "I don't know". But who can know with a significant amount of certainty? It's the manager himself, and this is the topic of one of the following articles.😉
What can you do to set goals and achieve them adequately? You can set the criteria of when the goal is treated as achieved and put your effort into achieving these criteria. I've described the approach in one of my previous articles, "The Immense Power of Vaguely Stated Goals". One piece of effort, in our case, could be a pomodoro.
If you've watched the "Shrek 2" movie, you might remember the moment when Shrek, Fiona and Donkey ride in a carriage. Donkey constantly asks a question: "Are we there yet?" The moment is funny because it's usually evident if we've already arrived at a place or not. On the other hand, it's not always apparent if some work is complete or not. You need to define this state of completion and then go step by step, or pomodoro by pomodoro, constantly asking: "Are we there yet?" When the answer is "yes", have my congratulations. Conversely, at some point, you might start thinking that a goal takes too much effort, and it's unclear how much of it is still required. Then you could negotiate the completion criteria or abandon your efforts.
So the point is that now you have an instrument to measure the effort — pomodoros. You can balance their amount to achieve the desired. Here is an example of a possible goal-achieving pattern:
Day 1 Day 2
─┬──────9:00 AM──────┬──┬──────9:00 AM──────┬─
│ │ │ │
│ DAY PLANNING │ │ DAY PLANNING │
├───────────────────┤ ├───────────────────┤
│ NOTES REVIEW │ │ NOTES REVIEW │
├───────────────────┴──┴───────────────────┤
│ TASK#A TASK#A COMPLETE │
│ ╒══╤═══════════════════╡
│ TASK#A │ │ P#4 │
╞═══════════════════╡ ├───────────────────┤
│ EPICS REVIEW │ │ EPICS REVIEW │
├───────────────────┤ ├───────────────────┤
│ LUNCH │ │ LUNCH │
├───────────────────┤ ├───────────────────┤
│ LUNCH │ │ LUNCH │
├───────────────────┤ ├───────────────────┤
│ TEAM STANDUP │ │ TEAM STANDUP │
├───────────────────┤ ├───────────────────┤
│ TASK#B │ │ HANDLE URGENT │
├───────────────────┤ ├───────────────────┤
│ TASK#B │ │ TASK#C COMPLETE │
├───────────────────┤ ├───────────────────┤
│ PROJECT STANDUP │ │ PROJECT STANDUP │
├───────────────────┤ ├───────────────────┤
│ HANDLE URGENT │ │ TASK#D │
├───────────────────┤ ├───────────────────┤
│ BREAK │ │ BREAK │
├───────────────────┤ ├───────────────────┤
│ TASK#B │ │ TASK#D │
├───────────────────┤ ├───────────────────┤
│ TASK#B │ │ TASK#D │
├───────────────────┤ ├───────────────────┤
│ TASK#B COMPLETE │ │ TASK#D │
├───────────────────┤ ├───────────────────┤
│ TASK#C │ │ TASK#D COMPLETE │
├───────────────────┤ ├───────────────────┤
│ TASK#C │ │ P#16 │
│ │ │ │
─┴──────6:00 PM──────┴──┴──────6:00 PM──────┴─
Treat this scheme not as a plan but as documentation of what happened. You can see in the scheme above the whole effort is split into two days. TASK#A is important but not urgent. To reflect the attitude, we dedicate two pomodoros to it daily, and it turns out that three in total are just fine. On the other hand, we have several important and urgent tasks we want as early as possible. We approach them (TASK#B, TASK#C, TASK#D) sequentially in the second part of the working day.
Let's review what we have achieved to this moment with all the improvements:
- We mitigate the health risks by doing breaks every 25 minutes and even taking some exercise;
- We drink enough water to support health once again;
- We handle routine tasks effectively;
- We can handle long-lasting tasks effectively;
- We handle urgent tasks effectively.
Investing in the Future
Is there anything else we desire? Yes, we might want to not only support what we have but also support our prosperity in future. We might want to become better by learning. What a strange proposal, you might think. Should I learn during the working day? Shouldn't I work at work and learn at school or university? Well, 50 years ago or so, this could be a suitable approach, but today — no. Okay, but won't this conflict with the interest of my employer? You know, in a primitive situation, it could. However, I write this article not only for employees but also for employers, so let's look at this from the other point of view. Entrepreneurs, are you satisfied with the absence of improvements? If not, you should not only allow but also wish your workers to learn. How would they come up with better solutions without making continuous discoveries? Would it be better to get knowledge only from the most relevant sources? I don’t support this as we can learn from the methods of others to enhance our own. Who is tremendously experienced in debugging? E.g., virologists: the discovery of lentiviruses took years of "debugging". Why so long? Because it takes years to "run a single test".
We don't have to go wide or deep in learning and never return. We can combine these strategies according to our needs. E.g., we could do some essential required education and some frivolous ones. E.g. now, I actively introduce checklists into the development workflow, and the book that advocates for them is "The Checklist Manifesto". Its author is a surgeon Atul Gawande. Hardly there is a chance to meet it in a regular Java developer learning path.
Let's have a look at the working day enhanced with learning:
─┬──────9:00 AM──────┬─
│ │
│ DAY PLANNING │
├───────────────────┤
│ NOTES REVIEW │
├───────────────────┤
│ TASK#X │
├───────────────────┤
│ TASK#X │
├───────────────────┤
│ EPICS REVIEW │
├───────────────────┤
│ LUNCH │
├───────────────────┤
│ LUNCH │
├───────────────────┤
│ TEAM STANDUP │
├───────────────────┤
│ P#7 │
├───────────────────┤
│ TASK#X │
├───────────────────┤
│ PROJECT STANDUP │
├───────────────────┤
│ P#10 │
├───────────────────┤
│ BREAK │
├───────────────────┤
│ LEARNING │
├───────────────────┤
│ TASK#Y │
├───────────────────┤
│ TASK#Y │
├───────────────────┤
│ TASK#Y │
├───────────────────┤
│ P#15 │
│ │
─┴──────6:00 PM──────┴─
You can see that LEARNING stands after the BREAK. It's not accidental, and I have some additional thoughts about this recommendation. When arriving from the lunch or coffee break, you are already interrupted. It's easier not to step into the flow than to step out. I was there many times: you have a dedicated time to learn before lunch, but "this almost completed task" makes you miss your learning once again.
Follow Your Needs
Time to stop adding extra activities. Now you can see that the approach helps introduce flexible enhancements. Remember that you are in a lifelong marathon but not in the two-week-long sprint. I recommend you treat the working day not as a borderless mass of coding activity but as a much more structured way aimed at helping you reach long-term positive results. Here I include health for your stomach, back, hands, eyes, and everything else. The next thing that can help you cope with different tasks is breaking your day into blocks of time. In my case, I use the Pomodoro technique to do so. The last thing mentioned is learning. Incorporate it into your daily activities, make it easy for you to start doing it — eliminate the learning obstacles. As William Edwards Deming once said:
Learning is not compulsory… neither is survival.