Learning chess and the parallels with software engineering

I’ve recently became a bit obsessed with chess, and although I am very much an amateur, I am taking the learning pretty seriously, as I think progressing is a huge part of the fun that comes with this game.

As I learn about the game, and also analyse about how I think during the games, I am seeing patterns that can are parallel to software engineering. Recognizing them is helpful to me, in order to spot what to progress on, and to become better in both fields.

Focused Learning in Vast Knowledge Domains #

Both chess and software engineering present a dauntingly vast breath of learnings. A chess player could spend a lifetime studying openings alone, just as a developer could dedicate years to mastering a single programming language or framework.

As a beginner, I’ve heard many times the advise “Do not memorize openings until you understand principles.” The parallel in software would be to not chase every new framework or languages without understanding core concepts first, such as data structures, algorithms, system design, etc…

Going back to Fundamentals When Stuck #

During many chess games, as I am still a beginner, my strategies quickly dry out: I can find myself clueless to what to do next in a certain position. I can’t find any tactics that would win material, or fin any short way to reach a checkmate. Going back to basic principles, such as controling the center, developping piece, ensuring the king safety, etc… Pretty much always end up in enhancing my position, and unlocking new possibilities.

Similarly, when debugging an obscure production issue, going back to the basics, laying everything down, usually is the best thing to do when any problem becomes either too complex, or ends up in a mess of thoughs. Simplicity and first principle also are what one should go back to, when needed, during the desinging or implementation of any software.

Evaluating Options Efficiently #

It is not possible for chess engines to compute all the possible moves instantly. And this is way more true for humans, as our CPU is way more limited for doing such specialized tasks. That is why both computers and especially humans, have to first of all, evaluate the options efficiently. That can be as simple as identifying in the first place all the moves that are not a blunder in one move, and from there, deepen the possibilities each of them offers.

In a similar fashion, as engineer, we cannot exhaustively evaluate every possible solution to a problem. Less so because of the time constraint, but more because the breath could be exponential. So we need to use both experiences and heuristics to narrow down our options before diving deep into what seem the most promising answer.

Fighting Cognitive Laziness #

One of the things that I the most guilty of, is the lack of mental discipline. I think it is something that affects a large proportion of the people nowadays as we are always overstimulated, but for me it is one of my major roadblock. Durign a chess game, I can sometimes be tempted to make a move trusting my instinct a bit too much, or because it looks good. But not doing the necessary analysis work quickly leads to blunders. So, during the short time that represents a chess game, be present. Both when your timer is going down, but also when it’s your opposent who’s supposed to play.

Software engineering requires the same discipline. It’s easy to implement the first solution that comes to mind rather than thinking through edge cases, performance implications, and maintenance concerns. But as we build the right habits, and work through the same experiences again and again, things will become more and more natural. But the brain always has to be turned on, work has to be done.