This weekend I had the opportunity to participate in the AWS Hackathon in Portland. Based on the hackathons hosted at re:Invent, this brought together about 100 developers of all skill levels to break up into small teams and produce a demo product in 10 hours. I had a great time, and wanted to share what I learned!

My AWS Hackathon Takeaways

1. AWS Lambda is the future

There may be organization-specific roadblocks to adopting AWS Lambda right now and therefore, it might not be the right fit for your team at this particular juncture.

But this hackathon really underscored just how critical Lambda functions are and will continue to be. Out of the 13 teams there, barely any that didn’t use Lambda functions in their stack! Lambda is clearly an area where massive growth is on the near horizon.

2. You don’t have time for Amazon EC2 at a hackathon

Related to the first point, I didn’t see any EC2 running at this hackathon. This isn’t to say EC2 or Virtual Machines, in general, are universally bad. It just means that they don’t work very well in this situation. The reason involves time and division of labor: someone on your team is going to be doing operations while someone else writes application code.

The problem with EC2 is that it takes time to set up -- and the whole time you’re setting it up, your developer will be waiting to get started. After the image is provisioned and started, you’re still not ready since you need to give your developer access.

3. Using the Lambda dashboard directly is surprisingly fast

Normally I use Stackery to speed up the deployment process, which means I don’t have to interact with AWS console to set up or run Lambda functions. But in the environment of the hackathon, I did discover something interesting: the AWS Lambda dashboard is fast as heck!

In general for testing the Lambda function, we started with hand testing it with the dashboard “test” button, then testing it with Postman, then testing with our frontend. This was especially useful because:

4. Documentation of Boto3 examples is… minimal

The Python AWS library for Lambda functions, Boto3, has a complete documentation site. All well and good but the documentation of examples is extremely minimal. Just trying to send a response that would look good to an AWS API Gateway proved difficult, with a successful run still returning errors.

We attempted to find a simple working example of posting to an Amazon SNS topic and found three code snippets which were all posted as solutions to other questions -- and none were verifiable solutions. For my team, none of them worked!

If you’re a junior developer looking to write a dev.to post that will get some traction, a few examples of working Python Lambdas using Boto3 could prove extremely popular!

5. Take a minute to think about how your demo will look on stage

Everyone loves mobile apps, but without a lot of advanced preparation you’ll end up demonstrating on stage and hoping everyone believes you about what your phone’s screen shows. A demo you can easily project and present from the lectern will generate a lot more excitement.

Also: it’s great if you can show some debug output from your data layer. A product that’s actually working will always play better than one that’s just a wish and a promise

6. Your team succeeds or fails by its project management

The manager/coordinator role is the most important position on your team so put some real strategic thought into who that person will be.

the architecture slide from our presentation

7. Originality will always stand out

I highly recommend pursuing your biggest, wildest product ideas. If this is your first hackathon or you’ve never used AWS before, great, make a shopping list app. But if you have some competency on your team and in yourself, it’s time to stretch a bit. The three finalists at our hackathon were: an ambitious dev tool, a voice-activated tableau viewer, and our “digital graffiti” project (more on this below).

In general, a perfectly-executed app with uncreative features is going to play a lot less well than something that does something new.

8. Put it on your resume

We all dread that question in our first few coding interviews: “Have you ever shipped a product?” After a hackathon, you should be able to answer “I shipped a product in 8 hours, with a team of people I barely knew, all while sitting in an uncomfortable chair!” **Done right, a hackathon is worth about 6 months of development experience. **When you’ve done one, win or lose, it’s worth celebrating!

9. Eat, breathe, rest

With time ticking down it’s easy to skip snacks and trips to the coffee machine so you can focus on your work. This is wrong. You will get more done, and your work will be of higher quality if you take 10-15 minute breaks often. Like most development tools hackathon, this one had great free food. I encourage you to stand up and grab whatever snacks are available. It’ll also mean you’re in a better mood, which is critical for making the connections mentioned above!

Now, after telling you how to win at a hackathon, I’ll say:

10. Winning is not the only point… but it’s awesome!

The prizes at any hackathon are small, and the time commitment of the event is pretty large. If you’re here to win $100, you could get more money spending the day mowing neighbor’s lawns. The point of a hackathon is to try new things and make connections with other awesome people. If you’re given the choice between making a project you think will win and one that is more interesting, with more interesting people, always choose the latter. When you’ve done one, win or lose, it’s worth celebrating!

Speaking of celebrating, our team’s aforementioned digital graffiti project did win! Head on over to https://digitalgraffiti.club/ to post a message that only people who visit the website in that same geographical location can view. It’s like digital geocaching. For now it’s a website, but we’re hoping to make it a full VR experience in the future. Enormous thanks to my teammates Alastair Drong, Brian Ginsburg, Melissa Smith, and Jason Van Pelt

While, again, the prize of a hackathon is the connections and experience gained, I will say that winning has been an extremely motivating way to kick off a week that will end with me giving a talk about “The Serverless Mindset” at the inaugural ServerlessDays Nashville event in Tennessee.

My talk centers around my journey to serverless engineering at Stackery and some of the best practices I suggest for maximizing serverless (and career) success.

The experience of doing well in a hackathon alongside an awesome team with many of the AWS tools my permanent team at Stackery uses daily is almost like a case-in-point of the subject of my talk. Namely, that a serverless approach can really free up a lot of extra mental bandwidth so you (and your team) can spend time focusing on writing business logic on a regular basis — and maybe even win a $100 Amazon gift card if you bring that mindset to a hackathon!

If you’ll be in Nashville for ServerlessDays and want to chat about Stackery or serverless in general, please DM me on Twitter while we’re onsite or just say hi if you see me IRL. Hope to see you there.