🚴 Speed coding

We ran a programming competition called Extreme Startup (kudos to Robert Chatley and Matt Wynne for inventing this back in 2011) on a recent Friday afternoon. It was a chance for us all to have a bit of fun, play around with different languages, and crush our (fr)enemies on the leaderboard!

⚔️ Sounds cool, what's the setup?

There was a central problem server that would send out a question to anyone who was connected every few seconds. To play the game, you had to write a server that could listen for those questions and respond with the correct answers. As the game progressed, new, more challenging questions would be introduced. Every time your server responded correctly you got points, and if it responded incorrectly you lost points.

🤓 Actually, that sounds like work... what makes it fun?

There were a few things that made this a great afternoon.

• Some non-engineering folks got to take part in the problem solving and see how coding happens in real time. They each paired up with an engineer and  took on the challenge as a team.
• Because you just had to respond to a web request, you could write your solutions in any language you like. So while many folks chose Ruby as a comfort language, a few participants wanted to see how coding under pressure felt in less familiar languages like Rust and Typescript.
• It was a social event. We all hung out in a zoom while the competition was running so we could commiserate (and heckle!). Afterwards, we shared and discussed lessons learned and different approaches folks came up with.
• There was a leaderboard. Need I say more?

🤩 Ok, you've convinced me. Can I do this myself?

Of course! It's pretty easy to get set up. They have a docker image available. We use Heroku, so we just spun up a free-tier dyno running the image. You could also run it locally and expose the server via a local tunnel.

This competition was originally designed to be run on a local network so that the challenge server could communicate with all the contestant's servers. Since we are a remote team, we had to make it work remotely. The simplest way of doing this was using a local tunnel (like ngrok, or cloudflare) to expose each contestant's local server to the wider internet.

We wanted to maximise the time spent playing rather than setting up - so we put together an explainer google doc and spun up a demo version of the challenge server so that players could get setup before the actual event.

🧐 Some final thoughts

A few things we learned on the day:

• Server uptime is really important.
• Observability and good logging is really important.
• Testing went out the window! As a team we are really into good testing and TDD, but there was not one test to be seen during the competition. In theory, using test as your feedback loop instead of the challenge server should have saved points. In practice, the overhead of writing extra testing code under extreme time constraints didn't seem worth while.
• The benefits of Rust (typing, strict error handling, etc) were not useful for quickly prototyping a solution under pressure. Dynamically typed, more permissive languages like Ruby had the edge there.