I was listening to an episode of Matt Gemmell's eminent podcast Trouble with writing. I think it was the one about writing your first draft, but they are all equally short, informative, and entertaining. Regardless, Matt was talking about not letting other things interrupt your writing flow, research very much included. Make a note of things to look up and move on, retaining focus on getting words written. (He also mentioned common things such as turning off notifications, closing web browsers, and the like.)
Keeping focus and saving research for later made intuitive sense to me. Which got me wondering: Could I try the same thing for writing code? I, like pretty much everyone else, constantly look things up while coding. How do people usually solve something like this, what is this thing called again, where does this fit into a greater whole, and a thousand other thoughts and questions. It is very easy to tell myself that I would just get stuck more often and for longer if I did not work like this, but is it actually true? What if I just made notes, got something written, then looked stuff up and possibly made changes in a separate block of time?
It feels strange, yet somehow appealing. I can easily see how such a split could prevent a lot of time sunk into random rabbit holes, looking for things which were actually of no relevance at all. The resulting first draft of code may not follow all the common patterns, or do things in the standardized way. But why would it have to? It can easily be changed. And besides, if written as more of a piece, it might also just become a bit more of a whole unit, perhaps solving things in a way more fit for its special case rather than in a more general way?
I am still on holiday, and I do not foresee writing any code before I am back at work. But I would like to give this idea some more thought and a trial run or two once I am back in my coding shirt.