hack what?

I’m sure… or maybe not so sure (hence this post), that some of you have come across the term ”HackDay” and have sort of wondered what it’s all about. A rather broad term with multiple definitions depending on who you ask (@codinghorror, @jeanettehoran).

Originating from Altassian, it’s sometimes called a hackathon, sometimes prefixed with a descriptive noun (like music, history, or science). Sometimes capitalized, sometimes spelled with a space. They’re really all one and the same, some type of variation on a “HackDay”, well, at least in my book :).

In that case, what is my definition of a “HackDay”?

define it

Succinctly put (and trust me, that’s a hard task for me), a HackDay is an event or a goal where you take time for yourself to create something.

It could be a Javascript hack that you’ve been itching to try, or learning a new language (computer or linguistic). It could entail figuring out how to improve upon a presentation deck someone else crafted, or getting around to fixing those bugs and adding that new feature people have been asking for. You could decide to publish an article in order to explain something to users, or document an API to help developers. It’s pretty much anything you want it to be.

Should it be a day? A weekend? Done in stages? As a competition? These all become personal preferences and will be based on the target group demographic. Is it wrong to call it a “hackathon” but not do it at a venue? Or to call it a “HackDay” but offer more time than just a day? There’s no real right way.

In the way I’ve run them, the HackDay itself is the culmination day. It’s more like a checkpoint to say: “Here, we’ll pick a day. Show us what you can do by then”. Does that mean those who have more time may spend a few extra days creating? Sure. Will some people only literally have that day (or less) to go form nothing to completion? Absolutely. Does it mean you’re all done once the HackDay is over? Not if you want to take it further.

A HackDay is meant to be flexible but tailored to the needs of the organizers and participants alike.

drive it

So, why participate?

Because you can. Or rather, because you want to.

There are all sorts of motivations for participating. I’m not going to dive into this too deeply [yet], but suffice to say, running a good HackDay means understanding what people want. Figuring out what drives them to participate.

Contests, sponsorships, prizes, even fame and glory are great motivators, but in the end, those are really just superficial treats. As with anything people do, they do it to have some sort of satifaction from having participated. Stoke that inner flame and keep it well fed and happy, creative and energized, motivated and excited about participating.

With that in mind, the rest is all about driving the movement forward. Creating that wave of interest and getting more people involved. These types of things usually have a snowball effect, starting with a handful of dedicated supporters who see the value, and slowly acquiring converts. Once you get that going, it’s self driving and no amount of external influence is going to hinder this process.

And there will be external influences, both good and bad. There will undoubtedly be detractors, people who wont understand, people who will question why, even people who will actively try to stop it. But there will also be those that are in it hook, line and sinker. You just have to know it’s impossible to cater to everyone. That nothing is universal is just about the only universal truth.

So find the supporters, figure them out, feed them what they want and cater to their needs. Focus on creating an event for the people participating, not for the sponsors or an API or a model or [especially] a directive. Figure that out and you’ll have an event that’ll simple take on a life of its own.

deregulate it

I’m an idealist when it comes to HackDays.

I’m not too worried about venues or location logistics as I prefer a much more accessible online participation format. I’m not absolutely sold on needing sponsors or contests or formats or restricting what people can do or use. But I can totally understand how those things can help (as I’ve also leveraged them in the past). I’m far more interested in the spirit of a HackDay and what can motivate people to get in on it. That’s when the magic happens.

I know every HackDay is different, so there’s bound to be all sorts of rules and requirements, or at least suggestions that should be followed to make it a success. So here’s my set of “rules”.

The first rule of HackDay is:

1. Participate

Um, that’s it. What you do, how you do it, with whom, why, where, or even when is really completely up to you.

The only requirement is that you take it upon yourself to participate and try something. The phrase “it’s about the journey, not the destination” never rang so true as when you try out a HackDay.

The real goal is to learn something from the process, with the added bonus that you may actually complete something by the end of the HackDay. But completion is certianly not at all a requirement.

I have no idea where inspirations can come from, that’s why I like to encourage exploration and participation over the quest for results. Though, yeah, it is cool to be able to complete something :).

But, it’s even cooler to start something new and see where it goes.

organize it

Companies like Yahoo have their Open Hack Days where they invite developers to a campus for a weekend and see what happens. Others like IBM focus their HackDays internally, over a longer more gradual time period. One may allow the public to participate, creating a concentrated contest atmosphere. The other may focus internally on employees developing valuable IP to further the business. Both are different yet valid uses of the concept.

I’ve helped to organizine these types of HackDays at my previous place of employment since 2006. During my time there, we ran a total of 9 of these events, and we did it all grassroots style, from the bottom up, via pure community means and support. We saw good growth in participation, interest, and community over those years.

People participated because they wanted to participate. They created because they could. There was no mandate, and often times, no formal work time to participate. Folks took the initiative into their own hands to participate. They found spare time, after work time, and a few lucky ones asked and got blessed with formal time.

Some experimented simply for self satisfaction and learning. Others produced tools that benefitted their team or community, or implemented a long overdue website redesign. We saw feature enhancements and bug fixes, presentations and videos, even an internal radio station broadcasting during HackDay. Some even managed to produce really well done prototypes that caught the attention of management and went on to become products and enhancements to the company’s software line.

believe it

But it all started by simply setting a date.

We wanted to organize something that could intrinsically be beneficial to the participant, no matter what else happened. They didn’t need to feel like they had to complete something. There were no repercussions for not participating. No executive mandate or directive coercing them. No pressure to “win”. We wanted them, first and foremost, to enjoy their own participation, to enjoy the spirit of HackDay.

We did at times solicit other groups to sponsor prizes and contest for adhering to their set of guidelines, but the main event always remained free and clear of any requirements or expectations. All we offered was the chance at being voted as the winner in various categories. A fleeting chance at fame and glory.

It was enough to motivate people to participate. It was enough for people to anticipate the annual event.

Those familiar with the process were ready for the annual event. Groups took it upon themselves to organize their local faction by providing rooms, snacks and even local prizes. We seeded the idea, and let the word spread as orgnically as possible.

It grew because we believed it was the right thing to do. It grew because others believed in it as strongly as we did.

personalize it

I spent the last 6 years driving a company-internal HackDay initiative, and I left it in the good hands of people who understand the concept and hopefully can see it grow.

Now that my participation in that internal one is done, it’ll be interesting to see what may come of it out here. The realities are certainly different, the audience is immense and vast. But if there’s a way to figure out a nice niche to play in, it could indeed be something interesting to brew.

We’ll have to see… :)

Update: HackDay Micro Event on October 12th, 2012.

indeed… there is a certain itch waiting to be scratched