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.
The Python Coding Stack is a reflection of how I see coding, how I visualise things. If you enjoy these insights, please stick around as a subscriber, whether on the free tier or the paid one.
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.