What I Learned Hacking on a Team at the 2024 NASA Space Apps Seattle Hackathon

tl;dr:

• Scope of Work
• Teamwork & Communication
• Public Speaking

This past weekend, I made my first trip to the Pacific Northwest (PNW), specifically Seattle, Washington. Not to sight-see, but to #hack at the NASA Seattle Space Apps Hackathon. At the event, I both volunteered as staff and participated as a hacker, joining the team Tremor Trackers (TT) where we endeavored to analyze the Apollo Missions’ lunar seismic data. Our challenge was to identify seismic events (moonquakes!) while reducing false positives and noise, ultimately filtering down the amount of data that needed to be beamed back home for study.

The team and I were quickly reminded that space data is literally infinite, but relevant data is quite finite.

Backstory

My journey to the 2024 NASA Space Apps Hackathon started with a single #MeetUp I attended just a few months prior: Space Data Hackers , where I had the pleasure of chatting with fellow space-nerds about new technologies and exciting ideas regarding humanity’s future in space. This MeetUp got me pumped! I wanted to be more involved in growing the aerospace industry and was referred to Mike Doyle, the founder of Space Northwest, an accelerator program for PNW aerospace companies.

After chatting with Mike, he and I decided I’d head seattlespaceapps.org 's web development and design work leading up to the event. Space Northwest's goal was ambitious: break the previous year’s record number of registrations to the 2024 Seattle Space Apps Hackathon. Spoiler alert: We did! The Space Northwest’s team’s efforts yielded a 10.1% increase in registrations versus the prior year!

Riding on the excitement of the record breaking registrations, I hopped on a plane Friday morning and flew out to Seattle to meet my fellow space-nerds in person, volunteer, and put my hands to the keyboard as a hacker.

The Hackathon Begins: Day 1, Finding a Team

Upon arrival in Seattle, I drove my rental car straight to the Hackathon to help with event setup and Hacker check-in. Once everyone was in, I flipped my Staff badge to my Hacker badge and searched for a team. Fate was on my side and the first group I chatted with was a match: an experienced statistician, a 10-year Microsoft Software Engineer, a US Army veteran Front-End React developer, and me: a lowly self-taught Python coder turned Senior Web Developer with sights set on AWS Cloud Security. We selected our Challenge (Seismic Detection Across the Solar System), selected our team leader, and the team was assembled.

Let’s goooo!

Day 2: Ready, Set, Hack!

1. Discovery
2. Plan
3. Build
4. Present

Step One: Discovery

No one on team TT knew anything about seismic activity before this weekend, and we quickly realized the scope of the project was immense: the amount of knowledge we needed to gain, the millions of data points available, and then building a solution in a mere 1.5 days… The challenge was, well, challenging. After our preliminary review, I hopped over to the white board and started time blocking and visualizing our strategy in order to help make a massive undertaking feel more manageable (image below).

Step Two: Plan!

The second hour of our strategy was blocked out to plan out the app we would build based on what we had learned. We selected Lunar seismic activity (Mars was also available) and began to analyze the data. The data sets contained tons of “boring” data (700,000+ data points per each of the ~75 .mSEED files), and slices of “interesting” seismic activity (image below). The team decided we'd create a filter at the seismic data collection points so that only the slices of relevant data would be beamed back to Earth for study.

Next, we delegated responsibilities based on our strengths: two of us would be on the backend aiming to 1) Pre-process the seismic data to reduce noise 2) Create an algorithm which would identify start points of moonquakes and avoid False positives due to pre-shocks and noise. (Image below: An example of a moonquake that I visualized with an ObsPy Python script).

We also wanted to reinforce the algorithm’s accuracy with a secondary spectrographic analysis (Image below: Spectrogram I created using a second ObsPy Python script).

The back end part of our team settled on to using a form of encoding to pre-process the data to reduce noise, then Short-term/Long-term average (STA/LTA) comparison algorithm to ID the moonquakes in each data set.

For the front end duo, it was our job to ready the app’s User Interface (UI) to ingest the filtered data and create visualizations and animations of the slices of data where quakes were found. Front end stack: JavaScript, React, TailwindCSS for the UI, and then Python and ObsPy for samples to build with.

Ultimately, we settled on the goal to build a system where only the small slices of relevant data were beamed back to Earth and were made easy-to-ingest and study. This would reduce bandwidth, compute, and satellite power consumption. This would also help humanity to better understand celestial geology and potentially make space exploration more fruitful, and habitation safer for future space-faring humans.

Step Three: Build (Easier Said than Done)

