# Un día de viaje

## Cabalgando hasta el amanecer

Como programadores siempre estamos tratando de encontrar nuevas formas de ser productivos. Hacemos ajustes en los editores de texto, ajustes en la compilación, creamos _scripts_ y automatizamos tareas, la lista se extiende dependiendo de cómo los programadores quieran maximizar la productividad del tiempo que emplean en crear código. También pasamos tiempo haciendo ajustes al resto de nuestras vidas con la creencia que deberíamos siempre estar haciendo algo relacionado con el código. Cualquier momento que no estamos creando código es un momento en el que nuestros proyectos se retrasan. Y retrasarse con nuestro código puede desencadenar en otros problemas: plazos imcumplidos, que otras empresas lleven publiquen su programa en el mercado antes que nosotros, u otros casos que perdemos una oportunidad. Estamos constantemente preocupados por no estar haciendo lo suficiente para tener éxito.

Hemos escuchado historias de desarrolladores que se han despertado frente a sus equipos por un estraño pitido provocado porque se han quedado dormidos encima del teclado y la repetición automática de caracteres ya no podían gestionar más texto por que sus caras estaban apoyadas en las teclas. ¿No es así como deberían trabajar los desarrolladores?

Hay una tendencia a creer que como trabajamos con máquinas que no descansan y siempre están preparadas para trabajar más, necesitamos adaptarnos nosotros mismos a esas máquinas. Sentimos la necesidad de estar siempre en marcha y preparados para dar a la máquina más trabajo. La ociosidad se considera una pérdida de tiempo. Tratamos de llegar a ser como la máquina: sin descanso y siempre preparados para más trabajo.

Hay un problema con ese sentimiento de tener que estar siempre en marcha. Cuando sentimos que siempre tenemos que estar en marcha, no nos permitimos a nosotros mismos tener un momento de descanso. No nos permitimos periodos de ocio y descanso. Esto crea un patrón donde nos denegamos los momentos para sentarnos y centrarnos en lo que estamos haciendo. Nos forzamos a seguir en movimiento, a seguir programando sin importal el coste personal. Nuestros cerebros no tienen la habilidad de descansar, relajarse y cargarse de energía. Nuestras mentes están ocupadas y exahustas para procesar lo que aprendimos y guardar ese conocimiento a largo plazo. Cuando estamos exahustos empezamos a preocuparnos de que no estamos haciendo todo lo necesario. Esto no nos motiva, en vez de eso crea un círculo vicioso de miedo y pánico. Pasamos nuestro día precupados sobre que no estamos haciendo lo necesario mientras que nuestras mentes gritan un "¡suficiente!" de extenuación. Este cículo vicioso se miedo un extenuación puede llevarnos a un vórtice de agotamiento, depresión y el deseo de dejar la programación para siempre.

Hay un delicado equilibrio que debemos lograr entre nuestros deseos de estar conectados constantemente y nuestras necesidades de relajación y reflexión. Nuestro deseo de un desarrollo invencible e infatigable debe atemperarse con la realidad de que nuestros cuerpos y mentes tienen unos recursos finitos por día que deben asignarse adecuadamente. Piensa en esto como la administración de energía para una máquina compleja en la que el fabricante (actualmente) no te permite cambiar la batería cuando se agota. Ser consciente de qué procesos se están ejecutando, cuánta energía se está utilizando y cuánta energía queda es vital para garantizar que aún pueda funcionar hasta más tarde en el día. Ese es el nivel de conciencia que debemos tener sobre nosotros mismos.

¿Cómo equilibramos esos sentimientos de querer estar conectados todo el tiempo mientras nos permitimos a nosotros mismos el relajarnos y reflexionar en lo que estamos haciendo? ¿Cómo prestamos atención a las necesidades de esta "máquina de programar"?

## Luces fuera

Primero, debemos ser conscientes de que no podemos estar conectados todo el tiempo. Quizá sabes esto de manera intuitiva y pensamos "claro, por supuesto" pero saber esto no es lo mismo que ponerlo en práctica. Necesitamos periodos donde no estemos programando ni pensando en programar. Deberíamos tener momentos donde poder apagar la parte del programador de nuestra personalidad. Estos periodos de no programación son vitales para nuestro propio bien estar y nos ofrecen oportunidades para explorar el ancho mundo y permitir a nuestras mentes descansar en los tiempos entre las sesiones de programción.

