I 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
Top comments (12)
After a lifetime of coding, staring at screens, and being in my head, this is all excellent advice, and fits well with my experience. The need to get away from a screen, stare into the distance, and be out of the stream of information is hugely important.
Looking forward to your book. Interesting title.
Hi Kritz,
Thanks! Its already available to download and read. You can get it from here - leanpub.com/selfdebug/
Don't get me wrong, I agree 100% with everything you've written. To follow it up with a link to an ebook though? 🤔 😉
I had that thought as well, but once I considered that the book is optionally free and is related to the topic at hand, it makes sense to me that the author chose to include a link.
Call me weird but there is nothing sweeter than snapping out of the flow right when you reach its highest climax during a coding session. That to me is the best time to take a break, right when you dont want to. I'll then hop out of the chair, walk around, and reflect on what i wrote, how i wrote it, and ways to make it better. I also do this when im stuck. By the time i get back to my desk, all hyped and ready to jump back into my element, i have already mentally precompiled my code and forsaw loopholes in my logic so i have a better idea what to do next. Someone also told me that for every hour you sit, you should stand for 10 min. And for every hour you stand, you should sit for 10 min.
That's very interesting. I utilize the opposite strategy, wherein I take breaks by playing games that very immersive. I find that returning to Flow is much faster than when I go for a walk or read (whether book or social media). For example, 20 to 30 minutes of PUBG Mobile and I'm ready to Flow for another 90 minutes (assuming no other distractions).
And then my 1 hour drive of total solitude breaks me out of the Coding Trance, allowing me to be my best Self for my wife and children.
It's very surprising to me that breaking immersion increases your effectiveness.
Interesting. What are your thoughts on the 20-20-20 rule?
The 20-20-20 rule seems hard to follow practically - especially when you are lost in the code and are thinking about the problem intensely.
The problem I generally see with all these "rules" is that they do not accommodate natural human behaviour or the rhythms of the workplace. So even though they seem simple to follow - it actually requires a lot of effort and hinders the person. They are too rigid.
My main break of the day is at lunch when I go out to the parking lot and play guitar for a little while (weather permitting).
As with everything, the answer is tea. Make a cup of tea, and sit outside if you can.
It brings its own timing with it: You have to wait for the kettle to boil, and the tea to brew. When you've finished drinking, then it's time to get back to work.
GREAT advice! I'm off to read your book. I like how you look at the structured "rules" of productivity and offer up the negatives no one talks about.