How I Get Into Flow

Get primed

Before the work starts, I marinate the brain muscles.

Meditate. Clear the mind so it's open to possibilities
and rid of negative loops.

Coffee; bulletproof, no sugar. Caffeine is self-explanatory.
Caffeine-use sometimes extend across the day with green-tea
or spiked-coffee, depending on my sleep quality the night
before.

Configure environment for immersion

These are one-time workspace setup.

Music playlists with fast-beats, no lyrics, channeled through headphone. Hip-hop instrumentals, EDM and dubstep work for me. Be open to possibilities, I won't be caught alive listening to EDM or dubstep in any other environment. And anything with lyrics is a deal-breaker.

Minimize the use of mouse. I've minimized my computer to the point where there are only two major apps, Spacemacs (emacs) and Firefox. Even web-browser is a necessary evil where thumb-ing the cursor is necessary. Everything else is done with keyboard as much as possible. The point is minimize context-switching and make that a matter of finger gung-fu when I have to switch context.

Quiet workplace, minimize interruptions. This is a huge topic by itself, but having to take care of people is a flow-killer. Paul Graham has got more to say on this.

The principle is to be subtractive, not additive. Find things to cut out to protect your immersion.

Now get immersed

Coding is my thing. Each task is like a game-level, only the boss and level are designed by myself.

Each task/'level' runs through a cycle called red/green/refactor. (TDD-folks are familiar with this).

Red: design the level

Write unit-test first. Cover as large as its appropriate. Most of all make it fail.

Green: beat the level

This is what I get paid for. Write the real code to pass unit test.

When the task is complete, game-level has been beaten.

Beware of the danger of over-thinking and attempt to be elegant here. Steven Pressfield would've call this resistance if he does what I do.

Do not cave to that, it'll simply snap you out of flow. Simply beat the level, be dirty about it.

Refactor: create elegance

The problem is solved, now I can polish my solution. Only now can I be proud of my work and ready for git-push.

Create challenge

Red/green/refactor can only bring you so far if I stay within your comfort zone. Occasional review is needed to detect boredom.

When felt, work on a slightly difficult task where success is within grasp but not guaranteed.

If that's not available, deliberately inject something new into workflow. Learning emacs to do boring work was how I did it. That benefit is still paying off now.

YMMV

Obviously these apply to the domain of coding, where the wanted outcome is clear and deterministic (do this and you get that, everytime).

The same principles work for gaming, extreme sports, martial arts and maybe even mathematics.

Side note about gaming

Ever since understanding the flow-state, I realized I don't need to play games and is free of my repressed game-envy. Essentially coding is my game.

Which leads to me to appreciate the need for healthy dosage of gaming by most people.

Not all software work are equal

That said, software engineering-design work are not usually flow-inducing (though I'm thinking about how to make it so). It goes back having a clear outcome.

Driving principles

• Establish a clear outcome
• Be subtractive; protect your immersion
• Play (just slightly) outside comfort zone

Original post