Off Topic: Why Programmers Should Play Go
It’s been a while since I did a translation, but this article was quite nostalgic for me, so I made a point of sharing it. It’s by Jon Dahl from the RailSpikes blog. Read my notes at the end. Here it is:
Go is an ancient strategy game with simple rules and a profound degree of complexity.
Software development is the art of managing complexity using a limited number of rules, structures, and patterns.
Programmers should play Go.
Go in 28 Words or Less
The beauty of Go is its combination of simplicity and complexity. On one hand, Go has only a few rules. Place the stones, don’t be completely surrounded, control the territory. Like chess, the mechanics can be learned in a few minutes, although Go has only a single type of “move” and only one edge case (the Ko rule). And like chess, a person can spend a lifetime discovering the game’s strategic and tactical layers.
While chess is quite complex and rich — it took a 30-node supercomputer to defeat the chess champion — no computer comes close to defeating even an amateur Go player. There are 361 positions on the Go board and, with two players, there are 2.08168199382×10170 valid positions. That’s a little more than a googol (yes, that’s how it’s spelled). Realistically, there are on the order of 10400 different ways a typical game can be played. And the number of possible moves roughly follows 361! (361 factorial), meaning that with just about 20 moves in, there are many googols of possible ways a game can continue. (As a curiosity, try calculating 361! on an online factorial calculator.)
Managing Complexity
So how can a person play Go, given the near-infinite complexity? At a tactical level, a player approaches Go like chess, thinking several moves ahead. But this only works in small spaces, like a tight battle in a small sector of the board. Beyond that, there are too many possibilities. So strategically, a player needs to think in patterns of shapes. These shapes provide shortcuts for managing Go’s complexity. As a non-master, I may have no idea how things will unfold in a sector of the board, but I may be able to recognize strong and weak stone patterns, vulnerable shapes, and effective formations.
But there’s more: Go has multiple levels of patterns. Beyond shapes, there are Go proverbs. They can be generalist: “Your opponent’s good move is your good move”; specific: “Don’t try to cut the one-point jump”; and meta: “Don’t follow proverbs blindly.” These proverbs are principles that help a player make good decisions. They’re less specific than shapes, and therefore provide guidance for whatever situations might arise on the Go board. Proverbs can conflict, and a player must determine when and how to apply them.
Finally, there is Joseki. Joseki are patterns of play considered equal for both sides. They typically occur in the corners of the board, typically at the beginning of the game. Interestingly, there is a proverb in Go that says “Learning joseki costs 2 stones,” which may mean that memorizing these patterns is not worthwhile. Instead, a player should learn from joseki by understanding what’s happening at each move.
Patterns in Go, Patterns in Software Design
Each of these Go patterns has, more or less, an analogue in programming.
Shapes in Go are like design patterns in software. While nothing prevents you from putting logic in your views, that shape is recognized as a weak form. Think of Gang-of-Four design patterns: the MVC, Adapter, and Factory patterns are recognized as useful in certain circumstances (and inappropriate in others). At a lower level, iteration and recursion have commonly recognized forms, as does database normalization vs. denormalization. Even if you can’t hold an entire program or algorithm in your head at once, recognizing standard shapes helps you understand what’s happening.
Go proverbs are like other forms of patterns in software: CapitalizedPrinciples (for lack of a better term) that became popular thanks to Extreme Programming. Think DontRepeatYourself, YouArentGonnaNeedIt, CollectiveCodeOwnership, DailyBuild, TestFirst. They’re not “forms” of code like a singleton class — they’re general principles that guide programming practice.
As joseki is about equal exchange between competing players, its programming parallel is a bit less clear. The closest comparison, in my mind, is programming exercises. This article, for example, suggests 9 exercises to help you become a better OO programmer, such as:
- use only one dot per line
- use only one level of indentation per method
- don’t use setters, getters, or properties
In a real program, you won’t follow these principles 100% of the time. But forcing yourself to write this way can be an eye-opening experience and can make you a better developer.
So What Can Go Actually Do for You?
Obviously these parallels are structural. Specifically, Go proverbs may not have direct relevance to software development. So can Go actually make you a better developer?
I think it can, and I’ll go further. I think Go can make you smarter. There is a lot of anecdotal evidence of this effect 1, 2, 3, for example, 4:
Indeed, all our minds can benefit from learning go, which has been officially credited with the ability to make you smarter. Research demonstrates that children who play go have the potential for great intelligence, as it stimulates both sides of the brain.
The mentioned research has no bibliography, unfortunately, so don’t take this kind of claim at face value.
But it makes a lot of sense: like chess, Go requires pattern recognition, a mix of strategic and tactical thinking, and comprehension of complex structures — although in Go the patterns are larger and far more complex. A mind trained to think this way will find it easier to attack similar problems in other domains.
Like software development.
Akita’s Notes
I’ve liked Go for a long time. As someone of Japanese descent it’s obvious I’d been exposed to Go, Shogi, and other oriental games. But, like any good westernized Japanese-Brazilian, I paid very little attention to them. Because of this, today I know no more than the basic rules and philosophies behind Go.
My interest was particularly renewed when I read the Hikaru no Go series, which is an entire story built around Go — one of my favorite manga series, by the way. I even bought a Go board and some Joseki books, but didn’t get very far. These days I just glance at online games on the IGS servers.
I don’t remember where I read this, but someone once made an interesting observation: chess is primarily a game of destruction. Go is essentially a game of conquest and expansion. That’s not literally true, but there are nuances in Go that remind me of it. And in the parallel to software development, design patterns aren’t just structures you copy and paste wherever you “think” they’re needed. A handful of design patterns doesn’t make good software.
What Jon was getting at makes a lot of sense. Just like a Go player, a software developer needs to be an artist. Playing is a creative activity. Strategy is a creative activity. Given a set of constraints, what’s the best path forward?
More than that: the only way to learn Go is by playing, hundreds of thousands of times over many, many years. Go professionals start developing around age 10 and move upward from there into old age. The only way to learn is by failing, failing, and failing again. Which brings us back to what Ryan said about Hurting Code.
Refactoring is something similar to this: conquest and expansion. Only a good developer truly understands the real reasons for refactoring. Nobody refactors because someone told them to, just as an artist doesn’t make a certain stroke because someone told them to. A good developer doesn’t put stock in acronyms, brands, and fashionable names. They put stock in the form and philosophy of what is being built.
There’s a lack of eastern philosophy in today’s programmers. Being a brick-stacker coder is easy: any grunt can do it. But reaching the 10th dan of programming is only for those who have put in the work in the art.