Why 'The Divine Move'?

My first blog post, exciting times! Maybe a warning is in order - this may be a bit of a ramble but I need to get the ball rolling somehow. I wanted to explain why I chose to call a blog by an Android developer something weird like 'The Divine Move'. In a nutshell, I find playing Go and writing code put me into the same mind set unlike any other activities (apart from maybe university level Mathematics). I wanted to just briefly explore why this may be and steal a cool Go term in the process (im not the only one).

Go

I love Go. I came across Go first at Sussex Uni (where I studied CompSci, Music & Maths) where a student was writing a Go AI engine (not a trivial task). My first personal Android project was building a Go client called Goigo for the IGS/Pandanet servers and I had to learn the rules properly to be able to create the reference docs that I desperately needed to understand the servers telnet protocol. Through out this process I slowly got addicted to the game and whilst watching the Go-based anime Hikaru No Go (go overkill here maybe) I came across the concept of The Divine Move.

A divine move is a truly inspired and original move; one that is non-obvious and which balances strategy and tactics to turn a losing game into a winning game. A divine move is singular — they are of such rarity that a full time go player might be lucky to play a single such move in their lifetime.

This is quite an attractive idea when you have been slowly losing for 2 hours to think there may still be a way of turning the game round. Ive seen it happen a few times between beginners where one move drastically changes the outcome of the game but its really referring to this as the pro level I feel. But what relevance does this have to software development? Well unfortunately there is no such thing as 'The Divine Refactor' or changing one line of code to make a sucky codebase fantastic. It still is loosely related for me as the mindset of playing Go and writing code are very similar and associatively linked via the nature of intuition due to both being tasks that make heavy use of abstraction.

Intuition

What is intuition? According to Wikipedia

Intuition is the ability to acquire knowledge without inference and/or the use of reason.

and also

Intuition provides us with beliefs that we cannot justify in every case.

Below I will just point out how this relates to Go and Development specifically.

Go & Intuition

Go is a very complex and strategy rich game and has many different layers. The process of learning go means you can learn one playing style which works enough to get you to progress a few ranks and then play higher level players and subsequently increasing the complexity of your own playing style while internalizing your previous strategies (whilst as an added bonus also enabling the player to easily slip into a flow) state. It can then become very difficult at points to be able to logically reason why a given move feels intuitively the correct move to play, especially during the opening of a game and the clock is running. I guess one the reasons Go is so great as it calls for playing by intuition and also moments of pure reason and logic. This may be partly due to Go involving both the left and right hemispheres of the brain due to the use of logic and heavy pattern matching (more so than chess). Intuition feels very at home in this context.

Software Development

Even though the above suggestion of a process of learning and application could be used for many tasks, software development feels inherently similar to Go for me. Instead of a playing style its quite easy to see distinct steps in learning including syntax, coding style, project organisation, use of encapsulation and other OOP concepts, design patterns, architecture, project management styles etc. I used to find it an issue that sometimes I felt a potential design approach would lead me down a wrong path and I not be able to easily explain why. I have since learnt to trust these nudges in the generally right direction as they are a mix of rules that have long ago passed into the subconscious and ones that are still being formulated due to the associated patterns or situations only having being encountered a few times and maybe having slipped past the radar of the conscious analytical mind. Coming across the world of the notorious Nippon Chicken Sexers concretes this for me as reaching the state of pure intuition is their goal.

Even the best professional sexers can’t describe how they determine gender in the toughest, most ambiguous cases. Their art is inexplicable.

Im not saying that my goal is to only program via intuition but I find it valuable to recognise it is a valid approach in some circumstances.

Time limits

One crucial thing here is that intuition plays more of a role in time-limited situations, for example when playing Go against the clock (most games are time limited) or when working on a software project that has a tight deadline and the time you have to work on architecture and design is less than you would like (which is always!). It is definitely worth questioning your intuition when possible as it obviously can be incorrect due to the fact that some intuition is based upon subconscious knowledge gained from limited sources - but when time bound its a viable solution to 'go with the flow'. Edit: since my initial draft of this post I came across the related Recognition Primed Decision Model which explains this in better detail.

Conclusion

Obviously these things are only loosely linked by what I have stated above, but linked enough so I feel they fall into the same ballpark and justifies me using a cool phrase like 'The Divine Move' for my blog!