Rails Rumble Strategy Guide

Registration is now open for Rails Rumble, one of the biggest distributed programming competitions. In Rails Rumble, teams of one to four people work for 48 hours to build an application using Rails or another Rack-based web framework.

Registration runs from Oct 6-12, and the competition is Oct 18-19.

I’ve collected a few tips for people new to programming competitions, or those who just want to make the most of their Rails Rumble experience.

1) Have Fun

Yes, it is a “competition.” I’m competitive. I want to win. Here’s what I have to remind myself about in any programming competition: Winners mostly get internet bragging rights, so calm down. If you “play to win”, you’re only going to feel good if you rank highly. Everyone else is going to feel successful by flexing their skills and making a cool thing in 48 hours.

2) Read the Rules

You wouldn’t want to work all weekend on something that the judges won’t even look at, right?

3) Plan In Advance

You are not allowed to create any code or production assets before the competition. There are lots of things you CAN do before the competition:

  • Think up your app concept
  • Make paper or digital UI mockups (no “production-ready”/”ready to slice” assets allowed)
  • Plan your database & API schema
  • Create user stories without code or test cases in your project management software

If you want to get as far as possible with your app in 48 hours, pre-planning helps because you don’t have to do these tasks during the competition AND it reduces time-wasting confusion.

4) Put Together the Right Team

Previous successful Rumble teams have had diverse skills. You could put together a team of four Rails wizards and create a mess of Rails backend in 48 hours. However, UI/UX counts in judging, and helps “sell” your app to the judges, so it is smart to include someone with design skills.

Remember what I said about planning? Have someone on the team who can play project manager and keep everyone else on schedule. You probably don’t need a “full time” PM for the competition, but someone that can be a PM part of the time and write code the rest of the time would be a great asset.

Also, decide who will play “product manager” and make quick decisions about what the app will and will not do.

5) Use Open Source & Know Your Gems

Using open source is a no-brainer for productivity. Stand on the shoulders of giants. Resist falling into DIY rabbit holes: spending a lot of time on things other than the cool or unique features of your app.

Before the competition you should try out any unfamiliar gems that you plan on using. Build a minimal throwaway “test run” app using the key gems before the competition to get familiar with the APIs and pitfalls. You can’t reuse any of that code, but the experience will help you execute faster and smarter.

6) Sleep and Eat Well, Take Breaks, and Don’t Drink Too Much

Programming competitions give us a deadline and remind us of pulling all-nighters in college. There’s also the naive assumption that more hours awake = more code. That means there’s a temptation to try to stay up for all 48 hours of the Rumble. This is a bad idea. Sleep deprived coders produce little useful code. Most participants don’t get a full night of sleep, but at least try to get a few hours in each day.

Programming competitions tend to encourage bad nutrition because we favor convenience and lowest common denominator food (“everyone likes pizza”). Bad nutrition will make your mind foggy and your body sleepy. Plus, if you make yourself sick in the middle of the Rumble, you won’t be useful to your team.

Take breaks. Specifically, frequent, short breaks. Research shows that breaks reduce fatigue and increase total productivity.

Also, some people drink cases upon cases of beer during competition. This is another bad idea. Have fun (after all it is the weekend), but don’t get annihilated. Beyond the obvious effect on your code quality, drinking too much can make you hard to work with and make you sleepy and/or sick. If you want to drink, strive for moderation.

More Posts by Robert Prehn: