The other day, I posted about my Ruby Rampage entry, Teamview, a tool to help remote teams stay connected by allowing them to record and share short videos.

It's taken me almost a week since the winners were announced to get around to writing this, but holy crap, I won!

I've been competing in Ruby Rampage (formerly Rails Rumble), since the year it started, back in 2007. They skipped one year due to a change in management, and I skipped one year due to a particularly scary and much more complicated than usual round of eye surgeries for Narrow-Angle Glaucoma, but I have a long history in competing in this particular hackathon.

This is the 3rd time I've placed. In 2007, the very first year, I was fortunate enough to be on an amazing team that placed 3rd overall. In 2013, I won the best solo entry category. This year I won the top spot overall.

That's not to brag, just laying out the history. Truth be told, I owe a lot to this hackathon, possibly my career.

In the summer of 2007, I was pretty burned out on web development. I'd been doing PHP development since 1998 and I just wasn't having fun anymore. I'd heard about Ruby and looked into it a couple of times, but the idea of learning something new didn't really excite or interest me. In fact, for several months prior to the 2007 competition, I'd stopped doing web development entirely. I was instead making a modest income designing custom icons.

Then Jack Canty (who now works at Square), and Ryan Bates asked me to join them because they were looking for a designer.

It sounded fun. I didn't know Ruby, or Rails, but I wouldn't have to and Ryan assured me that what little bit I'd need to deal with inside of the ERB templates I'd be making, I'd easily understand, given my background.

Well, he was right. I did. The project was a lot of fun and we built a cool app that was pretty unique at the time. In fact, I was having so much fun that I started peeking into controllers and models and going beyond the view files to learn what was happening under the hood. And even though we were on that 48hr time crunch, Jack and Ryan both took the time to explain things to me and teach me what was happening.

In 2008, I'd dabbled more with Rails and knew more of what was going on, but was still very much a beginner. I teamed up with Ryan again and we built another app, and the learning process and the teaching continued.

Many people can say that they've learned a lot about Ruby on Rails and owe their start to Ryan, but I was lucky enough to learn from him and Jack first-hand. You can't ask for much better than that, and if it hadn't been for Ruby Rampage, it might never have happened.

With the exception of 2014, when I teamed up with my boss, podcasting co-host, and good friend, Jonathan Stark, I've competed solo. I think every year, I turned down an invite to join a team.

I wanted to compete as a solo entry to see how far I could push myself. A couple of my entries were duds; a weird Sinatra app that, looking back on it, wasn't designed or implemented nearly as well as I thought it was at the time, etc.

In 2013, when I hadn't come up with anything more exciting, I decided to do a little Rails rewrite of an invoicing app that had been a one-page Sinatra application. It wasn't fancy or unique, but it was a solid idea that worked well. I think that's why I won the solo category that year.

My 2015 solo entry was one of my favorites, but too heavily JavaScript oriented, and too light on the Ruby to really be a good contender and it understandably didn't do well in the rankings. This bummed me out at the time, because I really liked what I had built, but looking at it now, I can see why it probably just wasn't a great fit for this particular competition.

Still, given lest year's low performance, I really didn't go into this year's competition expecting to place, much less expecting to win. What I did have this year, though, was a solid idea that appealed to a lot of people. I took advantage of Bootstrap and a couple of free themes to make the design work easier so I could focus on functionality, and managed to build a rock-solid site for recording, capturing, and playing back video from the user's webcam. Then I prettied it up a little.

In that way, it reminds me of the 2013 entry - it's a good idea and it's solidly built. I made it easy to demo, and none of the exposed features break easily. I spent a lot of time planning out features that I knew I could get working well within that time frame and I stuck to that list.

Actually, our 2007 entry was much the same.

I've come to the conclusion that when building an app in 48hrs, if you want to do well, the number one thing you can do is make something that doesn't break. Secondary to that, make the UX clear, and make it look nice - but it doesn't have to look beautiful. Form should follow function.

Building a full-featured app in two days can't happen. Leave out what you don't need, add extras as you have time, once you know the stuff that's there already is solid.

Remove features you start on but don't finish, instead of leaving them in as unfinished features to show what you plan to do eventually (Teamview's Slack integration was fairly last-minute and could have been easily pulled if it hadn't worked). Less features and less error screens is better than more half-done features.

Anyway, that's my $0.02 on how to win a 48hr hackathon, which I guess I can say with some authority now? I don't know. I know a lot of great developers, and I don't feel like I'm near to being at the top of the pack. I'm humbled by them every day and I'm especially thankful to all the ones like Jack Canty and Ryan Bates to take the time and have the patience to share their knowledge and experience with others.

Kelli Shaver

Kelli is a full-stack developer with over 15 years of experience. She's also the lead developer at StickyAlbums and the co-host of the Terrifying Robot Dog Podcast.