Pioneer Hackathon Retrospective

This article describes what I learned during recent hackathon participation.

Before I dive in, let me give a shoutout to this great team, and a double-shoutout to Ben Awad for organizing the team:

Alex Luong (Twitter)
Ben Awad (Twitter)
Radi Huq (Twitter)

First I’ll describe the hackathon, then I will describe what our team accomplished, then I will cover general learnings.

Hackathon Description

The hackathon was called the Pioneer Hackathon. Pioneer is a fully-remote accelerator, and they organized the hackathon. The hackathon lasted 24 hours from April 11 to April 12. An email announcing the final results counted out the competition as more than 750 registrants, from 60 countries, with 140 completed projects. Hackathon developer teams ranged in size from 1 to 4.

Business Concept and Results

Our team developed a web application called DevFit. DevFit is a fitness tracker with social and gamification aspects, focused on software engineers as a target user group. See this link for more details including a video overview, and, if I’m still hosting it, a live link to the application.

Our application received 14 points, placing us in a tie for 24th place. The highest-scored application received 44 points. 10th place received 19 points and 20th place received 15 points. The winner was determined in a 3-phase process:

Initial voting determined the top 50 projects. These projects, including ours, are reviewed by a panel of industry-expert judges.
The judges select 8 finalists. The panel was extremely transparent about the judgement criteria. Criteria included usefulness, originality, polish, and technical complexity, but excluded factors of business viability including the total addressable market.
Our team was not selected for finals.
The 8 finalists participate in live demos and a live audience, and “live audience voting will help us select our winners.” I’m not certain about whether the final winners are selected purely on live vote results.
Technical Implementation

DevFit is implemented as a Next.js web application. Next.js is a universal, or isomorphic, React pattern. Next can be used for rendering a site statically or on-demand. Next.js also supports making API calls. It might technically be a wrapper for Express, but if not it is at least fully compatible with Express middleware.

We used Prisma 2, which is still in Beta, as an ORM. I’m a bit of a Node ORM SME, having written:

1. 2018, Jan, FreeCodeCamp: Which JavaScript ORM should you be using in 2018?
2. 2018, May, HackerNoon: From TypeORM to LoopBack: A Retrospective

Prisma 2 is the best Node ORM development experience I’ve ever had. It at least equals, and possibly beats, I haven’t quite decided, Loopback 4. The disadvantage I see is a lack of API autogeneration with Swagger UI. Prisma comes with a quality, open-source GUI DB IDE called Prisma Studio, a command-line tool, and what I find to be a nice syntax.

The app also includes an Express mock server and at one time we had Apollo in the app, but this was removed because it did add complexity without much benefit compared to using Prisma Client and fetch. DevFit uses React hooks, TypeScript, and css-in-js. We did not find a need to use Redux.

Our infrastructure was just as innovative as our code. By starting the project using a Zeit Next.js template, we were able to deploy a production site before we even starting coding, within two minutes. Zeit integrates seamlessly with GitHub. Zeit is a build and deploy system, and the Now CLI tool can be used to trigger Zeit builds. Zeit’s GitHub integration also sets up automatic builds for pull requests and on pushing to master. The Now CLI tool has support for secrets, so Zeit can handle setting up remote databases and other complex tasks.

As an AWS certified solutions architect, I can tell you that working with Zeit and Now is much simpler and more ergonomic compared to using either the AWS CLI or using SLS CLI for serverless web projects.

Elephant was another tool that we used. This tool provides a serverless PostgreSQL database-as-a-service feature. This tool launches a PostgreSQL database within 60 seconds and will begin accepting connections from your local machine or from a hosted application, like the DevFit instance we had on Zeit. Elephant is faster and less complex than making developers install databases locally. Elephant and Zeit both offer forever-free tiers.

What Should We Have Done Differently?

Every hackathon team faces an optimization problem. The team can play to learn, play to play, or play to win. Our team struck a balance. For me in particular, it leaned towards a learning exercise. We weren’t finalists, but we did make it in front of the judges. We learned a ton. We were friendly, not too stressed, and most of us got several hours of sleep. I don’t think I would have done anything differently.

There are some things I will do differently the next time around. My experience with Prisma Client and Next.js indicates that it’s not feasible to split development into UI and back-end teams. Every developer is full-stack when developing with this architecture. That learning would lead me to set up an Elephant DB straightaway at my next hackathon, rather than spending hours working on mocking strategies.

If I wanted to optimize further on winning, I would not have recommended Next.js. I would have gone with a React or Angular UI and a plain Express server. I might have been open to Prisma, or I might have preferred something lighter weight like Sequelize or even pg, but most likely would be the case that I wouldn’t recommend having a database at all. Static JSON files can be used to build out an experience until it’s nearly user-ready, then a real database can be added on later, with less tech debt due to schema change and migration. While Elephant was great, our team had substantial database trouble over time.

I didn’t want to optimize further on winning this time, though. I’m extremely glad I learned about Prisma and some of the other technologies. One change I genuinely would have made would be to wrap up development an hour or two earlier and get into polishing a little sooner. We had build issues up to the last minute, and our finally-deployed version had at least one run time issue which could have been quickly fixed if we had been focusing on that a little sooner. I think 2-2.5 hours, rather than 0.5 hours, is about the amount of time a hackathon team of 4 developers should spend on polishing, including:

1. Getting PROD stable and deployed
2. Thinking through the demo
3. Staging data to facilitate the demo
4. Pen testing PROD a bit
5. Polishing up the look and feel

One thing we did very well was deciding the business case and technical architecture. Much of this stuff we began ideating on prior to the hackathon’s formal start. This allowed us to focus on code much more than I have been able to in other hackathon experiences. One thing our team did will which allowed us to quickly decide those questions is that no one was particularly pushy with their ideas.

The original version of this article, with a bunch of extra hyperlinks is available here on AfterEcon.