While not all programmers are good chess players (and vice versa), high mental effort is ultimately used to transform small incremental moves into a larger result. In this article, I want to share how acquiring my chess skills has shed light on how I approach my work as a programmer.

The starting position in a new project

From the default starting position, I can make any move I want. I can choose the path I will follow. I am full of hope and optimism for a satisfactory implementation of a new project. Just like in chess, starting from scratch is the best time to join the project. I know I can track its full history and anticipate what will come next.

History of movements in an existing project

Sometimes in chess, you’ll join somewhere in the middle-game. Perhaps you just started helping a friend analyze their next moves, or you’re restarting a game that was abandoned days ago. In many IT projects, developers will join the project somewhere in the middle—inherited by another team, or currently in progress as they grow the team.

Let's assume that I’ve joined a growing team, where the project already has a history. The early decisions on the choice of technology, tools and implementation have already been made. This position requires me to enter a specific mindset where I must get acquainted with the entire history of the project.

Chess players often practice on pre-set puzzles and challenges, where the board is already established. Analyzing chess positions and completing a chess solution isn’t just forward thinking—it’s also moving backwards to understand how the pieces got there.

This is analogous to joining an ongoing project, because I need to get acquainted with the existing situation. I spend a good amount of time backtracking through the logs, project summaries, developer changelogs, and asking questions about how things came to be.

Project analysis and planning moves

A project, whether new or ongoing, is a complex organism. It has a life of its own, developing and growing at an Agile pace. To execute the next moves efficiently, a developer needs to define assumptions, a goal and most importantly, plan ahead.

If you don't know where you are going, each road will lead you nowhere

-Henry Kissinger

In the case of programming, just like in chess, the plan I have as well as the analysis are extremely important. In chess, I perform position analysis to get to know my place better, and to make decisions about the next moves.

The situation is similar in programming. The analysis process allows you to better understand the project, task or error that I have encountered. The plan emerges from analysis, so that I can carry out tasks that will avoid most problems—or at the very least, I am well prepared to deal with them down the road.

Predicting customer expectations vs. Player moves

The game of chess is the realm of anticipation. I make a move, the opponent makes a move, a specific position is created and I predict what my opponent is striving to achieve. The more I learn about their intentions, the better I can understand what I need to do.

In chess, strong anticipatory skills allow the player to make moves that are difficult for your opponent to play against. On the other hand, in programming, the other side is the client and, unlike chess, I cooperate with them and recommend solutions. Just like in chess, I get to know their expectations and predict what steps they can take in the next stages of work on the project.

Thanks to this, I can write code that will allow me to scale the project and develop it in ways that will accommodate changes in the future. By being focused on predicting outcomes, I can also better understand the client (and their customers), resulting in a better end-product.

Choosing optimal pathways

Any seasoned chess player or programmer knows that getting to a simple destination can take many different paths along the way. As the project (or game) gets going, each decision opens up the opportunity to take a new path. In programming, we can decide between various tools, languages, frameworks, libraries and coding practices to apply and solve a given problem.

It is no different in chess. Studying other projects’ pathways can help programmers understand what they need to do to save on time, money, and headaches. Looking at historical implementations can give us better direction, just as chess players call on other masters’ game pathways to make moves.

When choosing technologies or frameworks, for instance, we look at similar projects (inside or outside the company), and use historical results to influence how to best architect a solution.

Attack, pressure and crisis situations

As an IT project goes on, code and functionality grows. Along with this, crises can arise and developers are on ‘fire fighting’ duty. These situations are not a matter of ‘if’ but ‘when,’ and a good developer should know how to deal with them.

In chess, an attacking position means that you are using as many pieces as possible to leverage winning. It is a confident spot to be in. A programmer knows this feeling well, when code is flowing, tasks are completed, and errors are few.

Coordinating pieces and team communication

Mastering piece coordination and maneuvering in chess allows players to achieve predictable outcomes (e.g. to get an opponent’s piece, successfully defend yourself, or set up for a reliable attack). Lack of coordination between pieces will result in a weaker position on the board. When synergies between pieces fall apart, an opponent can exploit them, or an attack won’t go as planned.

This relates to any modern IT project where multiple people and stakeholders are involved. Regardless of project size, distance or team composition, coordination and communication are key to a project’s success.

How does this relate to programming? We know that projects can be different. Smaller, larger, simple or tightly complex. Regardless of the size or type of a project, both coordination and communication are of great importance. I communicate with the client, with team members, and with external companies. I should provide reliable and legible information for every person participating in the project. It is important to achieve the set goal together.

After the game-winning move

When an Agile sprint ends, or the project itself has come to a close, the game really isn’t over. I’ve done my job, sure. But like any professional game, reflecting and analyzing your actions is the best way to improve for the next game (or project).

Only the one does not make mistakes, who does nothing

-Napoléon Bonaparte

Which moments were difficult? How did I react to the pressure? Have I done the best I can? What can I improve? What should I work on?I can ask myself such questions after the game as well as after the finished project. It is important to look at my abilities objectively and to approach problems constructively. In both cases, in programming as well as in chess, I can draw conclusions and analyze the moves I have made in order to be even better in the next match.