LiveCoda, Real-Time Coding Competition

Robert Shelton points out this "debrief" from ESCI LiveCoda 2006, a live programming competition. From the article: "On Wednesday the 24th of May at Loop Bar in Melbourne (Australia) fourteen teams of programmers gathered for the first ESCI LiveCoda real-time programming competition. Possibly the first performance based real-time programming competition. Before a packed night club with live music, each team had just ten minutes to write a program which could correct a corrupted image." (Here's a mirror of the LiveCoda site).

Comments

"How long, O Lord?"

[Black Parrot]

Why this fascination with speed?

When are people going to start programming contests where the award is given for something that's actually useful, such as fewest bugs, most readable, best re-use of existing code, etc?

Re:"How long, O Lord?"

[Ed Avis]

Competitions already are judged on 'fewest bugs'. Indeed, some competitions disqualify any entry that has any bugs found in testing. But all the other criteria you suggest are subjective. I think speed is a pretty good judge of programmer ability; someone who can hack up a correct program in 10 minutes stands a good chance of writing a correct, clear and maintainable program in an hour.

Re:"How long, O Lord?"

[Anonymous Coward]

Those are staggering generalizations. Your conclusions are nonsense. Programmers who are fast are generally, well, fast. To deduce that every single programmer who has the ability to pick up and solve a problem quickly becomes bored easily is ludicrous. I realize this may be painful to accept, but the fact that the world supports thousands of programmers more quick-witted and capable than you are does not mean that they are all short of attention and inferior in some way. Some programmers who solve a problem quickly will approach it with a unique solution in mind. Most simply solve the problem at hand. Additionally, strange doesn't always equate with bad. Haven't you ever heard the old adage "think outside the box"?

Again, not all programmers who are fast devalue commenting. Rather than mucking around adding their name and birthday to every source file and commenting "increment variable i by one", they're commenting complex trickery and the points that might actually confuse even a seasoned programmer. I don't know about you, but I'd rather have the latter.

Finally, that fourth generalization has no basis in reality. Just because someone can work fast doesn't mean they can't work with others. Just because someone can do drywall work in a house very quickly on average doesn't mean they can't work with dozens of other contracted workers on the job working at different paces towards the same finished product. It all depends on the person, not the speed of their programming.

These are problems. They aren't competing to create a stable architecture with which to build enterprise software upon. They're solving problems. Just because a programmer is competing in this speed contest does not "patently" make them a poor programmer in the big picture, nor does it make them incapable of teamwork, nor does it make them "strange". It sounds like you have some security issues about your own ability and are just taking it out on people who are talented enough to be competing in such a great and challenging speed contest.

Your troll is elaborate, though it "patently" is one.

Meh - TopCoder has had these for a while.

[JMZero]

Their design and development (and to some extent their marathon and multi-threading) competitions all allow much less restrictive timelines, and use very "real-world" problems (in fact, they sell the results of the design/development work). There's substantial prize support, and potential for royalties on the software you develop. They're evaluated by real people who look for bugs, run tests, and reward efficient, readable code.

But most people prefer competing in the algorithm competition (which are an hour and a half). I know I do - I'd much rather be done with the competition in a couple hours than spend a whole week stewing on it. I also do regular component development programming for a living - I don't feel the urge to go do more of that after work for less pay.

Re:Did the choice of language affect the results?

[Fahrenheit 450]

But for something like this, you're mainly limited by the contestants' familiarity with the problem domain.
With this particular competition (which looks to consist of reading in a simple image format, like PPM then applying a couple of simple transformations then writing the new file back out), the code isn't going to be too terribly different between most languages, and therefore the higher expressiveness of something like Python or OCaml wouldn't really get a chance to shine.

Re:This is what people actually believe?

[joebob2000]

The counter-generalization: The speedy ones are usually exceptionally smart, but their code is completely unmaintainable, no matter how much time they are given to write it, because the other 9/10ths don't understand the code enough to maintain it. Of course this is the fault of the 1 smart programmer. Why? because they are outnumbered 9 to 1. The exception? when the smart programmer becomes VP of engineering.

I know plenty of smart, fast programmers that write clear code and follow the rules. Sometimes the best ones will write something that most others have a hard time following, not because it is "sloppy", but because they are more talented. They also find and fix plenty of bugs that the other 9/10s made in their "maintainable" code. I have seen times where a super programmer correctly debugs a regular programmer's code in a design review sight unseen, just from the description. I have also seen regular programmers say "I checked it", or argue with a super programmer, until he gives up in and takes 10 minutes to find the bug and fix it himself.

What's my point? I don't have one, except maybe don't be a hater just because you can't hit the ball like Tiger Woods.