How to win a Hackathon, Part 4: Bring your A-Team and don’t forget the designer
1 Comment

Note: This article is part of the How to win a Hackathon series.

You might choose to assemble a team before picking an idea, and that’s fine. The order isn’t important, but assembling a solid team is. I’ve had the blessing of working with my best friend since childhood, Steven Pothoven, on both of the Rumbles, as well as an excellent designer and all around great guy, Josh Hemsley.

When I first approached Steve with the idea of competing in the Rumble, I told him that we would begin planning and proceed with the goal to do it, but, that if I was unable to find a great designer to make the site look professional I would drop out and not compete. I simply would not do it without a great designer.

I spent several months trying to find one, even attending the first Front End Design Conference in Tampa Bay. I can’t remember how I ended up coming across Josh Hemsley, but am so thankful I did. We chatted online. I pitched him the idea and challenge and thankfully he accepted. With him on board, and Steve’s excellent Linux and development experience I knew we could attempt to accomplish a lot during those 48 hours.

For the Rails Rumble, the team can be up to four members, so I rounded out the team with Linda Olson, who served as tester, writer, and even produced a video for the app.

Our second time around it was again Steve and Josh on the team, but the fourth member was Sean Farrell because we needed an illustrator to knock out as many badges for Commendable Kids as possible. He produced 80 incredible looking badges.

One of the keys in putting together your team is finding complimentary skills. If you are great at Rails but not so good at setting up a Linux server, then be sure to add someone who can bring that experience and skill. If you are a back end developer without front end experience, find a front end developer to add to the team. Ideally, you’ll each bring a certain expertise to the team that you can focus on during the hackathon.

I’ve heard some pretty awful horror stories of poorly chosen team members, from members that walked out in the middle of the competition and never returned to members who were so poor or new in skill that they were more of a liability than an asset.

The biggest decision is whether winning or participating is your top priority. If you only want to do it for the fun, then you may simply pick the people you would have the most fun with. If you hope to make a strong showing, be sure you surround yourself with sufficient talent. Hopefully, you’ll be as fortunate as I was, to have both. You’ll be spending 48 hours with the team, so be sure you can stand them!

How to win a Hackathon, Part 3: What’s in a name?
1 Comment

Note: This article is part of the How to win a Hackathon series.

For me, this is one of the hardest parts of the entire application development process. I have a list of ideas I’m passionate about that’s so long, I could never hope to make a dent in it, but naming each one…that’s the challenge for me.

The best advice I can give here is to not let it hold you up. Envision the idea, assemble your team, discuss the vision together over coffee, the golf course or cigars (my personal preference) and then start planning it. Let the concept sink in, and as it matures during planning, something may come to you.

Go to the Rails Rumble archives and read through the past entries and see if anything comes to you and see what you can learn from those names.

I had a few sleepless nights trying to come up with PeepNote and Commendable Kids. The challenge of course, was not only naming them, but getting a domain name that is available. There’s no requirement for a hackathon that you have your own domain name. You could host it at, for example, but I think part of the overall first impression and experience for the first time visitor is seeing a professional domain name that matches the name of the site.

One final note. As hard as it is to come up with a name, don’t be afraid to hold out for a great one, and even throw away a good name for an even better one. Before I came up with PeepNote I had firmly settled on, and purchased, I was sold on it at the time, but as the concept developed, I wanted to provide for a future where the service went beyond Twitter. PeepNote came to me during a brainstorming session and I switched at the last minute (about a week before the hackathon started). Thankfully I was open to the change, and I think PeepNote ended up being stronger.

How to win a Hackathon, Part 2: What’s the big idea?
1 Comment

Note: This article is part of the How to win a Hackathon series.

Though it all starts with an idea, keep in mind it doesn’t end there. While we all want to come up with the next most innovative and original concept, remember that the past winners of Hackathons such as the Rails Rumble, have included an app that helps you keep track of your favorite beers, and another that lets you create links to all your other online sites, even though and hundred other such services already existed.

When it comes to the idea for a hackathon, the most important element is that it be a concept that is easily and quickly understood. While judges will spend the time looking over the site trying to understand it, the average voter won’t. They will click on each site in the competition, look over the home page and then proceed to the next. Most won’t even sign up unless it specifically appeals to them.

