Clojure Cup Tips

So you’ve decided to enter the Clojure Cup. Awesome.

The organizers have asked me to write up some advice. I’ll give the opinionated nerd tips first:

That’s all tactical stuff, though. To take home the Clojure Cup, you’ll need to win the hearts and minds of the judges. I can’t speak for the others, but I can publicly declare my own judging criteria: my top entries will be those that explicitly define a problem and potential solutions in a broader context.

Don’t just write a library README that says, “Here’s Foo, it takes an X and returns a Y”. Provide some context: “I looked at Bar and Baz (which do X), but I needed something that also does Y and Z.” Consider drawing a picture to explain how things work at a high level. If you’ve actually thought about your problem, it should be easy to say: “Foo assumes that…” and “You shouldn’t use Foo if…”. Now, two days isn’t very much time—you might be tempted to skip the documentation and dive straight into the code. As a judge, I would rather see great design-level documentation with little-to-no code than running code with no context or documentation.

As for the context of Foo itself, that’s not for me to judge. I’d love to see anything:

Finally, take heed of this sentence from the rules:

You can, of course, work on the concept for your application before the competition starts, including paper and / or digital mockups of the user interface

Coding isn’t the hard part, it’s thinking; luckily, you’ve got the better part of a month. Good luck!