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.
One comment