Programming

I like to consider myself a natural leader. When most people are silent about their opinions, I express myself, especially in a situation where an opinion is needed to make an important decision. Because of that trait of mine, usually when I have to work in a group of people for a class assignment, I end up becoming the leader of the group, and others listen to me when I delegate tasks. Usually, I enjoy doing this because I can make the executive decision on whose skills can best suit a task. However, this is significantly more difficult when there is a huge time crunch.

​

That leads me to the story of my first hackathon. I attended ShellHacks with other UCF students, and I was excited to see what a hackathon even entailed. However, once the groups were formed, everyone in my group realized none of us had hackathon experience. Because the others were hesitant to begin the project, I became the unofficial leader of the group. The problem with leading a hackathon group is that everything needs to be done extremely quickly, because we had to design and build an entire programming project from scratch in only 48 hours. Trying to organize all of us to take on this task was quite difficult, but I tried to emulate leaders I admired that I had worked under to tackle this problem.

​

First, I allowed us to have fun and relax at the beginning, since we were all nervous with our lack of hackathon experience. Then, I asked everyone what programming languages they were familiar with and most preferred to write. After that, we brainstormed how to best integrate our skills with the project idea. Finally, I told everyone to work on a part of the website they had the capability to complete. If two people wanted to work on the same feature, I let them work together once they were done with their separate parts. That way, everyone’s skills would be best utilized, and we could finish the project in time.

​

Fortunately, this strategy was successful, and by the end of the 48 hours, we had a website that achieved all the baseline functions that we had envisioned during our brainstorming session. Because everything turned out alright, I am satisfied with how it went, but with hindsight, I wouldn’t have been so nervous at the beginning. I think my hesitation cost us a good bit of time, but luckily for us, it didn’t really have consequences.

​

I love hackathons because they are a low-stakes way to prepare for the reality of software development jobs – time crunches, working in teams of strangers, and trying to put out an actually functional result of hard work. Having the opportunity to be a leader in this environment was an extremely valuable experience, and it taught me a lot about how to lead in unfamiliar situations. Next time, I'll be more prepared to lead with pride.