Recently, some clients asked us about our opinion on a newly released framework. To get a better idea of it, we ran an internal hack day — here’s how!
Stay tuned for the second part about our experiences with running Jetpack Compose hack day!
What’s a Hack Day?
Basically, a hack day is a one-day event where you can work on whatever. This is awesome for exploring a new technology or just doing something different once in a while! There are no rules except for that what you’re doing should probably be kinda related to your work, but it doesn’t have to be!
Why you should run a hack day
There are lots of reasons to love hack days — I’ll focus on a few. The benefits will always be a different depending on your company, team and the tech you are working with.
It helps people break out of day-to-day work life
A hack day can enable working with different people and build connections
If you do it right, people will be able to relax a bit
A fun breakout
First off, hack days are a great thing to break out of day-to-day dev life. Project fatigue gets everyone after a while. Maybe the work is not mundane or boring, but working on exactly the same thing every day can get tedious. The longer you work on a project, the harder the challenges become and the longer the cycles of success/no success become.
On a hack day, you will be working on something entirely different, without any expectations. This makes it a lot easier to learn, takes some pressure off and can be very satisfying.
Teamwork!
Teamwork
Since a hack day is a defined space and time for folks to work on something, this makes working together a lot easier — you’re there anyway!
Working on something alone can be nice, and maybe that’s exactly what somebody is looking for. For others, learning together is a lot more fun and more memorable.
Interacting with folks from different teams
In our case, we had people working together who normally work on different projects. This helps create connections and makes the team grow together. Plus, working with new people, chances are you’ll learn a new thing from each other!
Hack Day vs. 20% Time?
The above reasons & benefits are all great, but can mostly be easily applied to 20% time where folks can learn on their own. Both are great instruments, but they aren’t mutually exclusive. Running a hack day doesn’t mean you shouldn’t provide time for individual learning or the other way around — they complement each other.
“So why can’t everybody manage learning on their own?”
People should be able to learn during their work hours and have time to explore cool things. The reality is that it takes lots of encouraging and works best if there’s a defined space for it — otherwise, some people are often too shy to take time. Or there’s a lot going on in the project and it’s just all too much. It’s similar to “unlimited vacation” policies where employees tend to take less time off because there is no “framework” or baseline. It works well for some, not so well for others. This is why a hack day is a great instrument to define a space for learning something new.
How to run a Hack Day
You can find a checklist for this at the end of this post.
It’s preparation & planning time!
Preparation Time!
Goals
As one of the first steps, define the goals of your hack day. Ask yourself why you want to run a hack day. Do you want to focus on strengthening the team? Do you want to explore a new technology? Did everybody have a stressful time and you want to provide some breathing room?
Defining your goals helps you justify the cost of running the hack day with management and makes it easier to plan, e.g. when picking the topic or motto. It’s also nice for the participants to know what to expect and why you are running a hack day.
The audience
Who should be part of the hack day? Android Devs? iOS Devs? HR?
In some cases, it might make sense to restrict the audience, e.g. if you’re looking to strengthen a specific team. In most cases it makes more sense to have the hack day open to everyone though — maybe an iOS dev has been wanting to look into Compose and Kotlin for a long time, or somebody from HR is interested in picking up programming (again).
We always have our hack days open to everyone, but from experience, only devs join without personal outreach.
Joining should also always be 100% optional. Don’t force people to join your “fun” event. Enable as many people as possible to join, but also enable them doing a small hack day on their own at some other time.
Time & Date
There should be enough time for everybody to make sure it fits into their schedule and for you to prepare. Announcing it two weeks to a month before is ideal. Fridays are great days for hack days because they are chill and it provides a relaxed way to get into the weekend.
Picking a topic/motto
First question: Do you even want to have a topic? You should be able to figure this out by looking at your goals. If you don’t want to provide a lot of guidance and just have a free roam day, you might want to pick a motto instead, e.g. Digital Wellbeing.
It usually makes sense to pick a topic or motto for the undecided folks (I’m one of those). It can help inspire or find a thing to work on instead of taking ages to decide on a task before actually starting. Working on that topic should never be mandatory though.
Picking a topic seems like a hard thing, but it doesn’t have to be! Either you can just flat out decide what the topic will be, e.g. Jetpack Compose if that’s something you want everyone to take a look at. Or you can have everyone decide together: Run an open poll with some pre-defined options, go with the majority vote. Both ways are totally fine, but keep in mind that everybody should still be able to work on something entirely different if they want.
Announce
Well, y’all know how Slack etc. work. We usually shoot a message in our general channel and ping @everyone in our Android/iOS channel.
Don’t be disappointed if you only get a few responses — folks are busy. If you think they’d be a great addition, reach out to them in a DM! Chances are they’re just busy and didn’t have time to respond yet.
Make a schedule
Pick a start time! 10 am is great, it’s chill and enables folks an hour behind or an hour ahead to join easily.
Pick a (soft) end time. It’s supposed to be relaxed, so don’t do later than 4 pm.
Ok, these were the obvious ones. What about all the stuff in between?
If you have a specific topic like a new technology, have some exploration time — two hours worked great for us. In that time, everybody can read up on things, watch videos and get a general grip on the topic.
After that, the hacking can (officially) begin!
Keep in mind that nobody should be strictly bound to this schedule, it’s just a general suggestion. If somebody wants to read up on things all day, that’s cool! If someone wants to start hacking at 10, heck yes! It does make sense to outline a schedule though because it’s easy to get sucked into watching conf talks or coding alone all day.
Here’s what a schedule could look like:
The schedule for our hack day.
Put together resources
If you are organising the hack day, chances are you are experienced enough to take a quick glance at existing resources and put together a list. We organised them by level (Beginner, Experienced and Advanced) to make finding things to look at easier. Doing research on a topic is cool and all, but it can easily take a good amount of time, so it’s not something you want folks to waste their time with — a day isn’t that long! Providing a starting point can make getting into something new a lot less frustrating, too.
If you are unsure where to start with compiling that list, contact some experts for that topic — they will probably be super happy to help!
These resources can also include sample projects and possible ideas of stuff folks can build.
We posted our links in a Slack thread so everybody could add to it.
Last but not least
Outline what’s needed to participate (e.g. specific versions of software). Nobody wants to be stuck setting things up while all the others are already hacking!
Be clear in your communication, but not pushy. Being pushed reduces fun.
If you want, provide a “breakout room”, e.g. by setting up a calendar event for the duration of the hack day and adding a Google Meet/Microsoft Teams/Zoom/Whatever call that folks can join at all times. These make for fun conversations if somebody else is in there!
Okay, got it? Are you well prepared? Let’s do it!
The Day Of
So here we are! Start off with a welcome message or a small optional kick-off call. Talk to people and gather their expectations and what they want to do. Encourage asking questions and working together on things.
When the start time for the official hacking part comes around, make a smol announcement and have everybody continue to go about their day. Now is a good time to ask if there are any questions so far. You can also have a short call to talk about what everyone thinks so far — that’s especially useful if you’re exploring a new technology.
Encourage pair coding! Offer to work with someone on something — this usually makes learning a lot more fun and you’ll both learn a lot. In my experience, you have to be active about pair coding. Some folks prefer working alone, but some also feel like they aren’t experienced enough e.g. with the new technology you’re trying (yay impostor syndrome), so it’s better to offer it once more.
At the end of the day, meet in a call or in chat to discuss what you’ve learned and what challenges you’ve encountered. If anybody wants to present what they’ve built, encourage that — it’s a great experience to show that off :)
It’s done! Have some drinks 🍻☕️ 🍵
After the hack day
So you ran the hack day! Great!
There are a few things left to do:
Gather feedback. What went well, what can be improved?
If you worked on something together, bring it into a state where you can pick off where you left at the next hack day!
Find the date for your next hack day :)
In addition to this blog post, we added some example messages and sample resources on Jetpack Compose in a repository. It also includes a checklist for before the hack day. Find it here!
What was your experience running a hack day? Let me know in the comments!
Oldest comments (0)