I’ve seen apps finish in the top ten that didn’t even work. That’s not good, but, it shows the importance of the simplicity of the idea. As a rule of thumb, the first time visitor should be able to readily identify your concept in under 10 seconds. I believe first impression is one of the main reasons why apps finish strong in a Rumble.

While the app doesn’t have to be the next big solution, it does have to promise value to those who will be judging and voting in the hackathon. It’s very important when selecting an idea for a hackathon to understand the target audience. Again, I believe this is why the apps that have finished in the top three each year, have done so well.

There are exceptions of course, and my entry in the 2010 Rails Rumble is a great example. Going in, I had two ideas to choose between. One was a service specifically targeted at developers (the majority of those judging and voting) and the other was I went with my heart and decided to accept that we’d not appeal to a good percentage. Thankfully, we still finished strong, and even those without kids could appreciate the goal of the site.

In the end, you and your team will have to carefully weigh the passion for an idea with it’s appeal to the target audience in making your decision, and then be sure that you clearly state the goal of the application on the home page and then fulfill the expectations you set.

How to win a Hackathon, Part 1: Why you should NOT compete in a hackathon
1 Comment

This article is part of the How to win a Hackathon series.

Let’s take a look at the reasons for participating by looking at it from the opposite direction.

You are so good already, you couldn’t handle being better.

Competing in a hackathon, win or lose, is guaranteed to improve your skills. Whether you are a designer or a developer, the challenges from trying to do so much in such little time are often very different from what we experience in our daily work. The parameters are different. The goals are different.

It’s also a great opportunity to try some of those strategies or techniques that you’ve been meaning to, but constraints at your current work project are such that you don’t have the opportunity to use and try them.

It’s fine to have as your goal to win the hackathon. I did. But, even if you don’t think you have much chance to win, maybe because you haven’t had much experience, haven’t written much code or designed many sites yet, you should still compete. Compete for the benefits that come with trying. Compete to push yourself. Compete because trying and failing teaches us more about ourselves than winning does. In the end, if you try, you win, even when it’s not your name on the trophy.

You’d rather no one knows your capabilities.

Competing and participating in a hackathon will provide you with another piece to your portfolio. Many designers and developers work for companies where they can’t show their work because it’s protected by NDA or other legal restrictions, or simply because the work being done is internal. A hackathon entry can be a fantastic addition to your portfolio because it was all you, and is free for you to share with whomever you choose, including the source code.

Employers like to see that prospective employees have a passion for what they do. They also like to see that you’re willing to continuing the learning process outside the job, even when you aren’t getting paid.

I’ve had many of my client inquiries specifically mention the two Rumble projects when contacting me. I would even say, my two entries have brought more client work than other client projects I’ve been paid to do that are listed on my portfolio.

Whether you are a contractor, freelancer, agency, or full time employee, participating in a hackathon offers you the opportunity to show your community and industry that you deserver a close look during the hiring process.

You love your job so much, you don’t want to waste time doing anything else.

Even when we have a job we love, it can become a grind. We have deadlines, we have to get paid, we have to please the client or boss. We always have concessions to make, we always have people to please, even in a hackathon, but in our daily jobs those often become the driving factors. As well, any time when you do the same thing over and over again, with the same people, it can become mundane. We get into ruts and lose our creativity and ability to see outside the box. Our passion wanes.

A hackathon offers the chance to briefly put all that aside and focus on something new and fresh. The experience can help energize our daily projects as well. It’s a distraction from the normal, and a healthy one.

You have no need for a creative outlet.

Most of us have had ideas when working for a full time job or for a client that just weren’t listened to. We thought we had a great idea, but it was brushed aside, maybe to keep focus on the current project or maybe because of close-mindedness. With a hackathon, it’s your opportunity to let the flood gates open. Be creative. Think outside the box. The only constraints is the time limit and your imagination. Use your creativity, or you might just lose it.

You only live once, why not let it slide by?

