another comment on another Reddit link...

I participated in the 2004 ICFP contest (in the Lightning Division only, as the 1-man "team" Busman Holiday Club), and enjoyed it, and did tolerably well, which might give me a reason to rationalize a fondness for programming contests:-) so take my opinions with a grain of salt.

While of course it is true that "fast programming isn't the same as good programming" as Vanier complains first, I doubt that that is all that big an issue. Playing Chess or Go under tournament conditions is not the same as really deeply understanding the game, but in practice there is a pretty strong correlation between the two.

Too my mind, a bigger issue is that small programs are not the same as big programs, and it's hard to address or even express big-program challenges in a short time. Much of what we do in programming follows from big-program difficulties which vanish in small programs. I think several things that Vanier complains about follow from this. For example, Vanier sounds quite justified in criticizing a programmer who refused to see the problems of coupling the UI with the program logic; his programming contest skills are unlikely to save him in large programming projects. Like Vanier, I find small problems to be unsatisfyingly far away from the ordinary challenges of programming, perhaps like having a contest in Chess pawn endgames instead of Chess. Still, small-problem skills are important, not so easy to learn, and not universally distributed even among graduates of good CS programs, so a contest based on them doesn't seem pointless. (Also... It seems a little odd that Vanier says he likes obfuscated C programs, for the programs are required to be truly tiny, and I haven't noticed programming-in-the-large skills on display in any that I looked at. And, for that matter, Vanier even says he likes the ICFP contest too. De gustibus et de programmibus nondisputandum est.:-)

Beyond the lack of programming-in-the-large, what I find most unsatisfying about programming contests is that they are naturally organized as surprise challenges. A surprise challenge format solves various practical problems, but it naturally ends up favoring contestants who happened to be particularly prepared for that challenge. It's a bit like having a "[generic] sports contest" where you don't reveal the rules until the day of the contest. If you think you are testing for pure athletic ability without people having drilled specialized skills, I think you are probably wrong. Your choice of ultimate-frisbee-like rules, badminton-like rules, rowing-like rules, or whatever will in practice tend to favor people who've done similar things in the past. For example, in the ICFP 2004 contest I likely got a significant benefit from having written several stripped-down assemblers when I worked as a programmer in high school; if instead I had taken the C++ job at Mentor instead of my FORTHalike/assembler real-time-control job, then in the ICFP contest I'd've had to make up more of the architecture of my software on the fly, and while it's not a terribly hard architectural problem, in the Lightning Division saving time is worth a lot. The winning Dunkosmiloolump entry also seemed to suggest a strong influence of the team having constructed similar solutions before. This isn't intended as a strong criticism of such contests or contestants --- I am still pretty pleased with myself that I did well, and I was still awed by the Dunkosmiloolump entry and thus the programmers behind it --- but it is a reason not to weight success in such a contest too heavily. It's probably important to be a reasonably good programmer-in-the-small to do well, but I don't think being the best such programmer in the contest is anywhere near a sufficient condition to win. Good luck coming in first in a contest like ICFP 2004 if your qualification is that you are stunningly good at programming --- in the field of numerical solutions to PDEs, or wireless telephony voice compression, or graphics rendering engines, or some other field where you have never happened to work on programs close to the ones required. Programming demigod (and DFW neighbor and fellow short person) John Carmack would likely stomp me harder in a problem soluble with preprocessed quadtrees than in a problem soluble with Metropolis Monte Carlo.

Finally, Vanier writes near his conclusion "Therefore, my advice to programmers who want to improve their skill: skip the programming competitions and start a free software/open source project of your own. If you do that, you have a chance of becoming a truly good programmer, not just a glorified code-grinder." Perhaps Vanier and I agree, then: I would not advise spending a lot of effort on programming contests either! My disagreements are with other points in his article, and with his original thesis that "programming competitions are (for the most part) a bad thing." Success in cooking contests might not be a particularly good measure of one's skills for the day to day challenges of feeding many people a variety of tasty food on a limited budget of time and money, but does that make cooking contests for the most part a bad thing?