What Blasterhacks Taught Me About Leadership

The Beginning

Although it was sev­eral months ago, I re­mem­ber it like it was yes­ter­day. It was what I would call a dusty Colorado Friday. The sky was over­cast and the trees de­press­ingly bar­ren. The air smelled of cow farts, which was typ­i­cal when the winds changed, blow­ing in cold air from the beef farms in the nearby town of Greeley. In my mind, this sig­naled snow.

I walked into the Green Center, the build­ing in hous­ing the open­ing cer­e­mony of BlasterHacks, the hackathon run by the Colorado School of Mines. I sign in at the en­trance and walk down into the au­di­to­rium.

As I greeted my team­mates, Grant Lemons, Lukas Werner and Byron Sharman, I no­ticed the ner­vous smiles on their faces. You know the kind, the smile with the in­ner eye­brows slightly raised, shoul­ders tense. We were ex­cited, but we also knew we had 36 solid hours of pro­gram­ming ahead of us.

After col­lec­tively down­ing sev­eral whole piz­zas and lis­ten­ing to the rules of the com­pe­ti­tion, we made our way over to Labriola Innovation Complex, the hours-old man­u­fac­tur­ing build­ing the com­pe­ti­tion would take place in.

The Plan

We brain­stormed some ideas un­der the over­cast sky:

• A Bennett Foddy-inspired bat­tle-royale game where all the con­trols were vim-keybindings.
• A health in­sur­ance app that es­ti­mates the cost of your care at all lo­cal hos­pi­tals.
• An app that en­cour­aged you to stand up and move every thirty min­utes.

It was that last one that we all got ex­cited about. We imag­ined it to be so­cial: at a ran­dom in­ter­val (which would av­er­age to thirty min­utes), the app would si­mul­ta­ne­ously send out a no­ti­fi­ca­tion to every user. Should the user choose to par­tic­i­pate in the StandUp mo­ment, the app would guide them all through the same short work­out ac­tiv­ity. Fi­nally, the user had the choice to up­load “evidence” of the work­out, which could be a short cap­tion about what they were do­ing, or a photo.

The idea of StandUp (as we would go on to name our pro­ject) was in­spired si­mul­ta­ne­ously by BeReal, re­cent re­search in the detri­men­tal health ef­fects of re­mote work, and the use of so­cial li­a­bil­ity for com­par­a­tively more ex­treme work­outs (Strava).

Of course, most of this had yet to be nailed down yet, for we were just en­ter­ing the Labriola Innovation Complex. I re­mem­ber ask­ing my­self if I would leave be­fore the com­pe­ti­tion was over. Al­though I was tired from the days classes and home­work, I felt a drive to ded­i­cate my whole self to this pro­ject.

The Board

We sat down and cre­ated a new git repos­i­tory. That’s when I started think­ing about how we were go­ing to or­ga­nize our work. I pro­posed we setup a KanBan board, a pro­ject man­age­ment tech­nique I had picked up at Archytas Automation.

If you’ve never heard of–or used a KanBan board, here’s the gist. There are three buck­ets:

1. To Do.
2. Doing.
3. Done.

The sec­ond bucket is di­vided up by per­son, so in our case, it was re­ally four sep­a­rate buck­ets. When some­one needed some­thing new to work on, they would go to the “To Do” bucket and se­lect a new task (which in our case, was a sticky note). They would place the task into their cor­re­spond­ing “Doing” bucket. Once the task was done, they would move the sticky note into the “Done” bucket and re­peat.

As a gag, we added an ad­di­tional (superfluous) bucket: IDGAF. If a task was unan­i­mously deemed no longer im­por­tant or rel­e­vant to the pro­ject, that’s where we would put it.

So, we got to work. We had de­cided to use Firebase, SvelteKit and Go. I started set­ting up Firebase, Grant started re­search­ing the no­ti­fi­ca­tion ser­vice, Lukas started work­ing on a cir­cu­lar sta­tus page and Byron started re­search­ing the Camera API.

As I look back at this mo­ment to­day, I re­al­ize some­thing im­por­tant about all of these tasks that ended up ben­e­fit­ing us in the long term: they were all in­de­pen­dent. None of these orig­i­nal tasks re­lied on any other to get done. We could work in par­al­lel. Down the road, this would change, but the fact that we were par­al­lel at the be­gin­ning set us up for suc­cess.

The Snow and the Crash

We kept work­ing through the night, down­ing en­ergy drinks and laugh­ing as we worked. We got the im­por­tant ser­vices and UI el­e­ment up and run­ning. Around mid­night, as my nose had pre­dicted sev­eral hours ear­lier, it started snow­ing.

As the snowflakes grew larger and ever more fluffy, I felt the teams en­ergy be­gin to dip. We were en­coun­ter­ing road­blocks, one-by-one, as our mo­ti­va­tion waned and the threat of sleep be­came more promi­nent.

Then, some­one in the main atrium (who, I don’t re­mem­ber) pro­nounced, “we are go­ing out­side.” We ran down the halls like chil­dren spread­ing the an­nounce­ment, and soon enough, there were dozens of tired com­puter sci­ence stu­dents throw­ing snow­balls in their jeans the t-shirts.

As I threw (and re­ceived) a num­ber of snow­balls, I re­al­ized some­thing im­por­tant: we were mak­ing an app about tak­ing care of your­self phys­i­cally, but had ne­glected to do so our­selves. As im­por­tant as the pro­ject may be, it won’t get done when every­one is tired, mus­cles cramped, and un­happy. To keep the mo­men­tum go­ing, breaks are re­quired.

As we filed back in­side to warm our hands un­der tap wa­ter, I swore to make sure the rest of the team would take care of them­selves–and each other.

The Conclusion

The rest of the hackathon was un­event­ful. We sat at our lap­tops, crank­ing out line af­ter line of code. We took breaks and slept when we were blocked by other tasks.

Although it was our first hackathon, we de­cided to run our pro­ject in the ad­vanced track, nor­mally re­served for hackathon vet­er­ans. It paid off, be­cause we won sec­ond-place!

Look at us: hag­gard but sat­is­fied.