Competing in a hackathon can be a great confidence builder. It allows you to step outside your comfort zone and push yourself to new limits. The challenge alone will improve you and when it’s over, you’ll always know that you and your team did it. You risked failure. You stepped up to the plate and took a swing. You’ll never regret that. Not nearly as much as staying silent on the sideline always wondering, what if?

You have no friends you’d like to spend 48 hours with.

A hackathon is an opportunity to work with your friends and new peers, that perhaps you’ve always wanted to be able to work with. Who doesn’t want to spend 48 hours in a small room with awesome people working toward the same goal! It’s an experience for sure, and if you approach it with the right attitude, you can learn a lot from the other members of your team, and they from you.

You are afraid it will be so successful you’ll be stuck reaping the rewards long after the hackathon is over.

Let’s face it. Sometimes we are afraid of success more than failure. We aren’t sure we’ll know how to handle it, or, that when it comes it won’t look quite the way we’d hoped. But ultimately, the real success is the fact that you attempted it. It’s going through the experience and coming out the other side that matters most.

A hackathon can also be a great opportunity to finally launch that startup you’ve wanted to get going. The competition itself gives you a deadline to work toward and can be a great motivator to finally start working on your dream. Or, it might simply be an opportunity to create that fun app you’ve been talking about over lunch for years.

Maybe nothing but the experience comes from it, or maybe you get covered on Mashable or TechCrunch, turn it into a real business, or even get purchased by Google. You never know what the opportunities can be until you give it a shot.

You simply don’t like having fun

More than any other reason, participating in a hackathon is a ton of fun. I’ve had such a great time with the two Rumbles. They are some great memories I’ll cherish forever. It’s an unusual opportunity and one you won’t regret. Just be sure, through all the planning, and maybe even the stress of getting the server set up, fixing that bug that’s driving you crazy on two hours of sleep, and all the other headaches that might come…remember more than all of that, to have fun. Enjoy your time and you’ll reap the benefits of it for a long time after.

Rails Rumble

The Rails Rumble is a great hackathon to participate in if you are a designer or a Rails developer. Registration starts October 1st. If you decide to compete, let me know. I’ll be helping judge this year and will make sure I take a look at your application.

Interested in hearing more about competing in a hackathon? I’m speaking tonight at the Tampa Ruby Brigade on How to Win a Hackathon.

How to Win a Hackathon

In the past two years I’ve had the awesome opportunity to compete in the Rails Rumble with a fantastic team and finish in the top 8 both years. In 2010, with our entry, we finished first in the U.S., were named a TechCrunch Top 5, a runner up from Chargify for most likely to monetize, won the appearance category, and finished fourth in the world out of 180 teams. The year before, with our entry, we finished 8th out of 237 teams worldwide, and were named by Mashable as one of the “11 New Apps We Love”. Both years were a great experiences I will cherish forever and I highly recommend it to all web builders as a way to strengthen and expand your skills.

This year I helped organize and judge the First Annual Tampa Mayor’s Hackathon, which was a lot of fun to be a part of as well.

For this year’s Rumble, I’ve decided not to compete, but instead will participate as one of the judges. Because I’m not competing, I want to help you compete by sharing my experiences and lessons learned.

Beginning tomorrow, I will publish an article every few days with tips on How to Win a Hackathon. I’ll also be speaking in Tampa on the topic at the Tampa Ruby Brigade meetup on Thursday, Sept 20th, if you are in the area and would like to attend.

I plan to cover topics such as picking an idea, assembling your team, planning your deliverable, team communication, promoting and marketing your entry, handling the hackathon hours, and more.

Hopefully you’ll find some helpful tips from my experiences and if you do, that will make my time competing in them even more worthwhile.

Here are the other articles in the series:

  1. Why you should not compete in a hackathon
  2. What’s the big idea?
  3. What’s in a name?
  4. Bring your A-Team and don’t forget the designer
  5. Communicating and collaborating effectively
  6. Know What The Judges Are Looking For
  7. Plan to succeed
  8. Don’t forget your health
  9. Everything else you need to know


Warning: Invalid argument supplied for foreach() in /srv/users/serverpilot/apps/brianburridge/public/wp-includes/script-loader.php on line 2678