Coding, Fast and Slow, Just Like Chess
An essay: How adapting from fast to slow chess got me thinking about coding in Python
A few years ago, when we were all stuck in our homes more than we wanted to, I decided to take up chess. I knew how the pieces moved and all that, but I had never learnt the tactics and strategies. So, I set up an account on a popular online chess site, watched a few video lessons, and started playing online.
The first decision I had to make was to choose which time-control version to play. At one end of the spectrum, there are one-minute matches. Each player gets a minute to play their moves. The clock ticks down until the player makes a move. Once the move is on the board, the other player's time starts to count down until they move. This is a fast and furious version of the game.
At the other end of the spectrum are the seven-day games—players have a maximum of seven days to make a move. So, a single game can take a while. This is the classic, slow version of chess where there's no time pressure.
I chose to play ten-minute games. Each player starts with ten minutes on their clock. This is much calmer than the one-minute frenzy, but you still can't spend too long mulling about each move, as you'll run out of time.
You may be wondering whether you're reading the wrong Substack this week. I can confirm this is The Python Coding Stack. And we'll get to Python programming soon.
Today's post is a rare essay-type piece rather than the usual article focussing on specific Python topics and concepts.
Chess, Fast and Slow
My first and, until very recently, only experience with chess was the fairly rapid version of the game. Ten minutes is not a lot of time. An average chess match consists of 30-40 moves per player, so that's fewer than 20 seconds per move on average. This was the chess I learnt to play.
A couple of weeks ago, I posted a random comment about chess on Twitter, now X. Soon after, I was challenged to play by Thomas, a fellow Twitter user in my network. And he set up a one-day match—each player has up to 24 hours for each move. In practice, players play quicker than this, so games don't drag out for weeks but are over in a couple of days or so.
I lost badly. And I didn't just lose the first few matches against Thomas but other one-day matches I played against other players, too. I was doing much better in the ten-minute games, but I couldn't figure out what was wrong with my one-day games.
Why are these two versions of the same game so different?
And I will get to coding and why all this chess talk is relevant. I promise.
Slow chess • Goodbye working memory
My biggest challenge when playing slow chess was keeping my train of thought across several hours and days. There were always long pauses between moves. Let's say it's my turn. I spend some time thinking about my strategy for the game and possible future moves. I decide my next move and put it on the board.
Then I return to the rest of my life–work, helping the kids with their homework, dinner, and whatever else happens in my typically busy day.
Several hours later, I return to my phone or computer. It's my turn to play again. But what was I planning to do? I can't remember now.
Yes, yes, I should have taken notes and all that. But life's too short and, let's face it, I'm not aiming to become a chess grandmaster!
This is less of a problem in fast chess since I can rely on my short-term, working memory to keep track of my plans and all the possible future moves I think of.
Slow chess • Seeing the whole board
So, I had to adapt how I played to deal with the slow version of the game. Now, each time it's my turn to move, I look at every piece on the board. I check which of my pieces are being attacked. And then I look at what my pieces are attacking. Where could my pieces move next, and where could my opponent's pieces move? And once I have a good vision of the whole board, I can start to remember the status of the game, who's on the front foot, and what my best possible moves are.
I can no longer rely on my short-term working memory to help me glide through the game within a quarter of an hour or so. But now that I'm forced to slow down and study all the pieces on the board each time I need to move, I'm less likely to miss a good move or a trap being laid down by my opponent.
The slow pace means I can see the whole board each time I need to move.
Fast chess • Tunnel vision
I'm not just playing the one-day games. I'm also still playing the ten-minute games. But I've now realised a flaw in my ten-minute game that I hadn't noticed earlier: tunnel vision. I tend to focus on the pieces I'm moving and planning to move, occasionally losing sight of the pieces that have been sitting quietly on the board for a few moves.
And that spells trouble. I either miss a really good move or fail to spot a devastating attack by my opponent.
Fast chess • Zooming out
But now that I've been forced to adapt how I play because of the slow games I'm playing, I can bring some of that "zooming out", which I have to do in slow chess, to my fast chess game, too. Sure, I need to keep an eye on the clock. But I'm gradually learning to quickly zoom in and out of the board. Look at the two or three pieces I'm planning to move and the relevant opponent's pieces, but also look at the rest of the pieces and get the bigger picture.
The result is that my fast game has improved, too.
I'll return to my beginner's views on fast and slow chess later. But it's probably time to shift to the topic I know a bit better: programming.
Coding, Fast and Slow
Here's a scenario I often see when teaching beginners. I give them a problem to solve. Several students start writing Python code within seconds. That's good, no?
Not necessarily. This is the equivalent of moving your chess pieces too quickly without stopping, slowing down and thinking about what you want to do, looking at all options.
What data structure should I use to represent the data? Should I put some of the code in functions? Or perhaps this is a good used case for creating a class or two? What are all the options I have? What are the advantages or disadvantages of each one, and which will leave me in a better position in my program? What traps is my opponent, the "bug generator", laying out for me if I go down this path?
Slow coding has its advantages. Unlike chess, you won't run out of time if you opt for fast coding. However, like slow chess, the time you spend thinking about your options will ensure you'll make the best choices within the limits of your knowledge and experience.
Of course, no amount of time thinking about moves will help me win a chess game against a grandmaster. You need to know your stuff to be able to put the right moves on the board or write the best code to solve your problem.
Coding and working memory
But here's one place where chess and coding diverge in this comparison. Slow coding does not mean writing one line of code every few hours and doing something else in between! Slow coding is the process of pausing to think and plan before diving in to write code. But in the stints when you're writing code, you can write for reasonably long stretches. This means you can rely on your working memory.
I'm sure I'm not the only one who returns to code in the morning, and I have to spend time to get back into the flow of what I was coding the previous day. The code is no longer stored in my working memory.
Fast and slow Coding • Seeing the whole board
Playing slow chess taught me to avoid tunnel vision. It made me aware that, at times, I focused only on the pieces I was planning to move. Instead, I should zoom out to see the whole board. This concept is just as important in coding. Often, you're focussing too much on the function you're writing or the class you're creating and perhaps lose sight of the entire code.
Luckily, unlike in chess, you can have it all in programming. In chess, you either have the working memory advantage without the time to stop and think, or you have all the time you want but can't rely on short-term memory to maintain your train of thought. In coding, you can have both. You can go into slow mode to stop to think at any point you want. But once you finish thinking and you're ready to 'make your move', you can switch to fast coding and get into the flow.
Watching The Grandmasters Play One-Minute Chess
My recent interest in chess led me to watch some professional chess matches. One of the formats they play is the Bullet game. These are one-minute games. Each player starts with one minute on the clock. Usually, they also get an extra second for each move they play, but let's not get distracted too much by the subtleties of the time control. They're fast games. Very fast. I also tried to play this format online. But it's tough. There's no time to think.
So how can the chess grandmasters play such high-quality games at this speed? They're exceptionally good at recognising patterns on the board and knowing from experience, often subconsciously, what the most likely best move is without thinking for too long. The thousands of hours they spent studying and playing chess gave them this unique vision and insight. They can make pretty good decisions even when they're in fast mode.
And watching the coding grandmasters code
The same is valid for coding, of course! Experience brings with it the ability to make quick decisions in some situations. Let me clarify: I'm not suggesting that experienced programmers can stay in fast mode all the time. Stints in slow mode are valuable for all programmers.
However, experienced programmers, just like professional chess players, can recognise situations that are similar to ones they've encountered before and come up with the right solution without too much thinking. For example, experience helps programmers choose the right data structure for a particular task without the need to try several ones and find their limitations.
Don't be fooled if you're a beginner struggling with a coding problem and see an experienced programmer solve the same problem in five minutes. It didn't really take the experienced programmer five minutes to solve. It took years and years of coding!
Endgame
I still relapse too often into my tunnel vision when playing chess. I picked up the bad habits in my early phase. And bad habits are hard to shake off—but not impossible. I'll keep trying.
I feel I'm improving at "seeing" the lines and patterns on the chessboard and getting a sense of the whole situation. And I'm getting better at visualising the board two or three moves ahead. I'm not seeing chess pieces move on the ceiling yet, though, Queen's Gambit-style!
And this skill is remarkably similar to "seeing" the whole code when you're programming. It's great when you can visualise the current state of your entire program. But it's even better when you don't just visualise your entire code in its current form but in possible future forms depending on which "moves" you choose to make.
Strategic thinking and foresight are essential skills in both chess and coding. In chess, "strategy" refers to the long-term planning and overall approach you plan for the game. "Tactics" refers to the short-term sequence of moves you use to gain material or deliver checkmate, say. Similarly, we need both strategy and tactics when programming.
Here's to more thoughtful chess-playing and Python coding ahead!
Stop Stack
#29
Recently published articles on The Python Coding Stack:
Butter Berries, An Elusive Delicacy (Paid article) How my quest to find butter berries at the supermarket led to musings about Python lists and dictionaries and more
Pay As You Go • Generate Data Using Generators (Data Structure Categories #7) Generators • Part 7 of the Data Structure Categories Series
Clearing The Deque—Tidying My Daughter's Soft Toys • A Python Picture Story Exploring Python's
deque
data structure through a picture story. [It's pronounced "deck"]The Final Year at Hogwarts School of Codecraft and Algorithmancy (Harry Potter OOP Series #7) Year 7 at Hogwarts School of Codecraft and Algorithmancy • Class methods and static methods
Tap, Tap, Tap on The Tiny
turtle
Typewriter. A mini-post usingfunctools.partial()
andlambda
functions to hack keybindings in Python'sturtle
module
Recently published articles on Breaking the Rules, my other substack about narrative technical writing:
The Story So Far (Mid-Season* Review). Are you back from your holidays? Catch up with what you've missed
Broken Rules (Ep. 10). Let's not lose sight of why it's good to break the rules—sometimes
Frame It • Part 2 (Ep. 9). Why and when to use story-framing
The Rhythm of Your Words (Ep. 8). Can you control your audience's pace and rhythm when they read your article?
A Near-Perfect Picture (Ep. 7). Sampling theory for technical article-writing • Conceptual resolution
Stats on the Stack
Age: 5 months and 5 days old
Number of articles: 29
Subscribers: 1,020
Each article is the result of years of experience and many hours of work. Hope you enjoy each one and find them useful. If you're in a position to do so, you can support this Substack further with a paid subscription. In addition to supporting this work, you'll get access to the full archive of articles and some paid-only articles.