Fixing the Marriage Between Flow & Code Review

This is an archive of blog post I wrote during my third venture (PullReview).

Flow - From my First Taste to Complete Addiction🔗

When I was still in school, I quickly discovered the impact of my attention on my efficiency - not only in terms of time - in terms of quality also - double strike! The equation was simple: more focus equals less time spent working - equals more leisure time. This was enough to push me to improve it.

Through the years I found a pattern that worked very well for me: work for 45 minutes, then take a break for 15 minutes. This might remind you of the so-called "Pomodoro technique". I made the same link recently when I discovered it.

Going forward, I have improved my technique and my capabilities, finding new patterns for different kinds of work. The 45/15 method was definitively the best for study. For writing or coding, 90/30 was perfect.

Finally, I experienced the concept of flow, that wonderful state that can keep you focused during several hours on your work - without being distracted by anything else. Even primary needs such as food, water, or sleep become irrelevant . It isn't necessary a good thing, but it's a wonderful feeling, and it was usually a time when I progressed a lot.

After having tasted the benefits of being fully focused, it's hard to study or work in a noisy environment, where you can get distracted - or interrupted - at any moment when you're trying to get into the flow. It's very painful.

My professional experience reinforced that habit. I coded a lot alone. Even when I was with other persons in the same office, they had the same modus operandi. We had silence periods during which we worked very concentrated, and very noisy periods during which we discussed, joked, and so on.

Now, when I need to work in a noisy environment, or when I'm often interrupted, I can feel the difference. I'm less productive - less creative - less focused. At some point, I don't even want to code anymore, frustrated as I am by my underperformance.

The Cost of Interruption🔗

As I already mentioned, that state is called the flow:

a deep focus on nothing but the activity – not even oneself or one's emotions.

I'm far the first to experience it nor the first to discuss the difficulty reaching it. It's well discussed in the community of developers, a lot of thoughts and opinions about the cost of distraction, noise, and interruption. Swizec Teller argues that's why a lot of developers work at night. Even a long compilation time is considered as an annoying interruption.

Paul Graham states that maker and manager don't have the same schedule, because they do not the same job. Jason Fried shared it as a gut feeling. It takes time to get in the zone: 15 minutes to one hour. Once you're in that productive zone, all your attention on what you're doing, you don't want to be interrupted. In Getting real, he reminds us of the importance to lay out “alone time” to be creative and productive - because it takes time to get in the zone - to be focused on your work. Interruptions are natural enemies.

Joel Spolsky goes farther and makes the math of the cost. According to Joel - answering right now will save the blocked developer 30 seconds at the cost of 15 minutes for the answerer. Of course, that decision depends on the blocking question, and on the real costs of the interruption for a person.

These are not just individual - anecdotic - opinions by famous professionals, or within the community. Scientific researchers have observed it and have tried to measure that cost. Speech and office noise cause a drop of 66% in knowledge workers' productivity. It requires more than 15 minutes before get into the flow after or not an interruption (broken link), a very critical period during which the worker is very sensitive to noise and interruption.

It seems undeniable that interrupting a developer costs him - and his organisation - more than just the interruption time. When someone is stuck, he doesn't necessary realize that cost as he's focusing on his own problem. Some issues or problems are probably worth the interruption cost, but most probably don't as an answer could be found in less than 15 minutes without distracting someone else (using Google, StackOverflow, internal wiki, etc.).

So, interruption is not necessarily the best strategy. As it is a complex question, there are several solutions, for instance: Scrum and its daily standup meeting, one person sacrifice, weekly maker's day, schedule alone time, deep thinking in the shower, or physical setup and consensus (“don't disrupt me when I'm wearing headphones”).

Beyond the productivity loss, there are some activities that needs the action of a peer. There is one important in software development: code review.

Flow vs Code Review🔗

It's especially a trickier question - as code review affects the flow of two persons: the reviewee and the reviewer.

On one hand, the reviewee's flow is interrupted at the time he requests a review. He's forced to wait until the reviewer will review and send it back to him. During the wait, he could do something else, start to implement a new feature or to fix a bug. But the longer the wait is, the more complicated it will be for the reviewee to get back into the code.

On the other hand, the reviewer has to decide when he'll review the code. Does he interrupt his work asap in order to not answer one week later? When is it the good time? Even if the reviewer finds a good moment, such as when he is finishing to implement a method, the time he will spend to review is a time he will pay to dive back in his own code. It's his flow against the reviewee's one.

The benefits of code review are known, but it costs. It is a daily - and important - task that takes in average more than 30 minutes. It's an important feedback loop for the reviewee's learning. The reviewer knows that and takes it into account. But in the worst case scenario, he will start 1 hour after having received the code, spend 15 minutes to read the code, answers trivial comments including team convention or flaws that could be detected by a linter, and spend another 15 minutes to get back to his previous level of focus. The reviewee will wait 2 hours and 15 minutes to get the review, a few minutes to read it, and 15 minutes to get back to his own previous level of focus. What a frustration for both!

It could be even worse if the given review just consists in a simple green light because the reviewer doesn't have the time to do more and has just evaluated the implemented feature is compliant.

In other scenarios, the code review would initiate a discussion leading a better design, a learning, and a great experience of sharing knowledge. That kind of review takes time, but it will be worth it for both! It totally depends on the code to review and the quality of the review against the flow of each other. Finding a good balance is not an easy question!

Making Flow and Code Review a Happy Couple🔗

There are solutions such as automated code review tools, including static code analysis tools. They should be used for complexity, style convention, and other simple checks, before any review. But it cannot replace a human for different reasons: automated software are aimed at underlining code issues, not toward improving developer capabilities, and are unable to prioritize the tasks (this one is critical for the business), or unable to deal with complex context. However, by using tools, the review can at least be focused on true added value whether in terms of code and design, or knowledge transfer.

At 8th color, each of us deals differently with those questions - due to our respective professional experiences. I'm the more addicted to the flow, where Martin and Stéphan are very used to deal with interruptions.

We do not just keep to our respective habits. We discuss them, we confront our opinions - and we try to come up with solutions. For instance, we've quickly adopted some static code analysis tools in Ruby for the reasons explained previously or a chat software to ask non urgent questions without interrupting each other. More specifically, we're building a structural solution that finds the balance between kick-ass code review and flow - more on that later.

We're very interested in others' experience and solutions. What's yours? Do you think automated tools are a good intermediary solution? Do they help you not only to improve your code but also to learn?

If you have any comment, question, or feedback, please share them with me.

Subscribe to the blog!