# A day's journey

## Riding until dawn

Programmers are always trying to find new ways to be productive. Different editors, scripts, compilation tweaks, automation; the list goes on and on for how  programmers want to maximize their time coding. We also tend to add that to the rest of our lives, thinking that we should always be on, coding. Any moment not coding is a moment that our projects get behind. And that can lead to other problems: missed deadlines, others getting to market before us, collisions with others work because they made a breaking change before we could smooth it out. We're constantly worrying that we're not doing enough. We've heard the stories: developers waking up at their computers to the strange sound of beeping because the keyboard auto repeat can't handle anymore input with their face resting on the keys.

There's this tendency that because we work with machines that are tireless and ready for more work that we need to be the same way; we need to constantly utilize these resources. We become like the machine, and the better we get the better we'd better get (because our boss or colleagues will notice that we've completed something and more work will come our way).

The problem is that if we feel we always need to be "on" we don't allow ourselves the opportunity to be "off". We create a pattern where we don't allow ourselves the moments to sit and reflect on what it is we're doing. We don't allow our brains to recharge. We don't allow for our minds to sit with what we've learned and sweep that into our long-term storage.

Instead we create a feeling of constant panic where we spend most of our time worrying that we're not doing enough while at the same time pushing our minds to exhaustion.  It's a vicious feedback loop, and one that can lead to burnout, depression, and a desire to leave programming for good.

So how do we balance these feelings of wanting to be on all the time while allowing ourselves to relax and reflect on what we're doing?

## Lights out

First we need to acknowledge that we can't be on all the time. You may know this intuitively and think "yes, of course" but acknowledging that you need to have a period where you are not programming, not thinking about programming, and not being a programmer is vital to your well-being. You need to have moments where you can turn off the programmer part of your being.

This can be tricky if you constantly feel like you're falling behind in your learning. When are you supposed to learn all of the new things happening daily? When are you supposed to catch up on all of that technical debt you've been accruing over the years? When are you going to have time to learn the ins-and-outs of whatever technology that is no longer part of your day-to-day work but is still interesting to you?

This constant feeling that there's more to do and we need to spend every waking moment doing it or we're somehow less of a developer isn't helped by folks who look super-productive; the folks whom you can suggest something in the morning and they have a working prototype in the afternoon while still figuring out their normal work routine.

We can acknowledge that we have this feeling; that we feel the constant need to somehow push ourselves to keep learning and doing. We can see ourselves in the moment with the thoughts of "just one more line of code before bed" or "I  can read a few more articles or blog posts or [insert favorite way to consume more information here]". We need to see our feelings and understand where they come from.

These feelings usually stem from a sense of inadequacy. We feel like we're not measuring up to whatever ideals we have, whether that's an ideal that is externally driven or one that we made ourselves. This comes from us comparing ourselves to other programmers and seeing their work. It also comes from us comparing ourselves to our own mythical idea of what the perfect programmer is.

What we need to realize is that those ideas of what a perfect programmer is and is doing right now are fantasies. They don't exist in the real world. True, there are programmers out there who seem to wake up with a keyboard in their hands, spend the day coding, and go to sleep only to dream in more code. But those folks are not us, and we need to understand where our bodies and minds can take us and when they need rest.

Our bodies require down-time in order to be most effective. We need to step away from the keyboard and allow ourselves to come down and relax. Our minds are not designed for constant work, especially at the levels that computer programming requires. We need to step back and realize that we need breaks throughout the day in order to recharge ourselves.

## Taking a break

Taking a break is more than just flipping to another application. I know my tendency for taking a break is to start checking email or head to one of the various chat programs I have in order to catch up on what's happened since I last took a break. But this is not really taking a break as it is trying ti multi-task at my desk. Real breaks require getting up from the computer. It doesn't have to be a large break;  taking a break can be as simple as standing up and walking from your workspace into another room or area. But you you need to stand up from your computer from time to time and get a "context switch" (where your mind can feel like it isn't in the same place as it was earlier).  It gives your mind the ability to completely switch out the context of the area you're in and allows it to focus on the new context and new input.

This can be tricky in an office situation where the expectation is that one must be at their desks in order to be productive. And there are only so many "bio-breaks" someone can take in such situations. How can you give yourself the context switch your mind needs in such situations?

You might be able to achieve the same sort of context-switch by looking away from the computer display for a few moments. It's a good idea to look away from the screen every now-and-again to give your eyes a rest. Giving your mind a rest while you give your eyes a rest can give you the incentive to do both.

Standing up can also be a good context switch where you give yourself more of a context-switch from the physical location of the computer. Telling yourself that there's two contexts around your desk: the context of sitting at the desk, and the context of standing at the desk you might be able to use that as the context switch and rest that your mind needs.

If you have a culture in your workplace that allows you to step away from your desk and walk around that would be a great context switch. Adding a physical component (as much as you can) to your context switch can help your mind to relax and recharge.

You'll have to experiment with a few of these and see what works. At the bare minimum you'll want your mind to feel as though it doesn't have to be on all the time. You want your mind to cool down between coding sessions so it can flush it out of "cache" and into longer-term storage. Then when you get back to your coding session you'll be more likely to remember what was going on.

## Productive thinking

Next we need to realize that productivity is not a constant. There are days where we will find ourselves generating remarkable levels of code and code quality and days where we'll be lucky if we can string together a coherent comment string. We have varying levels of energy and mental focus available to us per day. It's up to us to look at these levels and understand what our productivity might look like for the day. 

Understanding these swings of productivity can allow us to better gauge whether or not the day will allow us to generate the code that needs to be generated, but there's a level below that I think is important.

We make attachments on completion and hitting deadlines. Some of these are external: the project dependencies require that we need to get this done by a certain date and time. But many of them are internal deadlines that we've set for ourselves. We set a goal for ourselves that we will be this productive by the end of the day. The unstated condition of this that if we aren't that productive we'll feel guilty and ashamed. We'll fee unworthy of the task at hand. We'll feel like our day has been wasted and wonder if we're capable of doing anything at all.

It's better for us to get rid of deadlines wherever possible. We won't be able to get rid of the external ones where folks are waiting on our contributions (though we may want to renegotiate those if they're not hard deadlines) but we can let go of the desires to release this project on an arbitrary deadline.

## Containers

We should replace soft deadlines with the commitment to work on a particular project for a given length of time. One trick that I have found useful is the idea of a timed container where one chooses what they are working on and then focuses on that project with their full attention for the period of time. I've used 10 minutes but something as small as 5 minutes or as large as 25 minutes can be useful. The work we selected at the beginning of the container is the only thing we work on, and we do our best to make sure there are no interruptions, whether internal or external, until the container is complete. When the work is done we wrap up wherever we landed and then take a quick break before starting the next container (with the same or some other task before us).

When we start the container we see where the session takes us. There is no judgment of the quality of the work in the container, just the expectation that we will work  for the duration of the container. There's also no expectation about what we will have accomplished when the container is finished. If we complete the task before the container ends then that's awesome! We can then figure out what out next task will be.  If the container ends and we're still in the middle of debugging a problem perhaps we write down where we left off and what steps we took in order to get there and then work on something else. Or we get up for a bit and come back to the session in progress.

The underlying concept for the container is just to agree to work in the container without judgment for the work done and for the progress made. When the work is done in the container we take a step back and reflect on what we did and where we need to go. We give ourselves permission to not have to worry about it in the moment, but also allow ourselves the freedom to look back in short increments and see how we're doing. We allow ourselves to just work in the moment without fear of judgment, reprisal, or self-recrimination. We give ourselves the gift of uninterrupted work (or at least as much as we can possibly give). And we give it our full attention by turning off notifications, closing other programs, and focusing on the work in front of us.

## Distractions

Life is often full of distractions that are beyond our control. Someone walks up to our work-space and needs our attention at that moment. An email thread that we thought was settled becomes a heated discussion and needs our attention. Something happens at home and now our minds are split between work and home. Whatever the cause may be there are times when our attention isn't where we feel it should be and we feel pulled in every direction at once.

This is where the containers can be most helpful. If someone interrupts the container we can determine if it's something that is more important than the work we're doing. If it is more important than what we're currently doing we can stop the container with the understanding that we'll get back to it once we've handled the interruption. If it's not more important then we can agree (both with whomever is interrupting, or ourselves) that our focus needs to be here, with the work, until the container ends. We'll be able to give that other thing our full attention and not try to split our attention between the two.

This may seem like a simple delineation but putting it into practice can be challenging, especially if the culture you're in is about immediate results.

I don't have good answers if your culture demands your attention at all times. The best I can offer is that the containerized approach at least gives you some periods of concentration. But if you feel constantly on-guard because something might happen at any moment you're going to be less effective than if you have the ability to shut the world off for a bit. I'd also challenge you to see if that perception is really true: are you constantly being ambushed by interruptions? Testing that theory may be in order. Keep a sheet of paper (or put it into a text file, spreadsheet or database) with when you did a focus container and if it was interrupted or not. If you find that you are getting interrupted more often than not then you need to reassess what is causing the interruption and if it's something that you can control. There are many ways to handle workplace distractions that I won't go into here but being mindful of the distractions and where they are coming from will be key to figuring out how to mitigate them in the future.