FOB
Friends Of Bart
NavigationUser loginSyndicateCMS by Drupal |
Mike Vanier hates programming contests (me too)Mike Vanier has a nice blog entry that for some reason got Reddit exposure today. It's entitled Why I Hate Programming Competitions. I coach the ACM International Collegiate Programming Competition (ICPC) pretty often, and my criticisms of it are pretty much in line with Vanier's… In my humble opinion, though, the single worst feature of ICPC is something not even mentioned by Vanier: at most institutions teams are selected by having the individuals compete and grouping the top students as team #1, the second batch as team #2, etc. What a horrible lesson for students, on so many levels. No notion of a synergy or specialization improving team strength. Almost guaranteed animosity among the team members. Nearly sure-thing hotdogging by a "team" of non-team-players. Typically little or no opportunity for the team to learn to work together. In my long experience with ICPC, there is usually no teamwork at all among teams selected through individual competition; after a big initial fight each person takes one problem, solves it, and then fights again over the terminal. When a problem is solved, the individual moves on to the next one. If the team is a collection of individual superstars, this can be the most effective strategy at ICPC. Hopefully, no one believes it's terribly effective in real-life projects. I managed over a period of several years to improve my team's ICPC rankings consistently year-to-year, by emphasizing teamwork and teaching a good customized process. As the contest is currently constructed, though, they'll never win even our region: I have a bunch of good, solid, extremely bright software engineers to work with, not a bunch of programming savants riding mathematical trick ponies. I can live with that.
|
Wouldn't the ICFP reward
Wouldn't the ICFP reward teamwork a bit more, being one large problem instead of 6 or 7 small (and horribly defined) ones.
Also, the OOPSLA had a pair of related competitions, the first required a team to fully design a system, and the second competition had independent teams implement the design. Niether of these seem to reward lone hacking over team work.
ICFP: Agreed
Agreed on the ICFP as a better contest model. It is interesting looking at the winning strategies over the years that this contest has been run. The 24-hour lightning winners tend to be individuals (minimum overhead, maximum burnout!), but overall contest winners are often teams, sometimes distributed geographically to take maximum advantage of all 72-hours of the contest.
I also like that the ICFP contest encourages write-ups afterwards. It has become a great resource for comparing programming languages and techniques for problem solving in a variety paradigms.
(BTW, the 2006 contest is next weekend!)
ICFP mostly good
The ICFP is about as good as I've seen programming competitions get. The only problem I see with these "larger problem" kind of contests is that it's quite difficult to run them in a single day. While ICFP has its "lightning round", I'm not sure quite what it's measuring.
I guess at the end of the day I have a lot of sympathy with those who think the whole idea of programming as a competitive activity is kind of silly. I imagine there are sprint-style competitions in quilting or woodworking, but it seems to me that those would miss the point also. Programming is a craft as much as anything, and crafts aren't run against time clocks and scored pass/fail.
I dunno. It's all interesting.
Python Sprints
Another time-limited programming activity I've enjoyed is a Python Sprint. (http://c2.com/cgi/wiki?XpCodeSprint)
Instead of artificial problems, real open-source tasks can be chosen. (Though in my sprint, a toy problem was chosen since the focus was learning XP and Python itself.)
Instead of judges, you have coaches and seeded domain experts. Their jobs are to keep the process flowing smoothly and provide cross-training for the folks present, respectively.
This can of course be adapted to other languages and topics, though something interactive generally lets the time be used more efficiently.
http://wiki.python.org/moin/SprintIntroduction
Ian
Sprints are not contests (thank goodness)
Great thought! Yes, your point that a sprint is not a contest is well taken. I think sprints and other kinds of cooperative coding activities are awesome; maybe what we need to do is lobby the ACM to organize and sponsor some structured version of this.
Flying Bits... of Wood
They recently had a chainsaw sculpture contest 30 minutes north of here. Dozens of guys showed up. It's really amazing what they can do with a short log, a tiny chainsaw and 30 minutes.
Still, when they're done, it's not mistaken for Michelangelo's David. It looks good but rough - just what you'd expect from a half-hour with a chainsaw. That's what the published code from these contests looks like, too.
Nice datapoint
Presumably, nobody's suggesting following the rapid chainsaw sculptors' technique, when sculpting or chainsawing.
I think it might have been Vanier who pointed out that in some ways the coolest programming contest is the IOCCC . Clearly the IOCCC winners are uber-programmers and geniuses, and clearly you can learn a lot about C and C programming from the winning entries. Much like you can learn about chainsawing and sculpting from the winning chainsaw sculptures, I imagine.
IOCCC?!
"...clearly you can learn a lot about C and C programming from the winning entries."
Ugh... everything I've learned about C and cpp from reading those sources I'd rather forget. They are mostly about exploiting weird corners of the language and library (printf) specs to do actual work. That and C-golf that only a perl or TECO programmer might enjoy.
Ian
I'm not saying your code should *be* IOCCC
Everything I know about C Programming I learned from the IOCCC (with apologies to Robert Fulghum)
Teamwork in Hi-Tech
It's one of the biggest challenges, and these competitions are just one of many examples of how academia and industry can exhibit cluelessness about fostering teamwork. Yet teamwork when it succeeds is incredibly rewarding. In fact, lone successes are often forgotten by other departments, management itself, and marketing. And in my experience, one finds very few mid-level skilled people (e.g. good, but not good enough to always take time to see the big picture) who normally care about team work. Teamwork takes mental bandwidth, and the rewards are often delayed. Then again, I've rarely seen people appointed to architect positions who weren't exceptionally team-oriented. In other words, the unstated rule is that you probably won't make it to the top unless you do have excellent team skills.
One way we could improve these competitions is to actually seek programming challenges that require teamwork. The problems might need a bit more time to tackle (mythical man month issues come to mind), but if there were complementary tasks, perhaps it would lend itself to periods of isolated performance alternating with group effort. This is admittedly a rather thin example, but perhaps you could imagine a better one.
Post new comment