Esto puede ser complicado si sentimos que nos estamos retrasando en nuesto aprendizaje. ¿Cuando se supone que vamos a aprender todas esas cosas nuevas que están ocurriendo cada día? ¿Cuándo se supone que nos pondremos al día con toda esa deuda técnica que hemos ido acumulando a lo largo de los años? ¿Cuándo tendremos tiempo de conocer los entresijos de tecnologías que no forman parte de nuestro trabajo diario pero que nos siguen interesando?

Estos sentimientos que tenemos (que hay que hacer más y que necesitamos pasar cada momento en el que estamos despiertos haciendo cosas que no hagan que nos desfasemos) no son muy útiles cuandos nos comparamos con otros programadores que parece que son super productivos. Estos son los programadores que tienen una idea brillante por la mañana y un prototipo ya funcional por la tarde (mientras siguen gestionando normalmente su rutina de trabajo). Cuando nos comparamos a nosotros mismos con estos programadores nos preguntamos si ellos se toman algún momento libre fuera de sus ordenadores.

Podemos reconocer que tenemos sentimientos de querer esforzarnos para seguir aprendiendo y haciendo cosas. Podemos notar nuestros sentimientos cuando pensamos "solo una línea más de código antes de acostarnos" o convencernos a nosotros mismos "puedo leer algunos artículos o páginas más o [inserte la forma favorita de consumir más información aquí]". Podemos hacer una pausa y notar de dónde vienen estos sentimientos y pensamientos y entender por qué todavía nos esforzamos más allá del agotamiento.

Estos sentimientos generalmente provienen de una sensación de insuficiencia. Sentimos que no estamos a la altura de los ideales que tenemos, ya sea porque estos ideales son los que hemos creado o por que han sido creados de manera externa. Estos ideales provienen de analizar a otros programadores (colegas o personas a las que admiramos) y medir nuestro progreso en comparación con su trabajo. También provienen de nuestras propias ideas míticas de lo que hace a un programador perfecto.

De lo que debemos darnos cuenta es que esas ideas de lo que hacen los programadores buenos y perfectos son fantasías. Son una combinación de lo que creemos que debería ser un programador bueno y perfecto. No existen en el mundo real. Es cierto que podemos ver programadores que parecen despertarse con un teclado conectado a sus manos, pasan todo el día creando código y se van a dormir con sueños de formular más código en sus cabezas. Pero debemos darnos cuenta de que solo estamos viendo un lado de sus vidas. No estamos viendo la imagen completa de quiénes son. Necesitamos enfocarnos en nuestros propios cuerpos y mentes y darnos cuenta cuando estamos cansados y necesitamos descansar. No podemos convertirnos en otras personas, tenemos que trabajar con quiénes y qué somos.

Nuestros cuerpos necesitan tiempos de descanso para poder ser más efectivos. Necesitamos momentos donde podamos apartarnos del teclaco y permitirnos a nosotros mismos descansar y relajarnos. Nuestras mentes no están diseñadas para el trabajo constante, especialmente a los niveles que se requiere a un programador.  Cuanto antes nos demos cuenta de que debemos dar un paso atrás y tomar descansos a lo largo del día para recargarnos, más felices (y más productivos) seremos.

## Taking a break

Taking a break is more than just flipping over to another application on our computer. My tendency while taking a break is to start checking my email or open up one of my various chat programs to catch up on what happened since I last opened it (usually since the last time I took a break). This really isn't taking a break as it is trying to multi-task at my desk. Real breaks involve getting up from the computer. It doesn't have to be a large break; taking a break can be as simple as moving away from your work-space into another room or area. You need to move away from your computer to get a "Context Switch", where your mind can feel like it isn't in the same place as it was earlier. Context Switching lets your mind completely switch out and flush out the context of the area you're in. It allows your mind to focus on new context and new input.

This can be tricky in an office where the underlying expectation is that one must be at their work space in order to be productive. And there are only so many "bio breaks" (breaks that are related to matters of human biology, also known as using the restroom) 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.

Changing your sitting / standing arrangement can also be a good Context Switch where you allow yourself a change in your physical workspace. It can be as simple as just standing up and stretching from time to time, or as complex as raising or lowering your standing desk. Telling yourself that there are two contexts around your desk: sitting and standing at the desk, may be enough to give yourself the Context Switch and rest that your mind needs.

If your workplace has a culture that allows you to step away from your desk and move around then that would be a great Context Switch. Adding a physical component (as much as you are able) to your Context Switch can help your mind to relax and recharge.

You'll have to experiment with a few of these to determine 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 have cool-down periods between coding sessions so it can flush the remnants of that session from your mental "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.

