Hack days at Feather!
Tags: hackathon, programming, projectideas
Published: 2022-02-08 09:38:33

If you didn’t already know, hack days come from the [traditional hackathon](https://www.forbes.com/sites/theopriestley/2016/01/20/why-every-business-should-run-internal-hackathons/?sh=3962a49d47df) where companies come together with others externally, or internally and spend a limited period of time working on a solution to current problems, or improving internal processes. 

The events became quite popular and started to integrate themselves into the framework of software engineering culture in the industry. This has led many companies to dedicate a certain amount of their time to both internal and external hackathons, or in [Feather’s](https://feather-insurance.com/) case, hack days. 

# How often do hack days take place?

We do our hack days every third Friday, but this might change as our team grows. For larger companies like [Dropbox](https://blog.dropbox.com/topics/inside-dbx/be-a-force-for-change--hack-week-2019) (they have around 2,800 employees), they can only manage to do a hackathon for a week once per year. 

When writing this article, our engineering team is less than 10 people, so we have enough time and capacity to dedicate one Friday every three weeks to the ideas our team has. We encourage everyone to think of a topic before the hack day starts, so that way they’re ready to jump into testing a hypothesis, building a quick prototype, or trying out ideas there’d normally not be time for. 

Again, thanks to our small team size, we’ve been able to have a lot of fun over the years with numerous hacks maturing into systems we’re currently using in our daily routines. 

You can expect it to be quite different from a traditional hackathon, though, which would require the whole company to gather in one place for a week to brainstorm ideas. Our hack days build on the creative freedom of our team, and they’re tailored to work remotely, so no one has to come to Berlin. 

# What we work on during a hack day

Because of our small team size, we tend to work on micro-projects that a single person can complete in a day or so. It’s up to each person to decide what the micro-project will be about which is the most important part. 

The day begins with everyone sharing what they’ll be working on and ends with everyone presenting what they did or discovered. In the past, these micro-projects have turned into things like press releases, blog posts, new internal tools, or just skills that you wouldn’t otherwise have time to develop. 

Since we have hack days once every three weeks, these micro-projects can actually be used over time to work on something much more substantial. In the end, any given year would have 15 - 17 hack days which is about three weeks of pure creative freedom to test ideas.

We’ve been inspired by other companies like Spotify who have used their [annual hack week](https://newsroom.spotify.com/2021-03-19/spotifys-2021-hack-week-focuses-on-making-space/) to create well-known features like the discover weekly playlist. Giving people the space and opportunity to be creative can have a huge positive impact on customer experience. 

# Are there any rules?

While we don’t set many rules, the ones we do have are pretty much just common sense. First, your micro-project has to directly or indirectly contribute to the customer’s and/or team’s happiness (as well as to the company’s success).

And, although hack days are a great time for conducting research and learning new things, we try not to read books or watch videos online. This is something anyone could do during any point of their day (maybe while washing dishes or even hanging up laundry), and hack days are a time for actively doing something that you’d otherwise not be able to do.

What about clearing the backlog? It would make the team happy, but there is most likely a reason a project has technical debt. That’s because technical debt requires a lot more collaboration and QA processes than your average hack, so we prefer to spend an entire sprint dedicated to it. Technical debt also has a whole week blocked in our calendars every three months, and it deserves a separate blog post that will come later.

# Want some examples of Feather hack day projects?

## Dirty Swan

We built and open-sourced our design system during one of our hack days. You might be able to tell from our website and motto that design is pretty important to us since “simple, honest insurance” means cutting away at messy UI. 

One of our main grievances with the insurance industry is that it’s just too complicated too. So, we decided to give our simplicity to those who needed it. 

You can check it out here: 
https://dirtyswan.design/

## Our developer onboarding guide

One of our junior developers built this crucial document shortly after joining Feather, and it was immediately put to use by other newcomers.

## Migration to Customer.io

At some point, we realized that the notifications we send to our customers are becoming hard to manage and require a developer to be involved in every change. The solution to this problem came from a hack day: we switched from Sendgrid to customer.io and moved the hardcoded email logic to a clean event-driven architecture.

## Feature toggles

In one of the recent hack days, we’ve introduced [Unleash](https://www.getunleash.io/) to manage our features in production. At any given time, there can be multiple unreleased features that would have otherwise blocked the main branch from shipping new code to production. From now on, we hide them behind a feature flag, and it has dramatically simplified the releases.

## Set up development snapshot automation

We’ve implemented a tool that restores the staging database in a local environment. We’ve been eyeing [Snaplet](https://www.snaplet.dev/) since its [early release](https://www.youtube.com/watch?v=wtenHeq2asI), and decided to give it a try. We might not use all of its features and replace it with an even simpler tool, but for now it works like a charm.

## Numerous internal NPM packages

We are regularly extracting a lot of internal tools from our code and publish them through Github Packages as private and public NPM libraries. A lot of this work is done during this event, and it’s always a safe bet when you don’t have a bigger idea!

## E-mail signature tool
We’re pretty huge believers in diversity and inclusion. That’s why we not only build an automated signature tool that the entire company uses, but we added pronouns as well to make sure everyone is included. 

# Interested in learning more about the engineering team at Feather?

This article is part of our internal documentation at Feather. We build our product in the open and share our learnings with the community. We're always looking for talents to join our team check out our [careers page](https://feather-insurance.com/careers/senior-backend-engineer).

Alternatively, you can check out [our blog](https://blog.feather-insurance.com/) for our most recent articles!