Getting into the flow or zone as a coder is when you are your most productive and code spews from your fingers into your favourite text editor as fast as you can type. When in the zone you can seemingly pour out 100’s of lines of code in no time.
But how do you get into the zone other than by pure happenstance?
Authors have a technique called free writing which was popularized in Julia Cameron’s The Artist’s Way for which the rules are simple:
- Select an amount of time: 5, 10, 20 minutes for example
- Write continuosly and quickly for that amount of time ignoring spelling, grammar, formatting
- If you can’t think of things to write, write about that or simply scribble. just keep things going from your brain to the page.
- When your time is up, review what was written and mark anything interesting to explore further in a future free writing session
The goal of free writing is to build up enough momentum to blast through mental blocks and quickly transition to a state of flow for the real writing process. It is meant to be done daily as part of a morning routine before real work starts.
I’m curious if a similar technique could be used to get into the zone for coding. A quick Google search revealed no information about anyone exploring this idea so I thought I would.
Here are the rules I’m using for freecoding:
- Pick an amount of time before hand 5, 10, or 20 minutes for example
- Use a text editor where I can turn off syntax highlighting (to avoid the impulse to go back and fix typos)
- Code in a language that I know well enough to code without referring to documentation
- start coding and don’t stop typing. If you can’t think of something to code just code about that. it doesn’t have to run, it doesn’t have to make sense or be correct syntax. Try not to go back to code out of order.
- Don’t try to accomplish anything that will require you to stop to think. ie. don’t try to implement your favourite sorting algorithm.
- If you code yourself into a spot where you don’t know the API well enough, just fake it out with a call to a magical function that does what you want.
When time is up, turn on syntax highlighting and read what you wrote. Make notes about anything interesting that you’d like to explore again in the future. Note things that you were hung up on with syntax or APIs that you should brush up on.
The purpose of freecoding is to limber up your mind before starting real code. The secondary benefit is to identify gaps in your knowledge of a language or library where you might have to stop to look up the documentation.
Use the momentum built up in the freecoding session to launch into a real project. Try to keep the transition freecoding and real code somewhat smooth
As an example here’s part of what I did in my first 5 minute freecoding session:
a = 'hi there'
b = a.replace('hi', 'bye')
c = fun(a)
if requstA(a) == 'no results':
println("there's nothing in the google machine")
b = b.capitalize()
b = b.reverse()
b = b.capitalize()
not_sure_what_to_type = b
print "hell yeah"
There’s nothing interesting going on here, it’s not complete thoughts and doesn’t accomplish anything nor does it run. the point is to simply start getting a flow of code coming by reducing any blocks that might prevent it (in this case by removing the need to create something that runs or even makes sense).
Upon reviewing this particular session I might decide that the concept of using bing as a backup for google is interesting, and that I need to increase my vocabulary of string functions to call upon.
In my limited trials so far it’s clear that there is a bit of a skill to freecoding successfully. For all other coding you do there is a goal to reach, something specific you want to implement. I suspect that after a couple weeks of regularly freecoding the code will start to get more complex, better structured, and longer thought streams of cohesive code segments.
I am still early on in my experimenting with this concept. However, if it is as effective as free writing is for authors, then perhaps free coding can be a daily ritual more of us can use to boost our productivity. I’d like to encourage every software developer to give it a try and report back (if they like) with how it worked or didn’t work for you.