Clarifying the container

[themediocreprogrammer.git] / chapter05.md

diff --git a/chapter05.md b/chapter05.md
index 1dd5532b13e5134ffe37496b4245bdb63ec650ff..2b78888ecf75a894692ea85951516dc0140ec9ae 100644 (file)
--- a/chapter05.md
+++ b/chapter05.md
@@ -47,3 +47,17 @@ You'll have to experiment with a few of these and see what works. At the bare mi
 ## 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.