To put the scope of the project into simple terms, we could have spent weeks building out this app, but we had a day and a half. In figurative terms, we wanted to build a spaceship, we had to scope it down to an airplane, and ultimately we had the time to produce a paper plane. This was not a failure, but an extremely valuable lesson in Scope of a development project. (Image below yanked from this LinkedIn post)

Google Gemini defines Scope here, in short, as “Scope in app development refers to the boundaries or limitations of the project”.

We were limited in both time and knowledge of our geological topic. Throughout our day of hacking, team TT regularly had to adjust the scope of the project in order to ensure that we’d have a tangible project to present and submit on Day 3.

Scope was not the only challenge we faced. Improvement of communication was next in lessons learned. We all had great ideas about how to proceed with the challenge, but, these ideas were not initially aligned, and were often difficult to articulate as we were dealing with a subject entirely new to each of us.

This is where active listening and asking for clarification was crucial. The back end duo were more Senior-level in terms of work and hackathon experience and the front-end duo had fresh perspectives. Often, we’d each be explaining ideas which sounded different, but were ultimately in line with one another, had we spent some more time hearing and asking for clarification, we'd have ultimately saved time and been more efficient/effective.

One of my favorite techniques applied to encourage better active listening was my front-end partner using the phrase “Walk with me” in order to keep us engaged as he articulate his ideas.

Another handy tactic I employed was "Disagree and Commit", a management idea attributed to folks such as Jeff Bezos (Amazon) and Scott McNealy (Intel). This management strategy helps the ball of the project to continue moving forward.

By the end of Day 2, our spaceship-level-of-complexity ideas were cut down to paper airplane levels, and we needed to start creating a presentation with our data output and learnings.

One of the most crucial turning points was when one of the Hackathon Mentors gave us the advice that we needed to get our project to the point of “Just Good Enough”. This sounds like setting the bar low, which I thoroughly dislike, but we needed to be realistic and respect the scope of the project in terms of the time limits. Once our project was “Just Good Enough”, we needed to create a presentation and submit our work for judging.

Day 3: Presentation & Submission

Throughout day two (Build day), we’d been mindful of the presentation and submission guidelines in order to help keep the project on track. In between research and coding, we were piecing together a presentation that we’d have 4 minutes to share with the rest of the attendees and esteemed judges from companies such as Blue Origin, Microsoft, and Amazon. No pressure! /s

Delete, Delete, Delete

As a go-getter team, we chose the very first time slot on Day 3 to practice our presentation pitch for feedback. We found that we had too many slides and thus went over the 4 minute time limit. No sweat! This is why we wanted to be first to receive feedback in order to have ample time to revise our presentation.

We deleted and cut down on the number of slides from 16 to 7, abbreviated our talking points, and practiced pitching our presentation segments with one another and shared feedback. We aligned our presentation with the submission guidelines and finished the presentation with a few hours to spare.

The Time has Come: Present

I have ample experience speaking with public and presenting technical ideas at high and low levels from my time at Tesla, in property management, and from my web development roles. I felt confident during the practice and I kept my talking time tight. However, this was my first time presenting a computer science subject to a room of 80+ extremely talented individuals. I stumbled a bit, I awkwardly repeated a few items, but I reminded myself that I am my own harshest critic and allowed myself some grace.

The rest of team Tremor Trackers pitched their segments to perfection. We finished presenting within time, answered the judge's questions, exhaled a collective sigh of accomplishment, and relished the victory of completing and submitting our seismic challenge.

Public speaking and selling the pitch to the judges and audience were the crucial factors in which teams were selected as Winners and moved on to the Global competition. A good lesson to take to next year's competition. Team Tremor Trackers did not win the event, but we certainly didn’t lose, either!

Valuable Lessons

• Scope
• Communication
• Public Speaking

My three days with team Tremor Trackers at the 2024 NASA Space Apps Hackathon were some of the most accelerated moments of growth I’ve experienced in my ~5 year journey from teaching myself to code to becoming a more confident individual contributor in Web, Python, and AWS Cloud Development.

The objective at the hackathon, for me, was to gain experience building with a team. Mission Accomplished. I’m now better at building with a team, communicating, I can scope projects more realistically, and feel ever more confident in my coding and presentation skills -- Impostor Syndrome be damned!

• Thanks to the Space Northwest team, MAC PNW, and F5 Networks for your event sponsorship, presence and support during the event. More sponsor details here: https://spaceappsseattle.org/
• Thanks to the mentors and fellow volunteers who made this event possible.
• Thanks to all of the brilliant hackers who made me feel welcomed at my first in-person Hackathon.

"Space is for everyone!" - Mike Doyle