The concept of flow holds a mystical, holy place in the lore of software development. Nearly any programmer can tell you about being “in the zone,” totally immersed in code, oblivious to the passage of time. Countless programmers have cited this apparently hyper-productive state when stating their need for enclosed office space, separation from their colleagues, working from home, working at night, or any other similarly isolated work situation.
I’m not going to dispute the existence of a flow state; I’ve experienced it myself. I know the feeling of looking up after solving an interesting problem to find that fourteen hours have passed, it’s the middle of the night, and I haven’t eaten anything since the previous morning. I’ve felt the satisfaction of burying myself in ideas until finally finding a way to convert them into code.
However, I will suggest that working in isolation in order to promote a flow state is not the most productive way to write software. It’s better than working in an environment filled with distractions unrelated to the task at hand, but less productive than working in a collaborative space, or pair programming. To illustrate this, consider another, simpler task that also often involves working in a flow state: cruciverbanalysis.
There’s no such word, of course, but if there were I’d like to think it would mean solving crossword puzzles (a cruciverbalist is someone who constructs crossword puzzles, hence a cruciverbanalyst would be someone who solves them; much like the relationship between cryptographer and cryptanalyst).
Standard American-style crosswords depend on uncertainty for their trickery; many of the clues can have two or more answers. As an example, consider the clue “put away.” The answer could be any of “EAT,” “STOW,” “STORE,” “HOARD,” “JAIL,” or a synonym for any of these. The answer could also be the past tense of any of these answers, since “put” can be either past or present tense.
Thus, to find the correct answer for one clue you have to consider the answers to the clues that cross (or “check,” in crossword parlance) the letters for that clue. But the answers to those clues may depend on the answers to yet more clues, or the possible answers to the original clue. So, the solver has to build a mental picture of the puzzle with possible answers for each clue, as well as the interactions between them. As you might imagine, it takes some time to build up this mental picture, and a great deal of concentration to maintain it. Interruptions, distractions, and time away from the puzzle all quickly destroy it. In short, crossword solvers often work in a flow state.
However, there are a number of ways that a solver can fail to complete a puzzle:
- The clues require knowledge of specific facts that you don’t know.
I dislike this type of clue, because you either know the answer or you don’t; there’s no wordplay or clever trick to figure out. If you know that the capital of Mali is Bamako, or that John McCormack was Dame Nellie Melba’s preferred tenor, then good on you. But, if you don’t know, then you’d better hope you know the answers to all of the checked clues.
Think about when this happens while you’re writing code (it happens to everyone, you’re not omniscient). You come across an API you don’t know, an unfamiliar area of the code, or a language feature you haven’t used before. You’re stuck. You can take the time to look it up, but that takes time and interrupts your flow anyway. If you’re working with someone, such as a pair, who does know the answer, then you keep moving forward without a hitch and learn the answer in the process.
- You don’t get the trick.
Lots of crossword clues try to play on your assumptions to lead you down the wrong path. For example, the clue “Hall of fame” probably makes you think of the Baseball Hall of Fame, or something similar, but the answer could be “ANNIE.” The clue “Peter, Paul, and Mary” probably makes you think of the musical group, but the answer could be “SAINTS” or simply “NAMES.” Infrequently, puzzles will go outside the boundaries of the English alphabet to add to the trickery. Consider an eight letter answer for “The city of brotherly love.” You have to use Greek letters to get the correct answer: “(phi)LADEL(phi)A.”
If you miss the trick, you can’t get the answer. Having more than one person, with more than one viewpoint, looking at the clues will greatly increase the chance that you’ll see all the possibilities.
Designing software well requires choosing a correct approach to each problem. You can’t choose the right approach if you don’t think of it. Sometimes starting a conversation with “I’m thinking of solving problem X with approach Y, what do you think?” can be the best possible use of your time. Someone with a fresh perspective, or just a different perspective, might suggest a better approach than the one lodged in your mind. It’s up to you to set aside your ego long enough to accept the new approach, but that’s a different blog post.
- You go down the wrong path.
Truly insidious crossword clues not only attempt to lead you to the wrong answer, they try to lead you to a wrong answer with the same number of letters as the right answer. In some cases the wrong answer will have some of the same letters in the same positions as the right answer, increasing your confidence that the wrong answer is, in fact, correct. This wrong answer will then give you the wrong letters for checked clues, leading to more wrong answers. Once you start down this dark path, it’s very, very difficult to recover. This is, incidentally, why crossword enthusiasts insist on solving in pen: you have to be certain before you write in an answer. Otherwise you have to keep everything in your head, which adds to the challenge.
In software, as in solving crosswords, this is a path you do not want to go down. Once you choose the wrong approach (for example, using inheritance where it isn’t appropriate), subsequent decisions take this into account. It can be very difficult to figure out where the true problem lies once you do run into a brick wall. Having someone question your design decisions, or offer alternatives, can help to avoid going down the wrong path to start with. And, when you do have to backtrack, you absolutely want to involve someone with a fresh perspective. Another person, free of your assumptions, will more likely see the misstep.
Finally, consider that crossword puzzles are far simpler than software: there’s only one correct answer to any puzzle (with one notable exception). Software problems can have any number of workable solutions, with various trade-offs that make each more or less appropriate in a given situation. Also, working on any software project of significant size is really more like working with multiple people to solve several puzzles which check against one another in various dimensions. As the complexity of interactions increases, I’d expect the advantages of collaboration to increase at least linearly.
For those who would still argue that flow is necessary because it’s how programmers prefer to work (it can be quite enjoyable), I’d suggest you get yourself a book of crosswords. With puzzles you can sit by yourself and exercise your flow state as much as you like without spending anyone else’s money, or making anyone else’s life more difficult.
About the Author
