Stuck at 2kyu on KGS for two years, I've set the game aside temporarily, until my life situation is such that I can immerse myself in serious study. Love the game - got half a shelf of books including Invincible.
There's a saying, "Go is life". Learning the game will tell you an incredible amount about yourself, about determinism and chance and skill, about depth and limits and building knowledge and passing on knowledge.
For a software person there is a lot to learn about complexity and patterns. There are deep lessons about not fooling yourself, about the idea that a strategy for success emerges in surprising ways from ridiculously simple rules and facts of the underlying material.
There isn't much of a gap between Go's simple rules (alternating play, capture, ko) and software's fundamental elements (sequence, iteration, choice) in terms of simplicity, and likewise these simple rules combine to yield complexities that challenge the best human minds.
Hurdling the kyu wall, for me, required a leap of insight into understanding how to use thickness for attacking. The basic idea you probably already understand: when you have a wall (or otherwise fortified position), drive your opponent's weak forces into that area. As you do so you will get another wall. If this wall faces your own position, great! If it faces an enemy position, a wall gives you the opportunity to invade or reduce the op-position.
Go beautifully combines strategy and tactics. In what other board games can you take a strategy like, "Besiege Wei To Rescue Zhao" and implement it, tactically, in various ways?
I had a conversation with a project manager. He said that we should zip the development source files over to the test machine. I suggested that the test machine should be outfitted with the repository client (CVS) because it would be simpler solution, technically. How the goal is accomplished is not nearly as important as the goal itself. Both zipping the source and executing a "cvs update" solve the problem. And both are tactical ways of solving the strategic problem: test the latest development version in an isolated environment that is similar to production.
In "Besiege Wei To Rescue Zhao" the strategic concept is to parry an attack on your forces by attacking a weak (yet slightly more valuable) enemy force. I like to think of it as the Three Kingdoms problem. Kingdom A and B are friends, but not Kingdom C. When Kingdom C attacks Kingdom B, Kingdom A can rescue B in two ways: running to B's defense or by counter-attacking Kingdom C. Counter-attacking is usually best, to avoid the least amount of bloodshed. After you've attacked a weak opponent group, you've managed to create a stronger position that you can leverage to support the group that was being assailed.
Other elements that Go and programming have in common: intuition, aesthetics, and recursion.
There's a saying, "Go is life". Learning the game will tell you an incredible amount about yourself, about determinism and chance and skill, about depth and limits and building knowledge and passing on knowledge.
For a software person there is a lot to learn about complexity and patterns. There are deep lessons about not fooling yourself, about the idea that a strategy for success emerges in surprising ways from ridiculously simple rules and facts of the underlying material.
There isn't much of a gap between Go's simple rules (alternating play, capture, ko) and software's fundamental elements (sequence, iteration, choice) in terms of simplicity, and likewise these simple rules combine to yield complexities that challenge the best human minds.