What Developers Can Learn from Playing Chess and Video Games

I watched some chess recently. Amateurs played against each other, and a grandmaster commented it. It was fascinating to see that the weaker players all made the same mistake: when the opponent attacked one of their figures, they solely focused on this one figure and where they can move it to save it. The more advanced players reacted very differently: either they moved a different chess piece to cover their piece, or they seemingly ignored the threat and attacked an equally or even more valuable piece of the opponent.

I found it interesting and stored it in my memory as something I should consider when playing chess again. But then I started watching a series of YouTube videos of three people playing Age of Empires II against each other: two amateur players versus one advanced player. And I saw the same patterns: while the amateurs rushed from A to B to defend their base while canceling promising attacks of their own, the stronger player knew that offense is the best defense. Instead of only focusing on what was happening in his base, the experienced player tried to do more damage to the opposing bases. Seeing the same pattern again led me to think that there is more to it. I wondered if novices make the same mistake in other areas as well.

This article is about two things I learned from watching Chess and Age of Empires II:

Don’t always focus on what is most visible: dig deeper, and look at the problem from a different angle.

The second takeaway is:

If you have the chance to take action, don’t hesitate.

How to Translate Problem Solving Patterns from Chess to Programming

When a junior web developer who is somewhat familiar with JavaScript framework A and CSS framework B gets a task assigned, they will try to use A and B to solve the task. A more seasoned developer will analyze the task, break it up into smaller pieces, and then decide about which technologies to use to solve the task. And a grandmaster developer will work with the people who came up with the task to analyze the core problems that need to be solved and then collaborates with all stakeholders to find the best technical or non-technical solutions to solve the needs of the company.

Each of the three cases can lead to a very different outcome. While in the first two examples, the final result might consist of thousands of lines of code, the grandmaster solution may conclude that a change to the organization itself will lead to a better outcome, and we don’t have to write a single line of code.

While a grandmaster chess player looks at the big picture instead of focusing only on the one figure under threat, we also can come up with better solutions to problems if we have a deeper understanding of the tasks assigned to us and their broader context. The most pressing issue is not always the one that has the most significant long term impact when solved.

Remember: we developers do not provide value by writing code but by solving (business) problems. Businesses can solve problems by automation or other means like workflow optimizations or merely avoiding them. As developers, our primary job is not to figure out the best approach to solving a specific business problem. Still, because we have to understand the problems we need to solve very well, we can help find the optimal solutions, which might not always be software.

Don’t always focus on what is most visible: dig deeper, and look at the problem from a different angle.

Taking the Initiative

Another common mistake made by less experienced chess players is that they are hesitant to trade figures in situations where they could take a figure of the opponent by giving up one of their own equally worthy figures. Let’s say the two queens face each other, but both are covered. Stronger players tend to take the initiative and capture the opponent’s figure, while weaker players frequently make some other move and leave the decision to trade queens to the opponent.

Most of the time, the better move is to either take the opponent’s figure when you have the chance or make a move to save your figure from being taken by the opponent.

Hesitating to take action is also something that we can observe in the world of programming. Sometimes we know there are bugs in our code, but we wait until a large portion of our users is affected before taking action to fix them. There are also instances where developers decide not to fix security issues hoping that attackers won’t discover them.

We need to fix bugs and especially security holes as soon as we become aware of them. Furthermore, we can use automated tests to find bugs earlier, and we can and should check our applications for security issues proactively.

If you have the chance to take action, don’t hesitate.

Wrapping It Up

Playing Chess or video games like Age of Empires II seems pretty different from programming. And it is. Still, I’m convinced that often the problem-solving skills we learn doing one activity can help us become better at other activities.