What I Learned @ YHACK 2015

08 October 2015

I’ve just returned from YHACK 2015 and want to write about the event while it’s fresh in my mind. While you read this, realize that this was my first hackathon and that my intent was to produce a good performance (i.e. the intended goal was to win an API challenge/win the event).

Take the following as advice to any newcomers.

This being my first hackathon I had little knowledge about event logistics and preparation. I was unsure of what to bring with me — was one change of clothes too many, or not enough? Should I bring my own keyboard and mouse? Do I need to bring test devices? I was unsure about all of these questions, so let me fill you in with what I learned. For a two day event, one change of clothes is more than enough, and if you know ahead of time that you can’t shower it might be best to forgo bringing these if you’re traveling and you want to bring as few bags as possible. With regard to hardware, i.e. a second monitor and peripherals, this is all personal preference. I work best at home with my 27” monitor, ergonomic keyboard and mouse, but I knew I wouldn’t be bringing all that with me (though some people did bring their monitors). I brought a mouse and nice headphones, though I wouldn’t recommend bringing peripherals because the likelihood is that your hacking space will be small, unclean and you’ll be moving/mulling about quite a bit so these won’t really help you in this situation. At the end of the day I my setup was more than fine. This next bit speaks to the hack that you’ll be bringing to life, but generally I’d recommend having an idea of what you’d like to make beforehand that way you can decide if you need to bring some hardware to test on. I know that in some cases this isn’t possible, but I’d generally recommend bringing as little hardware as possible – if you’re building something platform specific for a big enough event it’s likely the vendor (ex. Microsoft) will be there and able to give you test devices.

What about the tech-talks, product demos and API help sessions? Should I even bother with the companies who are there? If your intent is to complete a challenge or try to win a hackathon I’d recommend reviewing the list of sponsors and their APIs ahead of time. If you know that Microsoft will be there beforehand then look at their stack; maybe you’ll be interested in Project Oxford and then decide to build something on that. Generally, it doesn’t hurt you to go without an idea or a team, but it will certainly take away from precious coding time, so keep this in mind in the time leading up to the event. Furthermore, if you know that you want to build something using a company’s API, such as Haven-On-Demand from HP in our case, then I would recommend going to the company’s session. Such companies will often run through the API quickly and then show samples or provide a help session, so if you need to get off the ground or need some help in how to implement something these can be a great resource. In the same vein, if you want to win API challenges then definitely do a “mashup” — it can’t hurt you and is probably a good idea given the time constraint. It’s better to have multiple facets to whatever you’re building so that you can apply it in different ways rather than to bank your entire performance on the evaluation of one company.

Sleep. Do I need it? If so, how much should I get? I would not recommend the approach that I took, but it worked for me, so you might like it. I decided, because of how late we started hacking (it took some time to decide on an idea), that I would power straight through the night and day to make as much ground as I could. At the end of Saturday I’d been awake for 39 hours (I woke at 9am on Friday morning) and coding for about 20 hours. This was not a good idea. I was slightly tired cognitively, but what really affected me was my physical state– I was really cold. This might be the type of person that I am, but when I get tired I get cold, as in shivering, and that combined with the fact that I’d just shaved my head and was without a hat was not a good combination. I spent my entire Saturday shivering over my keyboard, wishing I had on something more than my t-shirt and jacket. My partner on the other hand decided to crash for ~4 hours early Saturday morning and produced good code with no cognitive problems the rest of the day. He repeated this on Sunday and felt good. I’d recommend that you constantly analyze your physical state and decide if it’s best to sleep then because you’ll always end up paying for missed sleep at a later date. To note, by the time that 12AM on Saturday night came around I was so ready to be done coding that I got a bit sloppy. All I wanted was to go to sleep and this lead to me taking some shortcuts, again I wouldn’t suggest this, but in the long run it worked out as it forced me to employ some powerful thought so that I could finish early enough to get a good night’s sleep. Furthermore, in the week leading up to a hackathon, I’d generally recommend banking up on sleep. It doesn’t hurt to get a good 8 hours a night for the 5 days prior, and it won’t kill you to sleep while you’re travelling to the target destination. It’s best to arrive to the event rested so do whatever it is that you need to make sure that’s how you show up.

Teams. Do I need one? Should I have an idea? What if I don’t have one and/or want to work solo? I went to YHACK without a team and this made me nervous. I was also without an idea, which is also not a good position to be in. I think the best bet is to at least have an idea, as I mentioned before, of what you want to build there by reviewing sponsor APIs/offerings before the actual time you start hacking. If you have this, you can partially mitigate not having a team because at the least you’ll be able to recruit people to help you build your idea (assuming it’s not complete garbage). At best, I’d recommend either going with friends, or networking with people attending before hand (i.e. find them in the Facebook group, Slack channel, or email list) and then asking if you can form a team. Doing so will resolve a lot of anxiety, help you round out rough edges so you can build a great product, and also help you to further refine an idea or approach before the event so that you’re maximizing your time. I know that this isn’t possible in all cases, and that’s why hackathons try to do “mixers” or “team-finding” activities, so if you can’t or didn’t do the above then just go there and find someone to join. The worst thing you can do is work alone. The reason you went to the hackathon in the first place (I’d hope) is to build something cool with other people. If you want to work alone you could’ve done it at home (or maybe you just wanted the prizes) but the likelihood is that you’ll be more motivated, have more support and produce a better product if you’re with other people of similar or better skill!

Personally, YHACK 2015 was great for me. It was phenomenal to win some of the API challenges (HP Haven-On-Demand and Priceline(http://www.priceline.com) with my partner. I would’ve been more than happy winning nothing because at the very least I got to meet new people, build something workable in a short amount of time and improve my skills. More important though is what I know now: if you want to go to a hackathon, even though it generally seems spontaneous, you need to do some planning before hand and have a general strategy. Bank some sleep leading up to the event, come up with some ideas, and maybe even try to meet people before hand. If you fail at trying to achieve all of the above, the worst result you can encounter is being back where you would’ve been if you didn’t do anything (which isn’t so bad), so just do it anyway!

If you’ve made it this far I hope that you found at least some of this helpful. I wish you happy hacking if you decide to attend a hackathon and hope you’ll be more prepared than I was for my first event.

Check out what we (Thomas Lam and I) built at YHACK 2015 – HotlineBing: Search the internet and book hotels using SMS!

Thanks to Evaline Xie for reading earlier drafts of this essay.