I’d like to talk to you today about hackathons. Specifically, a little bit of history, how you can participate, tips on having them in your local community and why I think they are needed. As always on this blog, these are my personal opinions and impressions, not my employer’s.

Feedback requested! I welcome all your comments - tweet at me. I’d like to expand these ideas in a follow-up blog post and incorporate it into my VMworld vBrownBag TechTalk, so I’m looking to improve and include more perspectives on this topic.

If you’ve been in the #vCommunity you’ve heard of the VMworld Hackathons. They started as a grassroots effort led by Alan Renouf and William Lam and thanks to their resounding success grew into a VMworld tradition. I think the first one was in 2016, meaning all of the Vegas VMworlds had one. It’s become so big and central to VMware’s developer advocacy efforts that it’s now part of the VMware Code program, run by Kripa Sitaraman and the VMware communities team led by Eric Nielsen. Kyle Ruddy is, in my opinion, the premiere vCommunity ambassador for the event. Bookmark this excellent blog post he did for 2018 if all of this is new to you; he included a lot of tips that I don’t touch on here.

Now, originally the term hackathon was pioneered by the OpenBSD hackers who wanted to get together to develop code faster and also get to see each other - this was back in June 1999. Since then there’s been lots of types of hackathons, and we have to state that the VMworld hackathons are very particular. In my opinion, the social aspect of the hackathon far outweighs the competition aspect. My own definition of VMworld Hackathons are is:

An opportunity for like minded individuals to come together during VMworld and explore and discuss an idea in code that would typically require of hours of focused work, while there’s food, beer, camaraderie and overall good fun.

What I loved most about them was that the events spoke to all our inner geeks. They were held at night after a full day of conference activity - the technologists who decided this was a better use of their time than all available parties and social gatherings came out in droves. They also made it a point from the start to include everyone and encourage participation no matter the skill level, and this set the bar at a friendly level. A glorious thing happened - those who showed up at the Hackathons came with an open attitude to discuss their ideas, experiences and share their time teaching and learning from others, and if they could win something, “cool”, but participating and growing new connections was already a win for everybody.

Again, because this is an important aspect: the VMworld hackathons have always had a competition element - if there wasn’t some pressure, it’s just free food and beer, and people would just talk and wouldn’t code. Because there is some pressure, people set out to form or join a team and have to talk to each other and set a goal and find out what each person can do. But the success for me, the prize everyone gets is the camaraderie, the quick knowledge transfer and the new friendships that are formed. They are phenomenal events and I recommend them to everyone that will listen to me.

I’ve attended all of the VMworld US ones. I was a spectator in the first one, a “pusher” for the Ansible team in the 2nd one, and a participant in the last one with my friend and vDocumentation code wizard Edgar Sanchez. Let me clarify what a “pusher” for the Ansible team means. I was a new VMware employee for 2017. Several of my customers were attending. Two of my Pittsburgh customers friends were attending VMworld for the first time, and they had showed an interest in doing vSphere tasks using Ansible. I told them that the best thing they could do was lead a hackathon team discussing exactly that, as it would attract like minded individuals. And so it was that Dave Kalaluhi and Carl Capozza became leaders of a Hackathon team called Something Cool, had a blast, got to know others who were also interested or even using Ansible already. Yes, I applied the old vBrownBag “voluntold” trick.

That night was specially important for Carl and me. On two fronts:

