Addiing a bit on containers. Needs some help
authorCraig Maloney <craig@decafbad.net>
Thu, 5 Jul 2018 11:52:46 +0000 (07:52 -0400)
committerCraig Maloney <craig@decafbad.net>
Thu, 5 Jul 2018 11:52:46 +0000 (07:52 -0400)
chapter05.md

index 1dd5532b13e5134ffe37496b4245bdb63ec650ff..283297dbaba31e8d0c401e46c1aae44a6c280730 100644 (file)
@@ -47,3 +47,15 @@ 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.
+
+# FIXME
+
+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 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.