Riding into the Danger Zone: Virtual Hackathons for Virtual Teams
Five minutes left on the clock.
There’s an application error when loading the homepage.
You keep your cool while your teammate rushes to squash the bug before time runs out. If this isn’t fixed, your team’s chances of winning drop to zero. You gave this project everything you’ve got — blood, sweat, and tears fueled by pizza and energy drinks. Two back-to-back all-nighters. That can of Red Bull you chugged earlier to offset sleep has you pacing back and forth, eyes locked on the countdown timer. You really only have 2 minutes left if you include the time it takes to deploy your app to Heroku.
This is Ruby Rampage 2016, a virtual hackathon where hundreds of teams face off to build amazing web apps in 48 hours.
Last weekend I had the privilege of building an app with some fine gentlemen on the TaxJar team: Jason, Alec, and Matt. They also happen to be solid Ruby developers. We set out to address a simple problem: Keeping track of hundreds of online services that we depend on everyday both at TaxJar and in our personal lives. Good timing, too. Dyn experienced a massive DDoS attack on Friday bringing down thousands of popular services such as Twitter and GitHub.
The idea hatched a couple weeks ago when I was trying to jump on to Xbox Live with my girlfriend. We both realized it was a hassle to find the status page and having to constantly refresh it to see when we could connect to our favorite game. She deserves most of the credit.
Choosing a hackathon idea is similar to choosing a startup idea. You find a problem (preferably your own) and solve it the best way you know how by asking yourself or talking to others. The nice thing is that you don’t have to take it too seriously by worrying about competition, product/market fit, and revenue models. You’re in a safe environment to learn and fail. Want to hack on that microblogging platform you’ve been musing about for awhile? Curious to play with the latest flavor-of-the-month frontend framework like Vue.js or Polymer? This is where it’s done.
Mighty Wingin’ It
Going into this, we didn’t spend much time planning beyond the initial idea. First (obvious) lesson learned: Lack of planning can cost you time. We swapped around several APIs and gems throughout the weekend to handle authentication and scraping images. If we spent a couple hours planning out the system architecture and services we were going to use, we’d save an equal amount of time over the weekend while building things. Ditto for database schema and user interface sketches.
Friday morning we tried to decide on a name. Smoke Signal. Beacon. Flare. StatusMonitor. Hmm… too many syllables. Something in front of “flare” like BitFlare because every generic word for a domain in English is taken. All the domains are taken. Even with the .io TLD. Bummer. Choosing a good name is more difficult than coming up with an idea.
Again, adopt the hackathon mantra of “Don’t take things too seriously.” Focus on shipping and writing code.
We decided on Danger Zone:
To increase the fun we impersonated our favorite Top Gun characters via Git commits:
And I’m now the proud owner of https://dangerz.one. Well done. Let’s do this 👊🏻
Playing with the Boys
For many developers, one of life’s simple joys is building cool things and sharing them with the world. Hackathons are an opportunity to remind yourself why you’re in this industry. Why spend your entire weekend building a web application for free? You already know why.
Charlie: “You’re not going to be happy unless you’re going Mach 2 with your hair on fire.”
Fifteen minutes before the competition started, we jumped on Google Hangouts and our Ruby Rampage flow in Flowdock. That moment right before the hackathon starts is pretty special. You’ve got a million things to do and you’re about to go ham in a text editor. Snacks and drinks are at arm’s length for sustenance and survival. If you’re just getting off work, you might go with a beer instead to hit Ballmer Peak. Either way, you’re ready to rock and roll.
Goose: “It’s time for the big one.”
Iceman: “You up for this one, Maverick?”
Maverick: “Just a walk in the park, Kazansky.”
This wasn’t my first time doing a hackathon. Not even close. However, it was my first time doing a virtual hackathon with teammates across the United States. TaxJar is a completely remote company with developers in California, Washington, Oregon, Colorado, Missouri, and Kentucky. More states if you include the entire team.
With clearly defined roles and responsibilities, working together virtually is nearly the same as working side by side. Minus the high fives and shoulder rubs. When you have Hangouts for video/voice and Slack/Flowdock for sharing code, environment variables, and stack traces, there’s no need to be in the same room together for 48 hours. If you haven’t done it before and you’re interested in working remotely, it’s a good way to see if you can manage doing it long-term. That’s why at TaxJar we have a short trial for candidates to see if they can communicate and work effectively without the office environment.
Through the Fire
When you’re in a hackathon, you get into the zone frequently. Complete focus. No emails, no meetings, no distractions. Fleeting moments of time where coding just happens as you’re rocking along to your favorite tunes in Spotify. Lines upon lines endlessly flowing. The code might not always be beautiful, but it works.
Along the way, you’ll run into problems. Those are expected. Handling authentication for single page apps with an API has always been tricky. Early on I learned that the hard way (again) and decided to switch to Auth0. Huge time saver. We also discovered some status pages required JavaScript to render, such as Heroku Status. By no means deal breakers, but decision making constantly happens when you only have 48 hours. Priorities shift.
The hardest thing to do is take out features and scale things back. Most of the time your hackathon idea is too ambitious and it should be. Ambitious ideas are exciting. In our case, that meant dropping text and web push notifications. We also prepared a test notification feature for judging but there were a couple bugs to sort out near the end, so we dropped it. The user interface had animated tiles and snackbar notifications, but there was too much jank to leave it in with 2 hours to go.
If anything, hackathons are a great way to build minimum viable products. You’re quickly hacking and slashing to see what works and what doesn’t. The more often you do them, the more aware you become of scope creep and how to prioritize things effectively.
Maverick: “I feel the need …”
Goose: “… the need for speed!”
You Can Be My Wingman Anytime
It should go without saying, but camaraderie and teamwork is essential. Choose people you can trust and depend on to get the job done. Know what you’re signing up for and be open about your time commitments. Hackathons unlock the door to new people and opportunities. Over the years I’ve made some great friends and had the privilege of working with truly talented developers. It’s a wonderful team building activity. At TaxJar, it reaffirmed what I already know — we have an incredible team and the right people in place to take us to the next level. I couldn’t be more proud of what we accomplished together.
Ruby Rampage reminded me once again why I love hackathons. I’ll be doing them for the rest of my life. If it wasn’t for a hackathon, one of my startups would have never existed. Thousands of developers would have never participated in Static Showdown, a hackathon I helped organize. And I wouldn’t have created Danger Zone with my phenomenal team at TaxJar.
Thanks for bringing me back, Ruby Rampage organizers and sponsors.
It was a total rush.
