## 3 Simple Ways to Get Your Programming Flow Going

Also published on Medium.

It’s a well known fact in the software world that your productivity as a developer is not linear in the time you spend programming. What this means is that in 4 hours of code writing, you will produce significantly more code than x2 of what you produce in 2 hours of coding.

That happens due to the “Flow” or “Zone” effect. If we are lucky, after coding for a while we go into a “Flow State” where we are uber-concentrated, become one with the code and the loops and conditions stream effortlessly from our brain into the IDE without passing through our fingers. When we are in a flow state we write code faster, better and with less mistakes.

Getting into a flow state is hard, and interruptions and distractions take us out of it immediately (which is why open plan offices are the bane of developers productivity). However, getting into the flow and maintaining it is a mental skill that can be honed, and there are several tricks that help me when I need to do it fast.

# Have a Ritual

Rituals are technical things we can do to help our brain quickly snap to a new situation due to the sheer familiarity of the process. I like to:

Move to a quiet location. This is especially important if you are likely to be approached with questions at your desk. If you are a manager, set clear expectation around where you are available and when you need quiet time. Your team should and will survive without you for a couple of hours, I promise.
I like to use the couch in front of the window at the side corridor as my quiet place, so you go and find your own quite space.

Make a fresh cup of coffee. Self explanatory, duh.

Switch off notifications. Your phone should be on do not disturb mode. Close those social media tabs. Close your email client. Turn off browser notification. Seriously, nothing interesting happens there anyway.

Close unneeded windows and tabs. Isn’t it nicer to work in a clean environment? Plus, less chance for distractions and less junk on your RAM.

Remove your shoes. Because how can you write software while wearing shoes?!

# Use Mental Reminders

It’s easier to snap back into flow state when you have reminders to where you left off the last time you wrote code.

Draw a design/architecture diagram. I have a notebook of architecture diagrams that I create for my projects. Whenever I need to get back to coding I look at the diagram for the code I am writing and add some details to it, and it helps me to quickly get thinking in design again.

Write where you left off. *Inside your source code*. I have a friend who likes to write inside the source code what he was doing before leaving the office at the end of the day. This way when he comes in at the morning and tries to compile the code, the error messages force him to read the comments and help him pick up where he left off.

# Do Some Warmup

Switching between mental states is just as hard and switching between physical states, but where the sports world already realised the trick of using warmups to help these transitions, we keep trying to jump between mental tasks with no adequate preparation and being surprised that we are not very effective at it.

Whenever I start a new task or get back to programming after a pause I tend to feel “lost”, as if my brain is not used to thinking in code anymore. Taking on a simple programming task helps me realign my brain. Here are some simple things I like to do:

Document some code. In them olden days when it was common practice to *gasp* comment your code, I liked to find some pieces of code that weren’t as clear as they should be and document what they were doing. These day I just lightly edit some code to make it self-documenting.

Refactor some code. This is a great passion of mine. I like to start every task by lightly refactoring the code in preparation for the new feature I am about to implement. It’s fun, it helps maintain a high quality code base over time and as a bonus your manager can’t complain that you are wasting precious time on refactoring instead of delivering features.

I like these options because they help improve the project over time, but if you are not excited about any of my options:

Find an unrelated coding task you do enjoy. Coding quizzes? Amazing. Developing a small game? Super cool! Implementing a small feature? Awesome. Anything that gets you thinking in code instead of in human.
Just make sure that the task is well contained and that you are not likely to spend more than ~30 minutes on it, else it will lose the benefit of helping you become more productive in your actual job.

# Development Superpower

When a state of flow has such a major effect on your development productivity, being able to get into it quickly and maintain it is a development superpower. It helps you complete your tasks faster and better, makes you more effective at works and leaves your free time to be, well, free.

I’d say it’s a skill worth honing.

## Understanding the Y Combinator

I am now reading Types and Programming Languages, and I’ve been trying to wrap my head around the Y combinator and why it works. This is how I explained it to myself:

We want to define a recursive function, which means the function should be able to refer to itself. Unfortunately, Lambda calculus does not give us this option, so we define a function of the form:

$g = \lambda func. \lambda param.\space\text{return something or} func(param')$

Where $param'$ is some reduced version of $param$. In order for this thing to be a recursion, we need to find a parameter $func$ for which:

$func = g(func)$

We notice that $func$ is a fixed point of $g$ by definition, hence the name fixed point combinators. We also notice that it must be a function of $g$ (otherwise it’s a constant and we can show trivially that it doesn’t work, duh), so we can write:

$Y(g) = func = g(func) = g(Y(g))$

Cool. Now we are looking for $term_0$ such that:

$Y = \lambda f.\underbrace{\text{ } f(term_0) \text{ }}_{term_0}$

Hmmm… Ok. Let’s try to name $term_0$ and pass it as a parameter to $f$, will that work?

$Y = \lambda f.\underbrace{(\lambda x. f(x))}_{term_0} term_0 =\lambda f.\underbrace{(\lambda x. f(x))}_{term_0}\underbrace{(\lambda x. f(x))}_{term_0}$

This sucks. After our change we no longer need to pass $term_0$ to $f$, but $term_1$ :

$Y = \lambda f.\underbrace{(\lambda x. f(term_1))(\lambda x. f(term_1))}_{term_1}$

Fortunately, can easily express $term_1$ using our bound variable $x$ as $(x x)$! So if we write:

$Y = \lambda f.(\lambda x. f(x x))(\lambda x. f(x x))$

We win!

We can see that the Y combinator as we defined it is a fixed point of the function $g$, just like we wanted.
Great success :)

I ignored reduction rules for the sake of simplicity, but it’s interesting to note that the book talks about another type of fixed point combinator, which should be used under different reduction rules:

$fix = \lambda f. (\lambda x. f (\lambda y. x x y))(\lambda x. f (\lambda y. x x y))$

I wonder how many fixed points $g$ has under each set of reduction rules.

## Tesseract OCR + Open CV 2 on iOS

Disclaimer: This is a quick and messy post that I wrote just so that I will not forget what I did. I am not sure that this is the best way to do things and there may be redundant or missing steps. I will clean this up if I need to do it again. If you happen to go through this procedure and find mistakes, drop me a note and I will fix the post.

# The problem

• I needed to add this build of Tesseract OCR to my iOS project, which uses Open CV 2.
• Following the installation procedure in the link, caused the following error:

• I tried solving it using this stack overflow solution, but it caused a circular dependency issue – every time I removed and added some framework, I got the following error for another framework:

clang: error: linker command failed with exit code 1 (use -v to see invocation)

# What worked

• Added the Tesseract OCR iOS project from the link into my workspace
• Added another build target for the Tesseract project, of type: Cocoa Touch Static Library
• For my new target:
• Under build phases, compile sources – added Tesseract.mm (add any file that needs compiling, really)
• Under build phases, copy files – added Tesseract.h