Hack days 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!
At Feather, we have a tradition of hack days. This is a regular event that takes place on Mondays, every three weeks. It's the perfect time for testing hypotheses, building quick prototypes, and trying ideas outside of our daily capacities.
We've had lots of fun over the years, and numerous hacks matured into systems that we use in production and in our daily routines. We came up with a process that is affordable and doesn't require a lot of organizational effort.
It's quite different from a traditional hackathon which would require the whole company to gather in one place for a week to brainstorm ideas (although that can be great too!). Our hack days are autonomous and distributed, and they work great with a remote team.
What to work on?
The project you pick for the hack day is completely up to you, as long as it is related to Feather. This is a perfect environment to test your own ideas or learn a new skill, but it’s also a great opportunity to collaborate with others.
This type of work can be very exploratory, so it’s important to put some constraints on it. It’s a good idea to focus on projects that you can deliver in one day, from start to finish. However, it’s not uncommon to work on the same idea for a few hack days in a row, especially if you hit a wall the last time.
A typical hack day project is a proof-of-concept for a new tool, technology or approach. For example, if you believe that we will benefit from introducing a new state management library on the frontend, you can spend a day to open a PR that demonstrates the benefits of the new approach.
Hack days are also a great way to make progress on your areas of responsibility or career goals that were defined in your feedback sessions.
The hack day pot
We use Notion to organize hack day projects and ideas. Each project has its own dedicated page, featuring a brief description of the problem and a proposed solution.
Everyone in the company is encouraged to contribute ideas. When someone creates a new page, a Slack notification is sent out – this serves as an open invitation to consider it for your next hack day project.
During hack day, any progress or discoveries you make should be documented on the project page in a “log” format. Include screenshots and detailed descriptions of what worked and what didn’t.
To make the process easier, we use the template below. It provides a structured outline and helpful prompts to guide you:
# What’s the problem?
*Write a short summary of what you’re trying to solve*
# Explored solution(s)
*Explain the solution that you’ll try to implement. If there is more than one possible solution, list them here*
- Solution 1
- Solution 2
# Current status
*What’s the current status of the exploration?
Try to keep this section up-to-date to make it easy to know what are the next steps*
# Next steps
*What are the next steps to keep working on this exploration?*
*This section should make it easier for you or other devs to pick up where you left off.*
*You can also remove this section if there are no more steps left.*
# Log
## {{CURRENT_DATE}}
- …
- …
Hack day outcomes
If you do the maths, a team of 10 devs that runs 15 hack days a year can easily end up with more than a hundred individual projects each year. Not all of these projects will yield groundbreaking results—and that’s perfectly fine. Some will lead to incremental improvements or serve as valuable learning experiences, while others may not succeed at all.
That said, we’ve seen many hack day projects evolve beyond the PoC stage to become essential parts of our product and company. Here are just a few notable examples.
Dirty Swan
We built and open-sourced our design system during one of our very early 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. You can check it out at dirtyswan.design.
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
At any given time, there can be multiple work-in-progress features that would block the main branch of the repo from shipping new code to production. Feature toggles, also known as feature flags, are a typical solution to this problem. It took us one hack day to evaluate existing SaaS and open source feature toggle services and settle on a self-hosted Unleash instance, and we’ve been using it ever since.
Moving to an open source CMS
As the company grows, so does its SaaS bill. Sometimes it is justified, but a few times we’ve ended up in a position where it would be cheaper and easier to self-host a perfectly good open source equivalent than to pay for a SaaS tool.
Recently, this happened to the CMS – let’s not mention its name – that we’ve been using for years. After a quick hack day experimentation, we realized that Strapi is available for free, can be self-hosted and extended easily, and would provide us with even more flexibility than we had with a paid tool.
How do others do it?
