Don’t let the title throw you off. I am grateful for my first-ever hackathon resulting in a victory and I did work hard to earn it. But I don’t think I got the most wholly experience possible. Let me set the stage, then I’ll explain.
I joined forces with long-time friend and computer security guru, Connor Egbert, for BrickHack 4, the Rochester Institute of Technology’s annual winter hackathon open to the public. We’re both fourth-years at the school, but never participated in one of these endurance tests before. With the proverbial clock ticking away our remaining college experience, we decided to give it a try.
Connor brought the hardware and back-end to the table, while I brought the software and design. Over the next 24 hours, we’d turn an idea into a fully-working prototype inside of a dining hall-turned-digital den.
Going into the hackathon, we knew what we wanted to do: give non-“smart” laundry (washer and dryer) machines smart capabilities at a fraction of the cost. As freshmen, Connor and I would get mildly-inconvenienced when we’d bring our dirty clothes all the way down six floors to our dorm’s communal laundromat only to find that all the machines were occupied. Sigh.
Through some crafty engineering, we could place a motion sensor inside each machine and broadcast its occupational status, based on movement, to the particular laundromat’s “hub” (a server).
We arrived at a fitting tagline: if it’s shakin’, it’s taken.
We could have these units installed on all public machines, campus-wide, for less than 1/25 the cost of upgrading them through retail.
From the comfort of their dorm rooms, students could use the mobile interface I made to search their laundromat and see if there are any open machines.
This solution doesn’t rely on crowd-sourced information and is scalable. We named it Lndry, “laundry” without the vowels. (Look, we allocated all our creativity elsewhere…)
If you want to read more about the development and technical side of things, check out our Devpost listing.
Lndry won the Internet of Things category for the hackathon after we demoed a half-dozen times to various judges, staff, and fellow hackers. People really enjoyed the idea and our presentations, and I really enjoyed my first hackathon experience.
In hindsight, I could have achieved close to the same end result had I shifted my mindset from wanting to win to wanting to have fun… or maybe a nice happy medium.
What I’d do differently
I would explore my environment more. I was so focused on the checklist of what I needed to get done that I didn’t get the opportunity to see what other people were getting done. Sure, I knew what the pals in my general vicinity were crafting, but what about the other 490 people at the venue? What marvels of Red Bull-induced engineering were being built right around the corner?
So rarely do I get to experience this creative-overload type of setting, and I’m disappointed I didn’t get to shake more hands and be intrigued. Mindless wandering very well could have gotten me out of the coder’s block I faced a few times throughout the day. I could have inspired and gotten inspired.
I wouldn’t try to “prove” myself. The beginning of the event instilled in me a strange feeling that I needed to show everyone that I could succeed. This wasn’t verbally, but rather psychologically. I’ve been making things for nearly half my life, but never in a setting so intimate and uncertain. A sense of comfort eased over me once I realized that everyone is just here to have a good time and learn something.
A hackathon is a competition against yourself, not other teams.
Yes, I did win a category that other people entered, but at the end of the day (and a half) I created something that physically didn’t exist when I woke up. So did hundreds of other people. And that’s awesome.
I would put more faith in others. Between a last-minute server crash, a 3D print job gone wrong, and two Raspberry Pies frying, it was as if there was an inverse-correlation between time remaining and hardware-related problems arising for Lndry.
I had a hard time fathoming a near-future where Connor and our mentor, Anmol Modur, could resolve the seemingly endless stream of issues in time for our demo. I didn’t doubt their abilities. I was just overwhelmed because the solutions to the problems were out of the scope of my toolbox. Besides, I had software-related debugging to do myself.
They managed to fix almost everything.
I felt stressed, but I shouldn’t have been for three major reasons:
- I prepared plan B’s where possible, like simulating data client-side instead of actually pulling from a server.
- A hackathon is a healthy place to make mistakes. The worst that would have happened if problems persisted would be a suboptimal demo of our product. There was nothing major on the line.
- My teammates were honest and transparent. When they said they could fix something, I should have believed them. Why lie to me when they have as much, if not more, of a stake in our end result?
If from hour zero I tried delving into Raspberry Pies, for instance, I might have been able to help my teammates with the problems they faced later down the road. This would have come at the expense of not having a front-end to the likes we did, but we would have still built something.
A hackathon is a perfect opportunity to be introduced to the new and unfamiliar. On a day-to-day basis, I tend to stick with what I know, save natural curiosities.
Being in an environment that basically spoon-feeds me this unfamiliarity and me not taking a bite or two is a missed opportunity. Fortunately, I was second-hand exposed to the marvels of 3D printing and the coolness that is a Neopixel ring. Next time, I want to try taking the wheel on some of the hardware and hands-on stuff instead of watching passively.
I would use Open Source sooner. You’ll hear this all the time in software: don’t reinvent the wheel. Only after wasting what I deemed was a considerable amount of time building some of the app’s components did I look into publically-available repositories that did what I needed (which is within the rules of the hackathon).
I only had 24 hours to write this software, and Rome.js wasn’t built in a day.
I wouldn’t pump myself full of caffeine for 30 hours. Coffees and Monster Zeroes helped me power through the waves of exhaustion I faced the latter half of the event, but it wasn’t healthy. It took me two nights of rest post-marathon to feel recovered from the strains I put on my body.
I participated in the 7:00am sunrise yoga BrickHack offered. It was my first time trying yoga and it made me feel surprisingly rejuvenated (and sore) after being awake for 22 hours at that point. The remaining 10 hours saw me stretching frequency and getting my body moving. In future hackathons, I’ll be getting off my butt more and maybe even catching a quick snooze.
Yeah, I’ll do a bunch of things different next time. But it’s equally important for me to capitalize on what went right.
What I’m Glad I Did
I was satisfied with “close enough”. Once I got over that “proving myself” mindset early in the event, I became more comfortable with my work being passable. Being done is better than being pixel perfect. What we did is better than what we wanted to do.
I took the time and planned. Making changes to a product when it’s still in the idea phase is considerably easier than when it involves re-writing code. The 20 or so minutes I spent making a wire-frame and iterating on the design with Connor and some randos by my side was well worth it.
…But, I winged the scope-creeps and pivots. Our project grew from the idea of throwing a Raspberry Pi on a washer that talks to an app to something much more elegant. We were only halfway through the hackathon when it occurred to us that the basic functionality was complete. We were just missing that oomph. We started brainstorming where we could take the idea. This lead to printing cases for both the sensor and a novelty desk toy that lights up when your clothes are done!
We measured twice, cut once. But we didn’t have a set-in-stone production schedule to follow. This spontaneity made each hour exciting.
I documented my progress. Because then I got cool time lapse .gifs like this!
I formed a team and idea beforehand, but kept the doors open. It was advantageous knowing Connor before BrickHack because I was aware of his skill set, strengths, and weaknesses. This made divvying up tasks a breeze.
What I didn’t expect was a third-party giving us assistance. Anmol, a mentor of BrickHack, helped us shape the end result by leading us in the right direction when it came to 3D printing, glass-cutting, and some circuitry. At the start of the day, we didn’t know we’d be so privileged as to work with the treasure trove of information that was Anmol.
Keep your eyes and ears peeled.
I took the time to help other teams. I had a few hackers ask for my help with React Native because they saw I was using it. I’d stop what I was doing to give them a hand. This assistance sparked a couple intriguing conversations where I, in turn, learned some things. Again, don’t view the other teams as competition. View them as potential friendships (/cheesy).
Anmol’s altruism really rubbed off on me.
I showed, not told. I brought a dozen copies of my résumé, but only gave out one. If I really wanted to, I could have gotten all of them into other people’s hands (or trash bins). However, I realized that wowing the judges and company representatives with what I could do in 24 hours was more impressive than 12-point Times New Roman on Sea Form 32lb cotton paper.
I surprised myself with what I was able to accomplish. There’s no better feeling. I’m proud of Connor and Anmol’s work ethic. But next hackathon, I won’t go in with such a I-want-to-win mentality.
All that’s come out of winning — prize aside — is a couple “nice job!”s, some high-fives, and little boost to self-esteem. The real hackathon trophies were the ones each team built, regardless of grandeur.
Stepping away from my computer at the next hackathon to talk to like-minded developers and test experimental projects sounds like a hell of a time. And if that’s valuable time I could be spending working on my own stuff, so be it.
Because even if I’m not building a project, I’m still building myself.
(Just please oh please remember to bring deodorant.)
Hey! Thanks for reading my first Medium post. I have a blog on my personal website, zackbanack.com/blog, where I make coding tutorials and fun game development-related posts.