05.23.06
Flow and Refactoring
Those being the names of two books I’m reading now. I like it when two things I’m reading, from different fields and for different purposes, turn out to have a nice connection.
It sorta struck me when Fowler mentioned “not once did I have to open the debugger, so the process actually flowed quite quickly”, that, yeah, there does seem to be a connection between flow and refactoring in a general sense.
With any complex project, there are multiple competing concerns. For example, in writing software, I want the functionality, but I also want a clean architecture, good performance, multi-platform capability, etc. With a document, I want clarity, completeness, cleverness, alliteration, etc. But due to limitations of brain-context-capacity, varying interest levels, and compounded complexity, it’s rarely possible to keep all these concerns going simultaneously. And swapping between them all the time can wreaks havoc with the potential for flow.
Given that, one can look at refactoring as a way to profitably resequence work. If I can’t fulfill all the concerns at the same time, I’ll just focus on slapping down something that works, forgetting for the moment all the other stuff. Then, one by one or two by two, I can go back and refactor in the other concerns, as time and interests permit. Beyond simply enabling me to get past the block of “I can’t do it all, so I shouldn’t start at all”, I can also match my work to my capacity and have some chance of getting a flow state going.
yana said,
June 19, 2006 at 3:42 am
Hi Steven,
thank you for the interesting comment on my interview! I replied in the same comment section if you want to read it.
Also the aspects of simultaneousness and coexistence of different contexts – as well as one’s own weaker (perfectionist) self – being counterproductive are indeed important to keep in mind!
This entry is also great: It’s relieving to know flow could happen during pretty much any type of activity, even software development
Thanks for sharing.
Jana