The Parallel between Chess and Programming

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. ↩︎

Read more...

On Markdown and how to fork a project

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.

Read more...
markdown

Marco Arment on Overcast

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.

Read more...
ios

Don’t be afraid to take risks

A quote from _why about experimenting and taking risks, before his disapparition.

I do not write tests for my code. I do not write very many comments. I change styles very frequently. And most of all, I shun the predominant styles of coding, because that would go against the very essence of experimentation. In short: all I do is muck around.

So, my way of measuring a great programmer is different from some prevailing thought on the subject. I would like to hear what Matz would say about this. You should ask him, seriously.

I admire programmers who take risks. They aren’t afraid to write dangerous or “crappy” code. If you worry too much about being clean and tidy, you can’t push the boundaries (I don’t think!). I also admire programmers who refuse to stick with one idea about the “way the world is.” These programmers ignore protocol and procedure. I really like Autrijus Tang because he embraces all languages and all procedures. There is no wrong way in his world.

Anyway, you say you want to become better. I mean that’s really all you need. You feel driven, so stick with it. I would also start writing short scripts to share with people on the Web. Little Ruby scripts or Rails programs or MouseHole scripts to show off. Twenty lines here and there, and soon people will be beating you up and you’ll be scrambling to build on those scripts and figure out your style and newer innovations and so on.

— _why

Read more...
risks _why