Take Time to Breathe - A Few Minutes to Better Code

In a previous blog post, I talked about taking time to unplug in order to avoid burnout. That’s not what this is about. This is about getting in the zone. It’s about those times when you are so deep into the code that you just keep going and going. This is about those times when you get an idea and you dive headlong in and don’t come up for air for hours. Stop it. Stop it right now. Take a step back. Take a moment to breathe.

Don’t mistake me. There’s nothing wrong with getting into the zone or running long code sessions. These can be very productive and you can get a lot done with an uninterrupted code plunge. But before you start that dive, take a few minutes to plan. Ask yourself a few questions:

What do I want to accomplish with my code in this dive?

The first thing you want to establish is what your goal is. What are you trying to accomplish? What do you envision the end result to be? I’m not talking about the completed project. Be it 30 minutes, or 3 hours, when you reach the point that you step away from your desk, what will you have added to your project?

Go in with a plan. Are you: adding a form, coding a class, refactoring a block of code. Establish what the end result will be before you code a single line. Avoid wandering down any unrelated paths while you work. It’s far too easy to get distracted from what your original goal is.

It’s fine to get ideas for other things while you work. That’s where most of my inspiration comes from. When that happens, take a 30 second pause to record your idea in your work items or to-do list and then go back to your goal. Keep focused on the goal.

What is my time limit?

Establish your time limit before you start. Keep it reasonable. I find 1-2 hours works well for me. If my goal isn’t something I can complete in that time, it’s too big. Rethink the goal into something smaller.

A lot of people make use of the pomodoro technique where you work for 25 minutes, break for a minute or two to stretch, move, walk around. They do this 4 times before taking take a longer break. For me, 25 minutes has proven to be too short a time as even with a minute or two I tend to get distracted by something else. Other devs work well with it.

There are a couple of reasons to keep it reasonably short. First, code often takes time to sink in to your thoughts. Far too often I find myself get an idea and just dive into the code. When I emerge hours later and take some to evaluate what I wrote, I realize if I have gone well down the wrong path. Shorter dives gives you a chance to sit back and evaluate where you’re headed and make course corrections with less pain if need be.

Another reason to keep it reasonably short is that it helps to keep your brain fresh. The longer you spend pounding on the keyboard, the more fuzzy your brain gets and the less effective you are. Taking those breaks every couple of hours to relax your mind (and your fingers) and evaluate where things are at.

The method to keep yourself on time can be whatever you wish, but it should be something external. Use a kitchen timer, tell Cortana/Siri/Alexa/Google to set an alarm on your phone or smart speaker or tell your kids to come tackle you in two hours (note: if you use your phone, be sure to place it well out of reach after you set the alarm).

Whatever works for you. Just don’t rely on your eyes looking at a clock or some pop-up on your coding device. Those are too easy to ignore and keep going. It needs to be something external. It needs to be something annoying.

How will you avoid distractions?

You need to avoid distractions for your established time period. The problem is that the modern-day world (and your dev environment) are full of potential distractions. There are several tips I suggest for doing this.

Keep your personal phone out of reach

This is by far the hardest for most of us. We feel this constant, strong urge to just “check in”. And then we find we’ve spent 30 minutes on Twitter or Facebook or sending texts to people we never want to speak to in person. Find a place out of reach of your chair and put your phone there. For me, there is a window ledge in my room just a bit out of reach that I sometimes use. Putting it in a drawer or your bag works just as well if you can resist the temptation to retrieve it.

Shut off your office phone

If you have an office phone, turn if off. Some have do not disturb modes, but for the majority of them you’ll just have to turn off the ringer and hide it so you can’t tell it’s ringing. That may be turning it around or covering it up or sticking it in a drawer. Whatever you need to do so that it’s out of sight. If nothing else, maybe just unplug the thing for a while.

Block off your calendar

Block off your digital calendars. We all know we have those coworkers that love to schedule last-minute meetings. Show them (at least digitally) that you’re not available. Some people (we all know who in our orgs) don’t bother checking (or caring) what other peoples’ calendars say and schedule the meeting anyway. Just decline their invites. It’s OK to say no. Well, unless it’s your boss. You know how they are.

Turn off your chat and other distracting apps

Whatever you use–Slack, Teams, HipChat, IRC, Skype, etc–just turn it off. And make sure it’s really off, not just off. Exit the program entirely if you can. If you can’t for whatever reason, at least mark yourself as In a meeting or Away and ignore any chat requests or messages that come in.

Any other apps you have installed that might serve as distractions should also be exited. Even better, they should be uninstalled permanently. It’s the same as with your phone. If you can’t resist the urge to check Twitter every 5 minutes, your work performance will suffer. As devs we often have admin rights on our work machines. Avoid the temptation to install news, sports, social media, games and other apps that aren’t critical to your work. And no, you can’t see what apps I have installed on my work machine! :)

Shut the door

If you have a door, then shut it. If not, put up a “Do Not Disturb” sign with a time that they can come back and talk to you. I worked with someone in the past that would hang a rope across their cubicle entrance with a sign on it. Make it clear to people who you are not to be bothered except in emergency. Make sure they can understand that without having to talk to you. If they have to talk to you in order to know they can’t talk to you right now, it defeats the purpose.

Whatever you do, make sure it is clearly displayed at what time they CAN come back and talk to you. Honor that listed time. If all you do is put up a sign that says “Go Away”, then they’re going to bother you anyway.

Block distracting websites

As developers, we can’t avoid the internet. We need to be able to search for docs, Q&A’s, code samples and so forth. Shutting off the pipe is not an option. But there are ways to help us stay on task. The internet itself abounds with apps and browser plugins to help keep you off of distracting websites and to stay on focus. Some of them are free and some are not. I’ll leave it to your own efforts to find what works for you.

Use headphones

If you don’t have them, invest in a comfortable, high quality set of noise cancelling headphones. With cubicle environments or the recent trend towards “open” offices (which I hate with a passion), distractions are plentiful. People around you are always making noises, whether it’s talking or pounding away on their own keyboards. You don’t need to hear them. You don’t WANT to hear them.

Also invest in a music service that provides whatever music helps you stay focused. This is one type of app I absolutely must have for coding. I use Amazon Music since they have several great channels of music to help you focus at work. Whatever works for you is great. Avoid “spoken word” streams like podcasts, comedy streams, news, etc. While these are great at other times, if you’re trying to focus on the words being said, you’re not focused on your code.

Review your effort

Review and Evaluate

Whenever you reach your time limit, stop. You can go ahead and finish the line of code you’re currently in, but no more. Take a few minutes break, say 4-5. Get up, walk around, get a drink, whatever. Get away from your seat for a couple of minutes. Check your messages (but don’t respond yet), phone(s), etc. Don’t wander off too far.

After your 4 or 5 minutes distraction, sit back down and take 10 minutes to review what you completed. Are you on the right track? After a break and evaluation do you still feel good about what you added, removed or changed? I find that it only takes a few minutes of distraction to get my mind to a place where I can do an honest self-evaluation of the previous dive’s effort.

Once you’ve reviewed the past bit, now is the time to deal with the real world. Go talk to people who need your input, return calls, emails, etc. Get that all caught up and you’re ready to start your next dive.

Last thoughts….

In an ideal dev world, distractions would not be a problem for us. However, we don’t live in that world. There are countless distractions all around us all day long. While they are sometimes good and necessary diversions from our work, there are times when we need to just buckle down and get sh*t done. Hopefully, when those times come, a few of my ideas will help.