From f37a5a25088e158a620db84d435ee62f61572d07 Mon Sep 17 00:00:00 2001 From: Craig Maloney Date: Fri, 6 Jul 2018 09:32:53 -0400 Subject: [PATCH] Clarifying the container --- chapter05.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/chapter05.md b/chapter05.md index 283297d..2b78888 100644 --- 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. -- 2.31.1