You may also find when you go away from the computer for a while that you'll forget what you were previously doing. That's OK. What I would recommend is keeping a journal or log of what you were thinking in as much detail as you need. Either write it on a physical piece of paper or use a text file to keep these notes so you'll have enough clues to allow you to pick up where you left off.

## 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 string of words for a code comment. We have varying levels of energy and mental focus available to us per day. It's up to us to be mindful of 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 put a lot of emphasis in our day on completion and hitting deadlines. This emphasis can cause us to create strong attachments to completion and deadlines. Sometimes this is warranted because of external factors (the "critical-path" of the project require us to get this done by a certain date and time). But many of our deadlines are internal deadlines that we've set for ourselves. We set a goal that we will be this productive by the end of the day. The unstated condition of this internal productivity deadline is that we'll feel guilty and ashamed if we miss the goal. We'll fee like we're not measuring up to our expectations and wonder if we're worthy 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 remove deadlines wherever possible. We won't be able to get rid of the external ones where folks are waiting on our contributions (though it may be possible to renegotiate those if they're not hard deadlines) but we can let go of the desire to meet arbitrary productivity levels and arbitrary deadlines. 

Arbitrary goals may work for some tasks. Some examples of this are game programming contests that only run for a week which makes teams focus on the critical pieces of the design and implementation of their game in order to release it in the allotted time. These can be a fun exercise for focusing your efforts, but they also incur a lot of stress and pressure before the contest's deadline. If you continually feel guilty and unworthy because you can't seem to meet the goals you set for yourself then you should reconsider whether it's useful to use them at all.

One trick that has helped me is creating small spaces of concentrated focus. That trick is described in the next section.

## Containers

