I learned a lot over the course of my sophomore year, from wiring a circuit to figuring out how much sleep my body needs (the hard way), but one of the most worthwhile experiences I had was one that was a little surprising.

All the way back in February, I attended my very first hardware hackathon.

If you know me, you're aware of the fact that "hackathon attendee" and "Caitlin Stanton" typically go hand in hand. Since my junior year of high school (when the hacking really started to pick up and my parents were convinced that I was on some government watchlist—they still don't really understand what a hackathon means), I've attended over a dozen hackathons. Alongside teammates new and old, I've helped make projects to support political education and discourse, help people find tech-related events that fit their wants and needs, and terrify people with extremely loud noises and scary faces.

By the time I got to Cornell and declared myself as an electrical and computer engineering major (I am **not** a CS major, no matter how many monogrammed items I own—those are just my initials), I felt as though I had exhausted all of the ideas that naturally arise in a hackathon setting. I wanted to expand the amount of possible things I could make, and the most straightforward way to pursue that goal was to learn more about hardware.

My fellow bomb-ass teammates waaay before we started crashing around 9 PM ;)

After seeing a ton of Facebook and mailing list promotion for it, a few of my fellow ECEs decided to sign up for the Life Changing Makeathon, an annual hardware hackathon hosted at Cornell by Life Changing Labs. We knew our knowledge was limited and our expectations for success were low, but we wanted to get our hands dirty and learn more about the applications of ECE outside of a lab.

When I say our expectations were low, I'm not exaggerating.

We went into the weekend with only two of us having even touched a programmable chip outside of our Digital Logic class (Henri had worked a bit with an Arduino for her project team, and I had programmed an Arduino in the span of four hours back at Qualcomm). Our strengths tallied up to the following.

we were relatively diverse in our studies (4 ECEs, 1 CS, and 1 MechE)
half of us had programmed before
all of us were well-versed in the art of bullshit.

"Bullshit" is the term I use to describe what often happens at honestly any sort of project-based competition. Whenever I walk into an event that requires me to make something in the span of two days, I automatically know that I won't get everything done. People's ideas tend to be bigger than their final product, and with a hackathon that was dealing with mediums I had never used before, I didn't expect anything different.

However, what hackathon judges tend to appreciate almost as much as a finished prototype is a good story. I've learned to incorporate my background as a hacker into my hackathon presentations, to give them a better idea of my skill-set and what they should expect in terms of a technical product at the end of the hackathon. I always dedicate a section of my team's presentations to our vision for the future: what kinds of features we would implement, how we envision our product growing, the underlying business/outreach model.

Basically, if you have a halfway-decent prototype and a grand vision to take it to the next level with more time and resources, it'll go far in the eyes of the judges.

With that in all of our minds, we spent the next three or so hours trying to figure out what was going on. There was a table covered in wires, sensors, and boards that people were scrambling to pick up, but we had virtually no idea what any of them did or how we wanted to use them. We grabbed one of everything and rushed back to brainstorm.

Having a variety of options did *not* help us narrow down what we wanted to build at all.

I had to leave for an hour to lead my sorority chapter meeting, and when I left, we had two ideas on the table:

A motorized flower pot to remind you when to call your loved ones by "wilting" when you hadn't reached out and "growing" when you had
A phone case that would buzz and flash lights if you were holding your phone and using it for too long

Both concepts had passion and usability behind them, so when we were split down the middle in our vote to pick one, we figured a combination of two good ideas would form one great ***vision***.

We finally had our idea down and were ready to build nearly five hours into the whole event. This isn't uncommon, to spend the majority of a hackathon trying to come up with a problem to solve and a workable solution to fix it.

Rome wasn't built in a day, right?

Idea? Check. Arduino and a crap ton of related sensors? Check. Fruit snacks? Not enough, but check.

So what did that leave us with? New technology to learn and an entire product to build.

The organizers put on a workshop on using Arduinos, which we of course attended because why spend hours googling when you can learn from a real person? Making an LED blink after hearing their tutorial was the most exhilarating feeling (and that's why I'm in tech). We went with a divide and conquer strategy to get all aspects of our product up and running. Two of us ECEs focused on the actual circuiting of the Arduino to the sensors. The CS major started writing code to connect the various inputs and outputs. The rest of the team worked on making the flowerpot so as to give our overall product a snazzy look.

Dinner rolled around and it's safe to say that we were truly exhausted. Even though we had only left our table to grab food and go to the bathroom, it felt as though we had been running a marathon. It's tiring to stare at a screen, fix bugs and then watch as new ones arise, and try to figure out if the sensor isn't working or if your code is just dumb.

But we were done with our prototype. It wasn't even midnight and even the rest of my ECE squad, the people who were used to staying up until 4 a.m. to add finishing touches to an assignment, felt comfortable with what we had all made.

Above is what we built and are able to call our shared dysfunctional child!

It's called in.bloom, and it's purpose is to alleviate negative phone usage and start ingraining healthy phone habits instead. There are two parts to it: a phone case and a motorized flower pot.

For the phone case (which didn't have an actual phone case incorporated into our prototype, whoops!), we used touch sensors to show how long the phone was being held. If it passed a certain amount of time, the LED screen would flash a message, which varied in color and urgency as time progressed, prompting the user to put down their phone. The research we had found showed that younger generations have a tendency to spend nearly a third of their day on their phone, often checking their device up to five times in a single hour. As college students, we (especially I) empathized with the urge to check your phone constantly, and felt that software-based applications were easy to override and ignore.

It's a little more in-your-face if your phone is literally screaming at you to put it down.

The other half of in.bloom was the motorized flower pot. Within the prototype, buttons were used to show that you contacted a loved one; in the future, this physical button would be replaced by an extension on your phone's calling/texting functionality to analyze your calls and messages to programmed contacts. Once a call to your loved one was logged (the button was pressed), the flowers would rise, providing positive reinforcement. However, if after a certain amount of time no contact with loved ones was logged, the flower would fall, as a physical reminder to call. The motion of the flowers was controlled with servos, and the buttons were wired as inputs to the Arduino.

Our team (Team Fruit Snax <3) presenting in.bloom to the hackathon judges!

The second day of the event was devoted to presentations. It's always my favorite part of a hackathon, because it's a chance for all of the hackers to see and appreciate the work that their fellow competitors put into their products.

As the other teams demoed one by one, our collective Team Fruit Snax heart sank. There were automated mailboxes, power-generating bikes, and muscle-memory enforcing gloves. We truly loved and were proud of in.bloom, but the competition was stiff.

At the end of the day, we told ourselves, it was most important to leave the event satisfied with what we learned and built, and we had that box checked off in our minds. The presentation was just another bullet point on the schedule.

So you can imagine our surprise when they named Team Fruit Snax (yes, us!) SECOND PLACE.

One moment we were chilling and eating bagels, commenting on how cool the other projects were, and the next we were squealing and hugging each other excitedly. We stepped away with a feeling of accomplishment (we had that anyway, but getting second place definitely added to it a lil bit), an invitation to submit our product to the Big Ideas competition run by Cornell eHub, and an Amazon echo dot for each of us!

The weekend was long, homework still needed to get done, and I had eaten way too many bags of mini pretzels, but that hardware hackathon enforced the feeling that I had when I first applied to be an ECE major: I love building, and I especially love building things that I can both hold in my hands and control on a screen. It's a little cliché to say that one event changed my outlook on my major, which is why I'm saying it didn't change anything, it confirmed everything.