KaranI felt the need to write this post is to expand my reply on Brenda's post of "distractions while taking break". It is also a topic in the the book I am currently writing (more at the end of this post).
This is an interesting problem which almost all engineers struggle with regularly. How to take breaks and make them useful so that you are productive on a daily basis.
There are 2 most common questions that people ask -
- Frequency of breaks - How many times should one take a break?
- Length of the break - How long should they be?
My answers to both is "it depends". There is unfortunately no single effective schedule that someone can follow. The Pomodoro technique fails for most people in the long run because it has too much of a rigid structure. IMHO, it is not flexible enough for coding. But your mileage may vary.
Since coding is a creative endeavour, once you get "into the flow" its best to not take a break until you need to eat/pee/attending a meeting/do something urgent/or something else that forces an interruption. Forcibly breaking a state of flow causes irritation and grumpiness - try to not be in situations that encourage unintentional interruptions.
Being in the flow for long is unsustainable - the flow will end in a natural way at some point - and you should take a break at that point. And in this case, the break can be of any length - from 15 mins to a day or two.
One of the downsides of the flow is that one tends to ignore physical signs. Those are risky, being in touch with your body is crucial - especially while coding since most of the time you are inside your head. As soon as there is a physical feeling of sleepiness, discomfort, pain or exhaustion - you must take a break. No ifs, buts or maybes. Pushing yourself beyond what is physically tolerated by your body is a recipe for disaster in the long run.
What about day to day when you are not in flow all the time? It's the easiest to arrange breaks around your physical needs - when you feel hungry, need to refill your bottle of water, go to toilet etc. Its natural, doesn't feel like an unwanted interruption, and is an easy place to start your break.
But apart from the above two there is one more important question that most people don't think or talk about at all - What should you do while taking a break?
I have seen a lot of people browse their social apps on phone, watch videos, play video games, read books/blog posts on their laptops/phones etc. Its usually something which is on an electronic device. And even though its not work - its unconsciously equally draining.
One doesn't feel refreshed after staring at a screen for 15 mins. Your mind is still buzzing and there is no sense of peace, rest, unwind or calm - its still wound up and noisy. The break ends up not being a break, there is no experience of real downtime.
And this adds up over the days. It leads to a flash point where you just crash (usually on one of the weekend days), lie in bed for a day doing nothing to recover, and then the cycle starts again.
Electronic screens are also the main reason for sleep deprivation - we do not realize how much it affects our sleep - using flux/night shift helps alleviate a little - but it's never enough.
The one thing which I strongly urge practising software engineers to do is get away from their screens - for atleast couple of hours a day. Rest your eyes on something that is further than 10 meters for an extended period of time - you will realize how different it feels - just looking at something that is afar for an extended period of time. Who would have thought of that eh?
For your break, don't carry your phone or laptop and physically move to a different space like a balcony/play area/street/park etc. Let your eyes wander and see things. It doesn't matter what the thing is - could be trees, water, people or anything. And then let your mind wander along with your eye.
You will surprised at how effective this habit is.
PS - I am all about applying such mindfulness techniques as above to workplace in order to become a more productive engineer. I am writing a book (self.debug) about it and I think it will help you as you start your software engineering journey. You can download it here. It has a free option if you want to check it out - but its super encouraging as an author to see readers pay for it.
Photo by Luke Ow on Unsplash, Photo by Adrien Olichon on Unsplash
