Aug 24, 2021 - JS
Hackday Speech
I love hackdays. A bunch of engineers get together and start vomiting code, and all the rules don’t apply. The goal is speed, just get something working. It’s not really about the code, it’s about the idea. I think during the first 5 years of my career, every day was a hackday. My first company was just a bunch of friends coding for money and having loads of fun doing it.
When I was “on the ruby scene” in the mid-2000s, it was pretty common practice at conferences to hack late into the night. Often people would pair up to rewrite some library or build a product in a day - after all, DHH did that, right? He’s awesome! Here I learned what it’s like to work side-by-side with someone you barely know, for like 10 hours straight, consuming pizza and caffeine and typing until your fingers ache.
The first time I attended a well-organized hackday - one with sponsors and prizes and proper demos - I was amazed. When you have good infrastructure and bit of planning, it goes to another level.
There’s a certain smell to hackdays. On day two especially. You know what I mean. I guess there’s advantages to hacking remotely these days.
I’m too old to stay up all night, but man it can be fun. I think you get smarter with sleep deprivation. Everyone is so tired by the time the demos happen, that it’s usually pretty funny.
I’m actually bad at hackdays. I like to say there’s two kinds of engineers: the ones who are fast and want to make it work, and the ones who like to think about the problem until they can get it perfect. You want the first kind in a hackday, and the second kind refactoring your codebase. I was definitely the methodical type, never finishing on time. TDD at a hackday, what the hell?
Hackdays at bigger companies are typically infrequent. Every time the engineers propose it, the product folks get uncomfortable and start calculating all the lost time on features. That backlog is pretty long, ya know. Do you realize how much a day of engineering costs!? We only have a three day sprint this week (glare).
But every single time, the demos are lively and inspiring, sometimes astonishing, and everyone is convinced that it was totally worth it. For the next week, people have a lot of momentum and are full of ideas. “We should do this more often!”, they exclaim.
But then the energy fades as we get back into our regular routines: planning, prioritizing, sprints, deployments, KPIs, and meetings. Lots of meetings. We miss the feeling of hammering out code, shouting at our teammates, and laughing hysterically as things come together (or fall apart).
Sometimes hackdays are really good for business - I’ve seen killer features go straight into production. At local.ch, spam number detection - one of their most poplular features today - was a hackday experiment. Ricardo’s message of sustainability came to life in a hackday. We’ve all seen stories like this.
It’s tempting to try to “steer” hackdays, by setting a theme or challenging engineers to solve real business problems. It takes away some of the creative freedom though, and you have to work in your old codebase. I asked our CTOs about this, and they told me “nah, just let people have fun!”, and looked at me like I was a corporate stool.
Hackdays are awesome. Especially the demos! So. No pressure, no expectations, make something awesome. The only rule is, you have to demo. Nobody dodges demos, that’s lame. Fails are the funniest, anyway.
That’s why I always tell people - do hackdays regularly. Once a month is not insane, seriously. Software development travels on sine waves, it peaks with output and dips into a stand-still as we clean up the messes. We can’t do things “properly” all the time, we’ve got to go crazy sometimes in a wild interpretive modern dance of software catastrophe.
So have fun out there, have a great hackday. And if someone complains that you should be working instead, tell them to talk to your CTO. See you at the demos!