Clarifying the container

diff --git a/chapter05.md b/chapter05.md
index 283297dbaba31e8d0c401e46c1aae44a6c280730..2b78888ecf75a894692ea85951516dc0140ec9ae 100644 (file)
--- a/chapter05.md
+++ b/chapter05.md
@@ -54,8 +54,10 @@ We make attachments on completion and hitting deadlines. Some of these are exter
 
 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.
 
-# FIXME
+## Containers
 
-We should replace soft deadlines with the commitment to work on a particular project for a given length of time. Those periods of time should be uninterrupted containers of time where we can dedicate our full attention to the project. And the containers should be self-contained.
+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).
 
-We start the container and see where the session takes us. We don't allow ourselves to get caught up in results-based focus; instead we allow ourselves to be curious and let the coding take us where it wants to go. If the container ends and we're still debugging a problem perhaps we write down where we left off and what steps we took in order to get there. Or we get up for a bit and come back to the session in progress.  
+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.