So what makes for a successful Hack Night? What is it I’m calling a Hack Night? Who is the target audience? How can you put together one of your own? Why would you want to have a hack night of your own? All questions I will answer in due time.

We’ve been running Hack Nights at Neo Columbus for about a year now and there have been things I’ve seen work well for our group and things that have been… eh.

Hack Night?

In it’s essence, it’s a pizza & BYOB night where people bring laptops and ideas.

Another take on hack nights is that they fill a void between user groups and conferences. User groups can be a lot of talking and technical talks without a lot of doing things. Conferences in my mind are more about cheerleading and morale boosting for developers and the hack night allows smaller groups of people to actively work on things in small groups.

It’s a great way to extend the reach of an existing community and to bring new people into the fold. Hands-on people don’t get much out of lectures and will get a chance to participate rather than consume and become creators themselves.

The intention when starting our hack nights was to have folks come up with great ideas and have folks around to help, but it’s turned into so much more. The learning expereiences people have shared have been very compelling stories.

Learning Experiences

Who should come and learn things? Everyone. Even the non-technical.

My last take on hack nights is that they fill yet another gap in training, the classroom vs. the real world. I’ve often thought of our hack nights as a Montessori Education for programmers.

When you run a classroom or a lab, it’s much like a traditional education. The assumption is that everyone is at the same level and we’re all starting from square one.

We’re not though. We’re not all the same age and at the same place from any sort of measurable metric. When we go to work, we’re not all of the same set of technical and life experiences, and that’s a good thing. Learning is a two way street. Teachers learn from students as much as students learn from teachers.

As someone who’s been in the field quite a while now, the benefits for me as a participant are massive. Technical people can have a habit of being focused on technical details. I’m reminded of when my six year old son asked my PhD Physics professor neighbor “Where does gravity come from?” — the professor sort of imploded. Thinking about these things can inject fresh perspective into my daily life as a programmer. Another benefit is that my own knowledge of topics is futher understood by explaining a topic, if only for the fact that I’ve recited it aloud as a learning method for myself.

The feedback we’ve gotten on mailing lists from people who are new to the field has been phenominal as far as how this sort of environment has impacted their personal growth. Fifteen minute conversations here and there have led to more people saying “I’ve never learned more than when at a hack night” than I can currently count.

Success Factors

Audience Size

Beleive it or not, some of the best feedback and most fun I’ve personally had are at the hack nights where attendance was low. People tend to get the most out of working together in small groups and tend to form little tribes anyway.

Is there an upper limit? Probably only limited by venue capacity. Standing room only hack nights can get a little chaotic, but some people thrive in that sort of atmosphere.

Keep it Unstructured

If we’re in Hacker Montessori school, the key is self direction when learning and working. Attempts to even have lightning talks have not gone well — in fact, folks were usually ignored.

Be Social

Programmers can be a little “heads down” sometimes when they’re into something. Even those with a lot of technical experience will often avoid bothering someone who looks busy. Someone who has their head down on a project might often not be able to switch gears to a conversation and perhaps not communicate well with someone who’s asking questions.

People also may not know each other well enough to have conversations with folks or to probe as to why they’re there. Other times people may know each other too well and and form cliques.

Getting everyone involved is as simple as asking “What are you working on?” to a random stranger. In the end, most people are excited to actually answer this question and you can spark some great conversation and learning experiences.

Diversity

The earliest of hack nights were an extension from our local Ruby Brigade. They were fun, but the same audience we always saw. We used a number of methods of reaching out, be it a reddit post or encouraging word of mouth. Bringing in more people from outside the fold worked out for everyone involved.

The early groups tended to all work on similar things, since we were all from the same user group. With a more diverse audience we’ve gone into topics like product development, languages outside our normal scopes, and tackling problems outside the domain of he average rubyist.

Scheduling

We’ve found three hours works well. People who want to stay less can come and go and filter in and out as they please. Any longer than three hours and folks can be a little worn out. Someone’s gotta clean up, right?

Setting a limit isn’t a bad thing, especially if people want to keep working or talking about things. It just means that they get to keep thinking, following up with each other and has people looking forward to next time.

Every other week has been a good fit with us as far as frequency. We’ve got lots of other local groups and events, and any more frequent and we’d not be able to have a consistent base of folks coming.

TL;DR

So the ingredients for a good hack night?

• Free Pizza
• Beverages
• Social people
• Unstructured Chaos
• Inviting lots of people from diverse backgrounds
• A consistent schedule