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.
-I think 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).
+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.
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.
+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.
projects / themediocreprogrammer.git / commitdiff