You enjoy flow states.
So do I. So does everybody. It’s a great state to be in to be. “The Zone” might be one of the best places you can get into. And you can get into it at a desk.
But it might not lead to the best quality work. At least not all the time. I’m currently reading Robert Martin’s Clean Coder. My general thought was that programmers want to get into flow states as much as possible. I was surprised to see that it might not be the case. From Clean Coder:
Here’s a little hint from someone whose been there and back: Avoid the Zone. This state of consciousness is not really hyper-productive and is certainly not infallible. It’s really just a mild meditative state in which certain rational faculties are diminished in favor of a sense of speed.
I was surprised by this, because programmers (I’m generalizing) hate meetings and love getting focused blocks of time. That’s probably still true, and the difference here is what I pictured as a good use of that focused block of time.
It’s great to hear another perspective. Uncle Bob’s forgotten more about programming than I’ll learn in my lifetime. I’ve programmed on an off through my life, professionally and not. I’ve consistently found programming to be one of the most effective ways to get into flow.
In Deep Work, Cal Newport writes about finding focused blocks of time. As expected, flow comes up:
This, ultimately, is the lesson to come away with from our brief foray into the world of experimental psychology: To build your working life around the experience of flow produced by deep work is a proven path to deep satisfaction.
Flow is satisfying, but it might not be the end-all, be-all if the output is writing good code.
In Clean Coder, Robert Martin points to pair programming as one of the best ways to keep quality high. And it’s almost as anti-flow as you can get. But he isn’t entirely anti-flow. From Clean Coder:
Well, that’s not quite true. There are times when the Zone is exactly where you want to be. When you are practicing. But we’ll talk about that in another chapter.
I haven’t got to that other chapter yet. So I’m interested in getting to that part to see what his take is on flow and practice.
Coming into this, my understanding is that it’s the opposite: practice is when you shouldn’t be in flow. Practice should be hard. You shouldn’t be entering the zone when you’re practicing. You should be failing, getting feedback to know how to fix the error, then trying again. Over and over.
I’m disappointed to find out that, hey, that might feel good but it doesn’t lead to the best results. But it does make more sense as I’m writing this and thinking more about it.
If you’re playing basketball, you can get in flow by playing pick-up games at your YMCA all the time. But you won’t get as good as if you drilled and worked with a coach in a non-flow setting.
Anyway, I’ll continue sharing thoughts about this in a future post—aka I need to actually get to that other chapter first.