I want to tell you a story of the spontaneous emergence of a spectacular collaboration. Four people, previously unknown to each other, created something miraculous, something that none of them could have foreseen or created on their own. But first I need to set the scene.

Last year's Cody contest ran from November 10th to December 7th. It featured eleven tricky problems cooked up by our diabolical puzzlesmith (and professional MATLAB trainer), Matt Tearle.

In Cody, as you know, your job is to solve a MATLAB programming challenge. Find the nth Fibonacci number, that sort of thing. Solve the challenge and you're done. That's all you need to do. But...

... but you might find yourself yearning for more. You might be tempted to solve the problem again, but this time with less code. The Cody scoring metric is based on the size of the code in the solution (technically it measures the size of the parse tree). A lower score is a better score because it implies less code.

Practical people often point out that this is a terrible idea. We shouldn't be encouraging people to seek short code as its own reward. Short code is often cryptic, placing an unnecessary burden on readers and maintainers. It's a fair point: generally speaking, code golf IS a terrible idea. But I always make these two points in reply.

1. Regardless of scoring nonsense, Cody players regularly tell us they learn a lot by obsessing (and watching others obsess) over minimal answers. And...
2. It's just a game, and it's okay for games to be stupid as long as they're fun. Nobody's asking you to do the stupid thing in real life.

Now back to the contest. Of the suite of eleven contest problems assembled by Matt, the most dastardly by far is the last one, Problem 61069. The one called "Clueless." It is, in fact, so dastardly that it is emblazoned with a dire message. "Warning: This is a non-trivial programming problem." Caveat solutor!

Some people see such a message and recoil in fear. Not so the heroes of our contest! And so at last we come to the story of four competitors, four champions who became collaborators and friends. They are: Wang Zi-Xiang, Stefan Abendroth, Vasilis Bellos, and Dharmesh Jain (a.k.a. JKMSMKJ).

Here is a plot of all the solutions to Clueless. Passing solutions appear as green circles. The most recent arrivals are on the left. See that green slope on the left side? That's unusual. It's telling us that someone, or some group, was submitting incrementally better solutions one after another in a steady drumbeat. What's going on here?

What happened is that our four friends started having more fun working together than competing. They began to quote and compliment one another, chatting in the comments of subsequent entries. In the process they discovered breakthrough after breakthrough. Ultimately they shrank the code size from 583 to a final 152. That last winner contained a mere six lines of working code!

Here's an animation of the evolving code. On the left is a timeline that shows the score improving (decreasing) across two weeks. On the right is a "greeked" version of the code. Each player has their own color, and you can see the moment when they moved from working on their own code to working on a single improving branch.

Read what they have to say in the discussion page for the contest. Vasilis paints a good picture of what all the excitement was about.

Apart from all of the amazing vectorization, linear and logical indexing, operator precedence etc. tricks that Zi-Xiang mentioned in his incredible article, what truly made this spontaneous collaboration shine was that whenever we would get stuck, one of us would come up with a motivating new trick to move the solution forward, which in turn enabled other sections of the code to be further optimized. In the end, we managed to reduce the size of the solution down to just 152 - which to me seems unreal for this kind of problem! The final product is a thing of beauty, and I am truly amazed by your coding proficiency, insight and ingenuity.

Is it foolish to boil code down to its absolute minimum? In practical terms, maybe so. But consider: this "bad" objective is precisely what led to the good social outcome. Ironically, it shapes the social conditions for superheated optimization. A clean-code objective would quickly converge to something more conventional and far less entertaining. Cody's absurd and artificial objective opens a landscape of tricks, discoveries, and mischief that people WANT to talk about. Cody is a jam session, not a doc page. The constraints provide permission to play, and that play is generative and sweet.

I'll let Wang Zi-Xiang have the last word.

I could not have imagined that it would end in an only 5-line solution to the problem, compared to the initials hundred(s) of lines! ... Do you know the book "Beautiful code"? Maybe it deserves a chapter in it ^^. It's a book that also talks about breaking rules. Exploring the extremes also helps determining the right choices depending on the situation, that's what Cody games teach us.