Chess as a Developer's Mentor
September 23rd, 2006
I have recently decided that to become a better developer, I need to learn how to play chess properly. This might sound eccentric, but let me explain.
I know how to play chess in the same way most of us learnt how to play the guitar as teens - we knew where to put our fingers and strum along, not really attempting to get to grips with the underlying nature of the instrument. In other words I know the names and legal moves of all the pieces, I know the middle of the board if often the most important part to dominate early in the game, and that’s about it.
I am a truly terrible chess player, because I lack the ability to remember techniques and tactics, and I don’t have the patience to understand how to play an over-arching strategy. I just move pieces around the board in a way that seems defensive or attacking depending on where my opponent is in their game.
If I’m honest with myself, quite a large amount of my development time can feel like this as well - I know how to code, I have a general idea of what is sane and what isn’t, but I lack the inner development to be able to see project as a strategic objective with each method and line of code another tactic in the battle.
Battle? Who’s the opponent? Again, here I need to be honest with myself, because whilst customers changing requirements, project managers not knowing what is going on and flaky code on the production servers can be an enemy to productive coding, I have to admit I am my own worst enemy. I know it’s easier not to write the tests, not to refactor my code, not to think if I could replace that twenty lines of code with three, not to go back and make sure that my tests covered every possible fubar the users could throw at it, not to comment code properly, etc.
I hope by encouraging a strategic and tactical perspective in my work, my code will get better. Chess is great at training the brain to think in ways I think will be useful to me in my work. Not convinced? Well after just a half hour of reading up on basic chess strategy and tactics, I’ve come to the following conclusions about how to improve my day-to-day developmet:
- My language and development tools are my ‘material advantage’ in chess terms. Ruby - my language of choice these days - allows me to express ideas more easily than other langagues, and in less code. Rails gives me a lot of stuff for free. Unix does too. These are all advantages my ‘opponent’ does not have - it is often easier to write good code than it is to write bad code.
- Automated testing can be my defence. They give me confidence that code is generally correct and allow me to move forward safe in the knowledge that as I progress I’ve got those pieces at the back there covered.
- Documentation is like a ‘fork’ - I can challenge my understanding now and deal with my lack of understanding 12 months from now by making sure code is commented properly.
- If I encourage myself to think three, four, five moves ahead and think about what my ‘opponent’ might do as counter-attack, that’s going to make me both a better chess player, but a better developer too. Right now I spend way too much time thinking about the problem in front of me and maybe the problem coming after that one.
This might feel like I’m stretching an analogy, but really I’m just trying to stretch my brain to thinking in new ways. If I’m able to develop my skills as a chess player, I can’t see the harm it would do to other areas of my life.

