Focus and Flow: trade-offs in programmer productivity

Programmers are fiends for productivity methodologies — ways to estimate tasks more accurately, get more done in less time, and get work done at a higher quality. I, too, have fallen far into this hole. Between all of the books I’ve read, I’ve come up with some interesting findings that may be useful to other software developers.

“Being completely involved in an activity for its own sake. The ego falls away. Time flies. Every action, movement, and thought follows inevitably from the previous one, like playing jazz. Your whole being is involved, and you’re using your skills to the utmost.” Mihaly Csikszentmihalyi on flow state

At first glance, it’s easy to argue that achieving a flow state is a good thing. It’s enjoyable, and one can get a lot of work done without feeling burned out at the end of it. By definition, a flow state is non-collaborative; you’re not going to be in that mindset when you have responsibilities to look at Slack channels, and you’re certainly not going to be in that mindset while you’re in a pair programming session. In addition, engineers sometimes “flow” for a full day or more of wasted time. If the concept was poorly thought out or designed from the beginning, flow state hurts productivity.

A common technique that many productivity gurus live by is the Pomodoro timer — set a timer for 25 minutes, for which you have a singular goal in mind; when the timer goes off, you take a 5-minute break and repeat. Every four iterations, take an extended break. The Pomodoro timer is an intentional flow-breaker under the idea that focused chunks of work provide better results than a lengthy flow-state session. Those who fully buy into the Pomodoro concept even argue that one should stop what they’re doing effectively immediately; a minute or two is allowed to finish up your thought and write notes if necessary, but no more than that. Again, this is an argument explicitly against flow state; regardless of if the juices are flowing, one should take a break.

I find the downside of the Pomodoro technique is that my motivation has “reset” along with my short break. Before I start the next Pomodoro, I find it easy for me to get distracted — to get caught up in reading e-mail, or any other problem that I was temporarily able to put off while in the middle of the session. On the positive side, once I have started the timer, that 25 minutes tends to be quite productive. When I use several Pomodoros over a day instead of trying to achieve flow, I tend to get more done overall.

There’s another reason I’m a proponent of the Pomodoro technique — shallow work takes up a vast majority of many knowledge-worker’s time, and on analysis, this adds very little value to either the company or to the worker’s knowledge growth possibilities. Shallow vs. deep work is a concept tackled in Cal Newport’s “Deep Work.” Newport explains that the brain is designed to seek quick, guaranteed dopamine hits, and that behaviors that feel productive are a prime way for it to accomplish that desire. The biggest example out there is the amount of time spent reading and responding to e-mail, Slack messages, and other asynchronous communication methodologies. The act of checking e-mail actually produces a tiny dopamine hit, a way of the brain rewarding yourself for doing something that may produce social value. The fact that you don’t know what might be sitting in your e-mail inbox is precisely why it’s addictive and exactly why e-mails are read and sent too often. This is no different than the dopamine hit received when browsing social media! The Pomodoro technique helps here, because it’s designed to have a single goal when starting, but requires the worker still to be cognizant that some behaviors are not actually productive and should not be done while in the middle of the focused session.

After a few years of working on it, there are a few productivity tips I’d strongly suggest for programmers:

1. Turn off your notifications! This is the biggest one. No buzzes, no texts, no dings. Do it on your phone and on your computer. You can keep things that you actually want to know, but be very careful. For example, you want to know when PagerDuty goes off, but you don’t want to see a text.
2. Turn off badges. You can do this from the notifications section in MacOS and iOS — I turn off the little red counters on all of my apps except my to-do list. In particular, I want to be sure I don’t see a red dot or number on my e-mail client, text message client, Slack app, etc. I can always check them later, or turn the badges back on after my session.
3. Carefully cultivate what remains of attention-grabbers. For example, even when notifications are turned off, Slack still makes a noise when mentioned. Sometimes, this is actually really important… but it’s usually not. Use your best judgement, and tend towards turning off the notification.
4. Batch your time on Slack and e-mails. Close the windows and open the apps only at certain intervals. Some argue that you should check only once or twice a day; for my work environment, it’s much more common (more like every 30-60 minutes). If you find yourself keeping an e-mail window open or clicking the e-mail app regularly, re-evaluate your relationship with e-mail as a dopamine-releasing concept.
5. Be very careful about asynchronous communication. Whenever possible, do not shoot off a small e-mail to someone else to kick responsibility for a task over. For example, e-mail scheduling often requires several back-and-forths, which is wasting all recipients’ time and attention. Similarly, sending a simple Slack message and hoping someone gets back to it kicks responsibility away from you, but draws others’ attention. This paradox is problematic — if you want to get an answer to something you can’t yourself, but don’t want to pull someone’s direct attention away, what do you do? There are some pretty good solutions out there, such as Twist. If you can communicate over a dedicated work means, for example over an Asana or Kanban board, that’s a much better place for communication since it doesn’t pull other attentions away. If your organization has good focus hygiene practices, Slack is relatively safe.
6. Communicate with others about your new communication preferences. Many apps have “busy” indicators on them, including Slack. Use those to tell your teammates that you’re busy and won’t see a message. Some people use tools like auto-responders, others use physical objects like a red light. Either way, tell your team what to expect when they see these indicators so that everyone is on the same page.
7. Use the Pomodoro system. I like an app called “Session,” but you can use anything as long as it won’t draw your attention until the end of your session. When you start the session, write down or conceptualize what exactly you will be working on and what you hope to accomplish at the end of your 25 minutes. If you deviate from doing that task, bring yourself back to the task at hand until the timer goes off; only then can you do something else. For example, if you have a task to complete some work ticket, checking e-mail is not part of that task! So, you are not allowed to check your e-mail. If you feel you must, you can end your session early, but there are no breaks from the task mid-session. Experiment with hard breaks and soft breaks (ie. allowed to continue the task as long as focus stays) and see what works best for you and your work environment.
8. Do pair programming sessions. Pairing is great because both people’s attentions are held. It’s bad form to check your e-mail while pairing together, and the social pressure will help keep focus on both sides. Switch the driver when attention starts to wane. I’ve found that actually doing Pomodoros in a pairing session works remarkably well — at the beginning of the session, decide between yourselves what will get done. At the end of the 25 minutes, each person takes their own 5-minute break, then reconvene and switch the driver. The end result is that you get some time to consolidate the information, and information is shared more effectively between the two developers.