Methods of improvement

A new hobby

I’ve recently picked up chess as a hobby. I played very casually growing up but hadn’t played in a long time. I was bored one day and figured that chess could be more thought-provoking than just another video game.

I’ve played for a few months now and have come to appreciate that the game is immensely complex. And I’m certainly still just seeing the tip of the iceberg. The game goes way beyond just knowing how the pieces move. Given the game’s complexity along with its huge player base, there are a ton of resources on how to improve. A lot of time can be spent just thinking about the right ways to improve, let alone time spent on improvement itself. It’s had me thinking about how methods of improvement differ between various pursuits beyond just chess.

In chess there are many clearly laid out paths to improvement; it’s not at all hard to figure out how to improve. It’s much harder to determine which path would be most beneficial for you at any given time. An example of a way to improve in chess is solving tactics puzzles. A tactics puzzle presents you with a chess board with the pieces laid out in a position you might find in a real game. Your goal is to find the move or the sequence of moves that are best from that position for either white or black.

The idea is that by solving many of these puzzles you will pick up on tactical patterns that you can recognize more consistently and quickly in real games that will help you win. This is one example of many methods of improvement in chess that focus on various individual aspects of the game. 

Thinking about improvement

The interesting thing about improvement in chess to me is that you can take a single aspect of the game (ex. see tactics above), work on that exclusively, and you will become measurably better at chess. But this approach doesn’t seem to apply as well in many other fields. An example that’s relevant to my life: software engineering. I completed my first software engineering internship this past summer, and will be starting my first full-time role in the field at the beginning of next year.

I’ve found that the path to becoming a “great” software engineer is more obscure than the path to becoming a great chess player. I put “great” in quotation marks in reference to the software engineer because it’s not even clear or agreed upon what makes a software engineer great. What I most often hear is that in this field nothing beats real world experience. The best way to improve as a software engineer is working at real companies, solving real problems. 

Connectedness

Improving as a software engineer it seems, similar to chess, is also largely about pattern recognition. You solve one problem, then you’re faced with a new problem that has some similarities to the last and you can solve the new one more effectively and efficiently. In this sense, a key goal in both chess and software engineering is improving your pattern recognition. And of course once you recognize a pattern, you have to know how to handle it.

Yet I think there is a discrepancy between improving in software engineering versus improving in chess. There appears to be a large degree of interconnectedness between the various skills and patterns required to complete a software ticket or project. For example, the ability to design a logical and effective architecture for a given system might not be as useful if you’re not also capable of implementing that architecture. And the process of implementing the architecture might have more influence than anything else on how you design systems in the future (ex. you discover holes in your original game plan that don’t present themselves at a surface level).

Maybe a critical area for improvement in software engineering is the ability to seamlessly connect various patterns and skills towards the goal of completing a task. And in this sense, the field doesn’t lend itself as well to drilling small parts of the process. In chess, drilling one or two move tactics that represent a small portion of an actual game can be massively beneficial. By contrast, in software engineering if you wrote for loops thousands of times as a drill, most of your peers would rightfully think you’re insane. 

An improvement spectrum

This all makes me think there must be a methods of improvement spectrum across various pursuits.

On one end, you have pursuits like chess where you can drill small parts of the game for improvement. And not only is this a valid way to improve, it’s actually the most agreed upon approach. You can become a great chess player spending a relatively smaller portion of your time actually playing games.

On the other end of the spectrum, you have pursuits like software engineering where the best way to improve is through real, fully-immersed experience. You can’t become a great software engineer by mainly focusing on contrived practice exercises that narrow down to a specific part of the process; your time is much better spent completing real projects from front to end.