Here’s where we get to the meat of this blog post. Let me tell you about our Little Hacks and the lessons we’ve learned after hosting them for a year. There’s many! But here’s 15 to start:

  1. “It has to start somewhere, it has to start sometime, what better place than here? What better time than now?" - RATM knew what they were talking about. It just doesn’t happen by itself. You have to care enough that you want to do it yourself. Find at least one more partner that believes in this vision and both of you commit to doing it even if no one else shows up. I recommend starting monthly, 6pm so most people can come straight after work, on a weekday.
  2. Find a spot that can take a small group. Arguably the toughest thing. Worst case, some bar will allow you to use a room if your group has a dinner-like tab - this is how I found out the NYCBUG meets. Hopefully someone has access to a room with power, bathroom, AC and a TV/projector and internet. Ask at work, find someone in a university IT job, check out community spaces, etc. Don’t count on more than 10 people showing up the first few times, but be prepared in case you have that awesome problem.
  3. You need to find a way to communicate your event to your audience. In my world, a blog post makes it official, twitter is king to disseminate information, and we made a channel in the VMware Code Slack to keep everyone abreast as time passed. Very useful when the meeting lands on a holiday, for example, and the date has to be moved or cancelled. Your blog post should explain the why, how, who, when, where, and also “what should I bring/expect” like Carl did in his blog post.
  4. You may have low attendance the first few times. It takes a while to get regulars. Even friends that would like to attend have to balance wives, children, after school schedules, etc. Don’t be angry when someone can’t make it, just try to figure out what date of the week works best for most people, and see if changing things helps. There’s always the next one. Our first three times, it was only Carl and me, and we had a frigging blast!
  5. It’s easier to put a fixed date - 1st Monday of every month worked out for us - than having to decide on a different date each month. No matter how good you are, someone will miss the communication. Thanks to AJKuftic for that one.
  6. Assume there will not be a sponsor. This isn’t a company putting an event - it’s a bunch of nerds getting together to play. Tell people you as host will put some drinks or food, but it’s to be expected that this event will be BYOB and you will chip in for a pizza or something everyone agrees on for dinner. Bonus, people who like craft beers/wine/etc will bring to share and compare and that’s a lot of fun! Also, tell people to bring any gear they want to play with. Most of the time, all they need is their laptop, but I had a switch and a NUC with ESXi available for anything that was needed.
  7. Try to separate this from any work related thing, whether you are a vendor, partner or customer. The focus is on the act of learning and sharing. This is not where sales people should be trying to fish. Sure, sometimes win-win situations will arise, but that’s not the objective of a little hackathon.
  8. Once you get attendees, the first thing you have to do is introduce people and make sure everyone is comfortable. Ask them what they’re trying to achieve, what they work on day to day, what they geek out on. If you know someone else also has the interest in the same thing, make it a point to say it so they have something to start with
  9. Providing internet to a bunch of people isn’t easy all the time. I had spotty wifi where we had our meetings. Literally one of my first projects was configuring a raspberry pi to be an internet gateway through my hotspot - and this setup worked for quite a while xD
  10. Decide on a hashtag - make sure it’s not used by something else, like #hackathon. Send tweets before, during and after, and especially take pictures of what you are doing. At the very least, it will give others an idea of what your events are about. You can tag people whose code and ideas you are trying out. You may be able to have someone join remotely. Make sure you leave a record of all you did - it helps keep the momentum going and also makes points for you in the vCommunity! Here’s some examples of ours: 2017-09 2017-05 2017-10 2018-05 2018-06 2018-08 2018-09 2018-10 2018-11 2018-10 2019-01 2019-03 2019-06
  11. Don’t be afraid to present! If you have a TV or projector, presenting is the quickest way to transfer knowledge to the rest of the group. This is also a great testing ground for new presentations and ideas, you can get a lot of feedback from the people there because there’s no formalities :)
  12. Encourage people to come, even if they aren’t particularly close. Encourage them to bring a friend and carpool. Sometimes really smart people live out in the countryside and it’s super worth it to make their acquaintance.
  13. In fact, encourage them to help them start their own little hack if they feel they could do it. We were thrilled when #BCLittleHack got started 4 hours away by two regulars, Jason Williamson - aka adminwillie and Brett Rath, aka pa_sre. We had to pay them a visit, and it was easy to have some of our regulars carpool with us!
  14. Don’t forget your local VMUG! I could see why a local VMUG leader could want to do this, but honestly it’s a lot of work to do monthly meetups and also VMUG events. I think it’s best to divide and conquer. However, there should be good communication and cross-pollination with the local VMUG. We always involved and invited our VMUG leaders and they always retweeted the PGHLittleHack tweets. Think of it like it’s all a big family and everyone wants the same things, which is an active and healthy community.
  15. Be safe. Obviously sending invites to the general public could end badly. We always followed our spidey sense. We were in a nice part of town, there were security cameras with keyfob access, etc - we were also ready to step in if someone made anyone else uncomfortable. Heck, Carl knows Krav Maga, he can pop a shoulder like opening a beer. The last thing I want to hear is that someone’s gear was stolen or people were held up. Trust your instincts and if something feels off, don’t ignore it.

I want to write more, and especially on when we did our first “Big #PGHLittleHack” - but instead I’ll just leave you with this tweet chain by lamw and kmruddy. Please remember - you are never alone in the vCommunity. We are proud when members take initiative and achieve things that benefit others, even if it takes a while! Doing local little hacks will be noticed and you will gather support from all over the world.

I wrote this so more people can get started doing these and more people participate in coding. I feel they are immensely important - the world is moving to more code and automation, and we aren’t getting any younger. So frequently we just don’t have time to learn. Little hacks are a way to dedicate a few hours to an idea, while learning a lot from others, and building up a local network of people you can ask questions to. Training and VMUGs are great, but at some point you have to do it, too - so your production isn’t also your test environment :)

What questions do you have? What did I miss covering? Let me know!

best,

Ariel