5 Great Lessons from the Hack for Western Mass

This past Saturday & Sunday, I participated in the Hack for Western Massachusetts — the first Hackathon I’ve ever done. It was a fantastic experience, and one I can’t wait to repeat.

Here are some of the key points I took away.

Update: Have the attention span of a squirrel? Want these in slide form for your own presentation? Get them at http://cris.lc/h4wma-5slides!

1. Questions Before Code

When you’re under a major time constraint, the impulse is to jump right in. Our team actually spent the first two hours of the day just discussing the challenge, identifying the different components, and figuring out how to break out the individual tasks. As a result, we were so productive after lunch that we finished all of our Saturday goals between 12:00 and 3:00 PM.

Lesson learned: Block off 2 hours at the start of the first day just for discussion and project planning. You’ll get way more than 2 hours back in productivity when you’re actually working on stuff later.

2. Know What You Need

Another benefit of starting with a discussion was that we could identify what we needed from our Community Partner early on in the day. That gave her as much time as possible to try and collect information she didn’t have at hand, or email her co-workers to get questions answered. We would have been in a lot more trouble if we had just gotten around to those questions late on Saturday or early on Sunday.

Lesson learned: Make a list of questions and information you need to have and split them into “Need to know now” and “Need to know later”. Then have at least one person start working on the “Need to know later” list as soon as possible, so you don’t get blocked later on.

3. Think Ahead

Remember that the Hackathon is just the beginning of the process for your Community Partner. Our project was pretty small, and based almost entirely on Google Forms and Google Spreadsheets — systems which Google has well-documented. Even so, we asked lots of questions about how it was going to be used in their office, and created a screencast covering the essential features for them to review (and to use to train new employees). It might take a somewhat-technical person to set up screencasting on a computer, but once it’s in place then just about anyone can help draft documentation.

If you’re building an entirely new application (e.g., in Django or Ruby) then this becomes even more important to consider. Ask yourselves, “After the Hackathon is over, will they remember how to use it? How do they train others to use it? If it breaks, what do they need to know to have someone fix it?”.  If the answers aren’t on the label, make sure you write them down somewhere that they can easily find later.

By the same token, make sure you help set your Community Partner’s expectations. Let them know whether or not you’re available to contact if it breaks. And be clear about how robust you consider your solution to be.

Lesson learned: Figure out whether you are offering ongoing support for the project after the hackathon is done. If not, then make sure your community partner knows that and has everything they need (including documentation) to manage it on their own.

4. Be Ready to Train

It’s not just your Community Partners that may need some training — be prepared to help educate your other team members, too. They may not be as familiar in a certain language as you are, or not familiar with programming at all. It can save a lot of time if you have links for some basic tutorials (e.g., on git) for them to review while you get started.

On the other hand, don’t try to make everyone into a coder if they don’t have (or want) those skills developed. There’s a lot of non-coding work that needs to go into a project — see if they can help tackle some of that. If you’re not sure what that work is, then see Lessons #1, #2, #3, and #5.

Lesson learned: Have some resources ready to help your other team members get up to speed. If someone’s expertise is in a non-technical domain, look for opportunities that match their skillset. There’s a lot of non-technical work to be done, too.

5. Prepare for the Presentation

In the grand scheme of things, the presentation feels a lot less important than producing something that your Community Partners can really use. It’s easy to get so wrapped-up in developing that you don’t even think about the presentation until five minutes before you have to go up.

Don’t let that happen.

Your presentation helps everyone understand the challenges your team faced and how you overcame them. It’s not (just) about the technology or platforms you used. It’s about reflecting on how far you came and what can be better next time. Even if your project didn’t turn out as well as you had hoped, there’s still probably something you can learn from — or that you can teach others based on it.

Without taking the time to reflect on what you faced and what you accomplished, you’re only getting 50% of the benefit the Hackathon offers you.

Lesson learned: Talk about the presentation in your group; briefly on Saturday, then for at least 15 minutes on Sunday. Agree on how many people should present, and have one person in charge of making the slides and coordinating everyone’s stories.

The best thing about civic hackathons is that your efforts continue to help the organization, long after all the volunteers go home.

Congratulations to all the organizers! I can’t wait to join again next year!

Learn something? Like something? Share this post!

Prefer your blog posts as PowerPoint? Get the (remixable, CC-licensed) slides!

Related posts

Leave a Reply