The Parallel between Chess and Programming

November 20, 2014

I found this quote I wrote down some time ago from an interview with Victoria Livschitz, serial entrepreneur, a founder of Grid Dynamics and more recently, a technology start-up Qubell1.

Chess, like any other complex intellectual activity, involves a combination of knowledge, creative vision, and technique. Good chess players are able to acquire and store a lot of information – classic and trendy opening systems, standard endgame positions, novelties specific to their repertoire, and so forth. The creative vision of a master comes through his or her ability to discover patterns hidden in the position, then correctly interpret the competing (and often incomplete) patterns as either more or less relevant to their goals – and finally choose the best option. Also, it requires flawless technique to see the well-played game through to its logical conclusion, in the face of the creative resistance put up by a skilled opponent. This combination of knowledge, creativity, and technique is what has been attracting people to chess for over 4,000 years.

The parallel between chess and programming is rather obvious. Programming is also about knowledge, creativity, and technique. Good programmers must have a vast body of knowledge at their fingertips: the programming syntax of one or more languages, standard and special-purpose data structures, typical (as well as advanced) coding techniques, many kinds of libraries and APIs, a multitude of design patterns, and so on. Good programmers use their creative vision to recognize many patterns that may be relevant to the solution of the specific design problem at hand, and correctly choose the best approach. Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless."

(Victoria Livschitz)


  1. The interview was originally published on Sun Microsystems' page but thanks to Oracle it’s no longer there. ↩︎

On Markdown and how to fork a project

September 15, 2014

Markdown and its syntax specification were developed by John Gruber as a text-to-HTML conversion tool for webwriters. Over the years, it has been widely adopted by sites likes GitHub and StackExchange. Most programming languages have some kind of Markdown library available, always developed not by Gruber but by some third party.

The syntax for Markdown hasn’t been updated in years. Different implementations implement Markdown different… and output different HTML code for the same markdown. Jeff Atwood (Coding Horror), John MacFarlane and others have launched an initiative to work around the limits of the current Markdown specification. Jeff Atwood explains their motivations in his post standard flavored markdown.

The ‘problem’ is they chose to name their project Standard Markdown. After a mail from John Gruber stating that he found the name inappropiate, they renamed it to Common Markdown, which doesn’t seem adequate either.

I think standarizing Markdown is the correct thing to do. But if the initiative does not come from the project owner, the way to standarize an open source project is to fork it and change its name to whatever you want.

Marco Arment on Overcast

August 7, 2014

Just finished listening to Episode 43 of Debug, where Guy English and Rene Ritchie interview Marco Arment about the recent launch of Overcast, his podcasting app for iPhone.

The episode is great. It is around three hours long but worth the time if you are interested in iOS development and the app ecosystem. Marco explains some of the problems he found while implementing the app and how he solved them, and his product design decisions.

Link: Debug Episode 43.