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.

Well, mostly.

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.

Scientifically provable.

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?

I would get further out of my comfort zone. Segueing off a couple previous points, I feel I’d have benefited more from the hackathon had I tried doing something that I hadn’t before. While BrickHack 4 marked my first time creating something with React Native, it wasn’t my first time using JavaScript or building apps.

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.