Flow time, processes and tools
I am big on flow time. Whenever I am placed in a completely new environment I strive to find a way to achieve the maximum possible flow time.
Here’s a great description of this with an eye to human interruptions, which cites De Marco’s Peopleware and also makes the connection to ESR’s Jargon file.
You should not break without good reason the concentration of a
programmer while they are working. If at all possible, communicate via
e-mail or some other way that lets them react when they have the time.
What follows are some justifications as to why this is so
– Cringe from Crossing a Concentrated Coder, by Lars Wirzenius
But note that this doesn’t stop with people, it happens with your choice on technology and tools as well. I think one of the reasons scripting languages have taken off the way they have is that, since they require little or no waiting between changing the file and seeing the results onscreen, they optimize the available flow time even with basic tools (Most of my rails development is currently done with vim and a shell window).
Stop for a few minutes, take a look at your day to day activities and ask yourself when your flow time is typically interrupted by your tools, and whether you can do something to eliminate that interruption. Good tools are designed to reduce or eliminate the flow time interruptions. Bad tools get in the way of that flow time.
Note that if you’re only learning to use your current set of tools now, you may find interruptions that are just a part of the learning process – those you can write off as learning time, since they will go away once you master your toolset. But if your process or tool forces you to stop your flow constantly, find a way to improve it or use different tools. You’ll be glad you did.
A perfect tool or IDE makes the write-build-test cycle feel so seamless that you forget to think about it, maximizing your flow time.
Finally, note that this optimization is only intended for development time. Your deploy process should still be using build script (i.e., no "building from your IDE" to put in qa or production, please!).