HN Explorer

Why don't we have Chess-Style Tactics for programming?

2 points by jinfiesto ↗ HN
I've returned to studying Chess extensively lately. One thing that's struck me is how easy it is to study Chess compared to programming.You can just solve "tactics" and improve pretty quickly. Here, I mean tactics in the broadest sense, including positional, opening and endgame "tactics".

Tactics are "positions" that have an optimal solution. Solving tactics builds a library of common "patterns" or "themes" for chess players to use in actual games. Anyways, I digress.

Besides studying tactics, Chess players go over games by masters. This part has an easy analogue in the programming world. Reading good code is obviously very instructive.

The analogue between tactics and programming seems easy. Programmers obviously encounter obvious patterns (design patterns for instance.) It seems it would have obvious pedagogical value to construct problems based on common themes and variations on those themes. Why hasn't anyone done this? I'm really tired of lame problems that I see cropping up in various "how to program" books and web sites around the web. Obviously programs take longer to construct than it does to solve a chess tactic, so I can understand why this approach might sometimes be unreasonable. I think books like SICP take a nice approach; writing out programs and leaving parts of the program blank for students to fill in. I think this strikes a nice balance between a problem that can be completed in a reasonable amount of time and a problem that has actual practical and pedagogical value.

I think the real advantage of this approach, "tactics" that is, is that it organizes "units of improvement" into smaller quanta. If I can solve a tactic and reinforce a tactic in five minutes, that means I can improve even if I only have five minutes here or there to spend improving. State of the art Programming-Pedagogy is decidedly not conducive to this approach.

I had considered that perhaps certain kinds of activities are just not suited to practice in small increments of time. I think this is false though, because I'm also an accomplished pianist. While it's not as clear cut as studying a chess tactic, I can usually work out something to do in a small amount of time that improves my ability. I've also fenced at the national level, and fencers can always do little drills to improve in small amounts.

I realize that things like code katas exist. However, it seems like most of the "practice ideas" programmers have are pretty lame. I find myself passively wishing that someone would do something about the frankly pathetic state of the art in programming pedagogy. I'd do it myself, but not being a master programmer, I wouldn't trust myself to not screw it up.

Anybody else have any ideas?

5 comments

[ 629 ms ] story [ 948 ms ] thread
tree_of_item
>I'd do it myself, but not being a master programmer, I wouldn't trust myself to not screw it up.

This thinking is why we don't have them. If you think the idea is worth something just do it: if the idea is good but you screw up a little, you've still done enough for other people to build on and improve.

CyberFonic
At first glance your idea seems to compelling. But then I realised that with chess, as with any other game, the desired outcome and the rules are fixed. In the case of a computer program the outcome is the correct implementation of the specification (requirements). Since that is different for every application, there is no series of steps that will lead to the "correct" solution.

Therein lies one of the core challenges of software engineering education. Teaching programming languages is easy. Teaching the skills required for analysis and design for real-world sized problems is difficult.

jinfiesto
This is true. Chess, as opposed to Computer programming is well understood. I traveled this line of thought also. I came to a different conclusion though. Music for instance, is as abstract as Programming is, but it's possible to create small "quanta" of improvement all the same. I refuse to believe that programming is such a unique endeavor that it can't be subjected to a similar approach.

Also, I don't think your analogy stands up totally well. Teaching the rules of chess is easy. Really good analysis requires years of practice. All the same, the state of chess pedagogy is fairly impressive. I wouldn't be surprised if someone out there has reached a low master class simply by studying tactics, openings, end games and strategy out of books (while playing very few games.)

CyberFonic
I'm a lousy chess player, so I'll stick to your comment about "small quanta". What you suggest is one of the features of Agile Programming and the art of refactoring. Taking your music theme further, many applications are like a symphony or even an opera; large, complex, lots of performers, large complext score, need for a conductor, etc.

Your chess inspired idea of programming is more like a jazz group - being clued in, playing off one another's riffs, improvising, etc without a score or conductor. Speaking of which, you might want to check out Live Coding (http://en.wikipedia.org/wiki/Live_coding).

ajuc
Chess have quick feedback loop. You do sth wrong and almost immadietly you know it was wrong.

Programming (getting the design just right) doesn't. You only feel the pain of bad design in big projects, after a few months passed.

Even the most complex games of chess would be finished in one day, most often in an hour or so.

Where programming has quick feedback loop, people learn very quickly - for example learning the syntax of programming language is easy, because when you do sth wrong, you know after a few minutes.