We should replace soft deadlines (deadlines that aren't externally imposed on us) with a commitment to work on a particular project for a given length of time. One trick I've found useful is the idea of a "timed focus container". When I do a timed focus container I start by choosing what will be focused on during the container. Once the task is chosen I set a timer at my work-space and then focus on that task with my full attention for the remainder of the time on the timer. I've had the best luck with using 10 minutes but a session as small as 5 minutes or as large as 30 minutes can be useful. The work selected at the beginning of the container is the only thing I work on, and I do my best to make sure there are no interruptions (whether internal or external) until the container is complete. When the work is done I wrap up the task with whatever I've completed, note whatever the next actions are for that task on my next actions list, and then take a quick break (usually around 5 minutes) before starting the next container. The next container can be a continuation of the same task, or I can select another task, but the idea is simple: I only focus on the task in front of me for the allotted time. When my mind tries to wander or I get the temptation to "just check this one thing" I pause for a moment and determine if it is indeed important. Most of the time it isn't important and I can make a quick note to check on it whenever I finish the container.

We can use these containers to overcome our desires to multitask. We only focus on one thing at a time. We can also use containers to just let the session go where it wants to take us. When we start the container we don't start off with trying to finish a particular task; instead 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 no expectation for what work we will accomplish, just that we will work on it until the container is finished. If we complete the task before the container ends then that's awesome! We can then figure out what the task for the next container will be. If the container ends and we're still in the middle of a task we can then write down where we left off and what steps we took in order to get there. We can then work on something else, or we can take a quick break and then come back to the work with a focus container.

The underlying concept of the timed focus container is to let ourselves agree to work within the confines of the container without judgment either for the work done or the progress made. When the work is done we close out the container by reflecting on what we did and where we need to go. We give ourselves permission to not worry about our progress in the moment, but we do allow ourselves moments where we can review our progress and note how far our journey has progressed. We allow ourselves the freedom to just work in the in the moment without fear of judgment, reprisal, or self-recrimination. The container is a gift of uninterrupted work that we give ourselves (or at least as uninterrupted as we can manage). We make this the best gift we can give by closing out other programs, turning off notifications, and giving this task the full attention it deserves.

I invite you to incorporate this practice of doing focused containers every day. I think they are an excellent way to give ourselves permission to focus on one thing at a time without the need or worry for what will get accomplished during that container. It allows us to focus on one thing at a time and do it to the best of our abilities.  The limitation of working on one thing at a time without thinking about the other bits of work that we have to do can be liberating, and I hope that working with these containers will give you a sense of what fully-focused work can feel like.

This whole book was created and edited using focus containers. I took about 10 minutes per container to write the initial draft, and later I used 10 minute containers to edit the book. Sometimes they bled over into 15 or 20 minute containers but that was because I was so engaged with the material that I didn't want to stop. This was in sharp contrast with how I've normally approached tasks. Usually I need to get over the initial hurdle of allocating a half-hour or more to the task. This means that I need to feel like I have enough control over my schedule in order to clear out that space. Since I don't tend to feel like I have that level of control over my schedule I tend to procrastinate on the task. With a focus container I think to myself "I can just take 10 minutes to work on this" which is just enough time for my mind to not feel like it should be doing something else. With each container I gradually saw the progress of this book unfold. That then fed back into my desire to keep working on this book, which helped lower the mental friction to keep doing the containers to work on the book. It created a positive feedback-loop where I looked forward to the next time I could do the container and work on the book.

## Distractions

Life is full of distractions. So many things want our attention, and many of these distractions are outside of our control. Someone enters our work-space and needs our attention at that moment. An email thread that we thought was settled becomes a heated discussion and our attention is drawn to it. Something happens at home and now our minds are split between worrying about our work tasks and worrying about what's happening at home. Whatever the cause may be, there are times when our attention isn't where we want it to be and we feel pulled in every direction at once.

This is when the containers are most helpful. If something interrupts the container we can determine if it's more important than the work we're doing. If we determine that it is more important than what we're currently doing we can stop the container with the understanding that we'll return to the work once we've handled the interruption. If the interruption is not more important then we can agree (both with whomever is interrupting us, or with ourselves) that our focus needs to be here with the work until the container ends. We'll be able to give that disruption our full attention once the container ends. We won't try to split our attention between the work and the interruption, rather we'll give each of them our full attention at the appropriate time.

This method creates a simple delineation between our work and the rest of the world, but just because it's simple doesn't mean it's easy. Keeping the delineation between our work and the outside world can be challenging, especially if the culture you're in is about immediate results.

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

Also be aware of the self-imposed distractions you've added to your life. Do you need immediate notification that someone liked something you shared? Is the funny anecdote you just remembered important enough to warrant switching out of your current context so you can post it to your friends and colleagues? Do you really need something to pop up in your field of view to let you know that your music player changed a track? Are you willing to sacrifice your attention and flow throughout the day because a program detected a change in your environment, regardless of the importance of that change?

We add these distractions into our lives because we worry that we might miss something important. Programs also come configured with most of their notifications turned on so a user can be reminded of the status of the program at all times. Perhaps it's useful, but for me they are very distracting. In my career I've sat at the desks of many other folks and have cringed at the number of notifications they receive in the short I period was there (a span of ten minutes or less). I've seen folks interrupt their current line of thinking because a notification for a message unrelated to the current task distracted them. What happened to the original thought? They had to mentally switch back to it and remember where they left off, usually at great mental effort.

I challenge you to turn off as many notifications as you can and get a taste of what your experience is like without them. That may be as simple as closing out an application when you're done with it, or may be as complex as changing the settings so an application doesn't notify you when new messages arrive. You'll need to play with this and see what works best for your needs and concentration. A good rule of thumb is "what does this thing track that is important enough for me to drop my important work and focus on this thing?." If you can scale your notifications so that only the most time-critical notifications reach you at the appropriate time then you'll be better able to relax and focus into your work. You won't have to parse the notifications to determine if what you're seeing is important or not.

One of the reasons I've heard for folks keeping their notifications on is that they feel they might receive something that requires an immediate response. We've created cultures where we feel a need to respond to messages the moment we receive them. I'd argue that most of the messages you receive during the day don't require the attention you're giving them, and certainly not the level of attention that warrants interrupting what you're doing to view and respond to them. You may be better served by scheduling several periods of the day where you do nothing but check and respond to your messages. Schedule these as infrequently as you can. Some folks recommend two or three times a day, but even setting a limit where you check your messages once an hour can make a vast improvement over how many times you're already checking your messages. You'll need to judge how often you check your messages based on your needs and your work culture. Also consider the person to whom you're responding. Does it make sense to give this person a quick, semi-thought-out response, or does this message require more time to simmer in your mind before you respond? Giving yourself time to think about a your response may give you additional insights into a problem that might not be readily apparent in the moment. This could mean the difference between one well thought out response versus a deluge of half-thought-out back-and-forth brainstorming via your messaging application. Responding to everything as it's received is very stressful and requires huge amounts of attention that could be better used in your programming work. 

It may seem challenging and foreign to live without notifications and without the need to respond to every message and notification, but our attention is finite and limited. Maintaining focus throughout the day is challenging and stressful. If we can limit the number of distractions we receive throughout the day we then give ourselves the freedom to not have to work as hard to keep our attention attuned to our programming tasks. We get to say "not right now" to our distractions and handle them at a more appropriate time.