Seeing how unimportant the chess board and pieces seemed to Beth Harmon in the TV series The Queen’s Gambit, and a recent Software Engineering Radio podcast on The Programmer’s Brain made me think about how programmers work. How much of it is using tools out in the real world, and how much goes on inside our heads? What can we do to make our lives better?
Chess
I was watching bits of The Queen’s Gambit recently, and it made me think of how advanced chess players use the board and pieces. (I’m nowhere near this stage, so this is largely assumptions by me, and I’d be grateful if proper chess players can put me right.)
By the time you’re really good, it seems to me that most of the time the chess board is for only two things:
- Communicating your move to your opponent;
- Your opponent communicating their move to you.
Even though the board also shows the complete current state of the board, you use a model in your head more than you use the board.
As a result:
- You can reason about the system, zooming in and out of different levels of detail, or playing time forwards or backwards, as Beth does lying in bed.
- It’s rare that a match gets played all the way to checkmate, because a player can see that they have inevitably lost before getting to checkmate.
- You can play chess without a board or pieces, e.g. by speaking your moves out loud.
The chess board is a tool, but most of the action goes on in the players’ head. As a result it’s a spectator sport only for spectators who can do at least some of the work in their head too.
What’s going on for programmers?
I think that there’s a similar split between using tools and brain work for programmers. This diagram is a statement of the bleeding obvious (no surprise with this blog, then – just search for “obvious”).
“The system” is everything that’s not your brain, the keyboard, mouse and monitor.
Please don’t think that I expect you to just stare into space, dreaming up your beautiful thoughts, and then with a flurry of typing and clicking all this is captured in your IDE. I realise that there’s often back-and-forth. There’s more below in the section on Software Engineering Radio, but sometimes you are using the keyboard and mouse to investigate, to ask and then answer questions and so on. These are developing your mental model, with the aid of the tools.
Also, it might be that the diagram points out to you the importance of keyboard shortcuts! The more quickly you can move your brain to its next state (by going around the loop from your brain back to your brain again), the better. The tool (keyboard and / or mouse) is just an overhead, so minimising this is a good idea.
I think that the main thing I’m trying to get across with this diagram is to remind you (and myself) to do enough thinking to go with the typing and clicking. Getting rid of Big Design Up Front doesn’t mean getting rid of design, i.e. thinking. It’s about doing the right amount, at the right time, with the right people, using the right tools, and so on.
Bubble art
Another way to look at this is with bubble art as an analogy.
With bubble art you put paint into a wide container, blow bubbles into it with a straw, then press a piece of paper down onto the bubbles to capture some kind of imprint. The typing up your thoughts is like pressing a piece of paper down onto the bubbles of thoughts in your head, to capture their structure in something more permanent and more easily shared and executed.
The kind of thing that the bubbles represent is the information that you’d show in UML diagrams or C4 diagrams. I’m not saying that you have or should have exactly these diagrams in your head, but that you need to have the same kind of information as would go in the diagrams.
Threats
If the brain work is the important and valuable thing, then it seems sensible to look at risks or threats to that important and valuable thing. If you’re being honest there are two problems, rather than one:
- Other people stopping you thinking;
- You stopping yourself from thinking.
Both can be thought of as versions of the “now, where was I?” problem.
At the risk of mixing metaphors in a horrible way, I sometimes use a coal mine as a metaphor. To do productive work in a coal mine, you need to be at the coal face. Unfortunately, the coal face is usually deep underground, and then along corridors for quite a way. So, from the moment that you decide to mine coal, it takes quite a lot of time to be ready to actually do so.
If you’re programming, you usually can’t immediately start typing exactly the right thing as soon as you sit in your chair. Instead, you need to create (or recreate) the mental model that will guide your typing. (It takes a while for you to blow the mental bubbles.) This is similar to going down the mine shaft and along the corridor.
Unfortunately, an interruption will usually whisk you immediately back to the surface / pop all the bubbles. Recovering from the interruption isn’t nearly so instant. Instead, you ask yourself “now, where was I?” and start descending the lift to get to the mental coal face again. If you get interrupted often enough, you never get all the way there again, which is where the most productive work happens. So you end the day having sat in your chair at your computer for the right amount of time, but you’ve made little progress.
There’s a book on the benefits of concentration to some kinds of work called Deep Work. I think that this fits with the coal mining metaphor well. There’s a podcast with the author that’s worth a listen, but also I recommend looking at a review of the book that takes into account gender and power stuff too.
Other people stopping you thinking
There is a balance to be struck at work between team effectiveness and individual effectiveness, which won’t always work out well. You might not have enough clout at work to reduce interruptions, or work in a quiet enough environment (at home or work). I’ve already written about noise at work.
If interruptions are a problem, I suggest you try talking to your boss about it. What are realistic expectations on how quickly people can expect a response from you? Are there different communication channels open that interrupt you different amounts, that can be used for different things? E.g. Slack, email, phone? Can you turn off notifications for things, so that you only have to bother with e.g. email when you have come to the end of your scheduled block of deep work time? Does that meet expectations?
You stopping yourself thinking
The lure of stimulation from the phone in your pocket is strong. I’ve found it useful to work at cultivating a longer attention span and a higher boredom threshold, to fight the corrosive effects of wanting the next little ding of stimulation. Turning off notifications helps a lot.
So I fight the temptation to “just nip over to Twitter” while my code’s compiling. I force myself to stay where I am mentally, while I wait for the system to update or tell me new information. (I don’t always succeed.)
It’s OK if the thoughts in your head go a bit quieter while you wait – it’s certainly better than inviting Twitter / Reddit etc. in to shout something new and shiny. It’s easier to turn the volume back up in a quiet mental room than it is to stop the Twitter party that’s taken over your head so you can start filling your mind with code thoughts again.
I try to plan breaks, so I can tell myself “No, I’ll check my email in half an hour rather than now when I’m in the middle of something”.
Software Engineering Radio podcast on The Programmer’s Brain
The SE Radio podcast often has a lot that’s worth listening to. One of the recent episodes was related to this post and also in this category, with Felienne (who’s also a host on the podcast) talking about her book The Programmer’s Brain.
I won’t go into everything that was discussed – instead, I recommend you listen to it. There is one thing that I want to bring out in the context of this article, to do with different kinds of thinking associated with programming (and other tasks).
She describes two ways of thinking that she calls exploring and transcribing. Sometimes you are still at the bubble blowing stage. It’s hard to predict how long this will take, or what the outcome will be. At other times, you basically know what you need to do and it’s largely typing. You might need to do some thinking, to expand from one level of detail to another, but it’s generally low risk stuff.
I’ve not used Basecamp, but it has a related concept called hill charts. These are to record progress, but take into account that 4 days of exploring has a different feel from 4 days of transcription. They compare exploration then transcription to climbing up a hill and then coming down the other side. Climbing the hill / exploring is riskier, more open ended and so on than coming down / transcription.
Summing up
I realise that this is all over the place, and also a bit navel-gazing. As a professional programmer, I think a little introspection is a good idea, if it helps you to get better at your trade, or removes annoyances or bad habits that might have built up without your noticing.
Random Tech Thoughts 