Developer Relations, Hackathons, and the Rule of Don’t Do it All
A full week after my team caffeinated our way through the FordDev Conference hackathon and I am past the sinus infection the hack gave me. It was my fortune that said infection hit about an hour into the hack and I went from pumped about nailing a car assistant to worried I’d never make it through the backend. You can’t tell, but in this picture of my team I am passed out under the table, thanking whatever soul decided pitch black table cloths were couture.
The Death of Well Formed Code
I’m going to say what everyone already knows: Hackathons aren’t easy. I’d contend in many ways that they aren’t fun either. Those 12 to 36 hours are the height of stress for any programmer. Add to that the harrowing moment when you realize you have to take every best practice and throw them out the window to be trampled upon by a semi of bad intentions. It is very much about winning and not about good code.
I mention this because it irks me every time I coach, mentor, or judge a hackathon and the code is so buggy and malformed that I want to tear my hair out. For this reason alone, I think everyone in developer relations needs to do a hackathon. Everyone. It might even behoove the standard developer to give it a shot as well. I’ve judged dozens of hacks, scoffing at why they couldn’t manage to put up a simple server. The arrogant raised eyebrow? Yeah, that was me. Turns out part of the problem was I hadn’t told them where to look and made the information too complex to break down.
Scope Creeper
On the subject of giving up what you know, recognize the scope creep monster and scare it off! I had a team at TechCrunch that blissfully wanted to be mobile agnostic, a point I fully support. Loved, even. However, as I pointed out to them, Android has a wealth of libraries to do exactly what they wanted without having to worry about adapting a library for speech services. They chewed it over for a second and then wandered off to start working. The end result was an awesome web browser based video chat that they rocked on stage.
Take those usability desires and file them away for the next phase of development after the hack. You can’t and don’t want to do it all. You typically have a minute to ten to present and the judges can’t tell if your app is React or Android native unless you tell them. Consider this when advising hackers. I could show a team twenty services that would create a rocking app, but the reality is they may only get to show five features.
Start from the End
Before you even begin, start from the end. One teammate, Joshua Carr, had the brilliant idea of storyboarding exactly what our presentation was and then building the tech to fill it in. Start with the five minutes you have and then limit your actions to fill that need.
Team the Basics and Learn the Sponsors
My other pain point? The skill of the team itself. Typically, when I judge a hackathon the participants are getting their first look at an API. This past weekend I helped with the TechCrunch Hackathon where the IBM Watson team focused on just one API: Watson Conversation. Seems a little limiting right? But then I’ve had a month’s worth of work with that API. I could build a conversation bot in my sleep at this point with how much time I’ve spent debugging interactions with the service and I still don’t know it all. In fact, I pushed for Conversation with our Ford hackathon because it was so fresh in my mind.
The average developer entering a hack knows so little about the sponsors that they spend hours just working out connection strings. Avoid tackling non-sponsor services that you know nothing about. You don’t win prizes for wasting three hours debugging those.
So my point is to pick your team wisely. Come in with a team that is solid in the foundation points of your app and then dedicate their time to piecing together the sponsor APIs. We had a group of five developers and the entire back end team was comprised of veterans of Bluemix and Cloud Foundry. Every API from the Bluemix catalog was hacked together in the first six hours and then the rest of our time was dedicated to integration with the Ford TDK and working through versioning issues. What did this teach me? Well that our advocacy group was serious when they said they knew the APIs for one.
Want to get good with a new service or feature at your company? Go do a hackathon with it. Better yet, go do a hackathon with it when the development team is about to run maintenance. You learn more about the pains of a developer when debugging a version update at 2am.
Advocate the Basics
Finally, starter apps. I really can’t stress these enough and I’ve already written three since doing the Ford hackathon. We started from scratch and it was a veritable nightmare to get it all working properly. For TechCrunch, I stripped down an existing app and turned it into a starter for users wanting to integrate Node.js with Watson Conversation in a chat window. It’s super basic and overly documented to point out exactly how to connect and call the service. Advanced apps are fantastic, but I personally hate having to rip apart the code to figure out exactly what is going on.
As a hacker, come in with a basic starter application on your platform of choice and save yourself a world of headache. As an advocate/evangelist, snapshot that basic app you started with before building the use case. It’s great that you pulled in ten APIs, beefed up a database, and added login, but I have two hours to figure out what you did just to add only one of those APIs.
Now Go Do It
Go do a hackathon. Go lose sleep for days. Go bang your head against a table for hours because of undocumented endpoints and back versions. You can spend your entire developer relations career judging hackathons and never really understand the wealth of product management data streaming in under your nose. These users are hard pressed to learn and come up with the oddest bugs.
The entire experience has made me appreciate just how rough the ordeal is and just how exciting it is when the app simply runs for those five minutes with the judges.
