by throwarayes on 2/20/24, 9:42 PM with 53 comments
To do a hackdays successfully, I find good projects have already had a lot of personal upfront investment before the hackdays project. The hackdays project then assembles a team of potential labor that might (or often not) accelerate the idea to a demo. And then, even if there's a snazzy demo, you have to engage in a tremendous push after the hackdays to turn them into successful projects.
I can just as easily spend my time doing this in normal planning channels. And instead of hackdays, maybe we should encourage prototyping and demos to be part of the normal planning process, not some out of band activity likely to screw up schedules and deliver nothing.
Please, companies, stop these mandatory corporate fundays. And just fix your normal planning processes.
by Jemaclus on 2/20/24, 10:06 PM
So with that in mind, as a leader, I view them as opportunities for sanctioned on-the-job learning. I would hope that you spend the time automating existing processes or learning a new technology that might be useful. At our most recent company hackathon, we focused on a new way to do the old thing. Everyone could build basically whatever they wanted, but they had to use the new tool to do it. Not because we want the output, but because we want everyone to feel comfortable with the new tool. There was zero expectation about turning anything into a production project, although we did have two projects come out of it that are likely to go to prod soon without disrupting the roadmap.
I get where you're coming from, and I agree wholeheartedly with your assessment. If your work is doing hack days, and then getting mad because features aren't shipped, that's pretty shitty of them. Might want to try and find another place with better culture -- easier said than done!
by wilg on 2/21/24, 2:51 AM
If hack days are used to prototype work that's definitely going to be done anyway, that's a planning problem. (You'll have to figure that out with your company.)
If people are investing work upfront just to make a good impression at hack day, that's a cultural problem. (You'll have to figure that out with your company.)
But generally, just relax and do something creative and fun and low-pressure.
by karmakaze on 2/21/24, 12:37 AM
A couple of hackday projects were proof-of-concepts that eventually made it to prod, in a very organic way. Other teams would learn what was done and adapt it for their needs. They do sort of play out like R&D playtime. I was so lucky to have started my career at companies that actually did software Research as well as Development.
by drekipus on 2/21/24, 2:22 AM
Often it'll be a case of "hey this table is actually searchable now" or "that page is now split into two" or "I removed a tonne of deprecated code"
It's actually really enjoyable in my company, we all like it. My only issue is that I rely on structure, and given "free-reigns" I tend to pick too big of a thing that I can't get done in a day or two, and I end up doing too much = nothing at all.
I usually use it as a "level up" day (which we also have, so I get 2) which is just a day to go learn something new and level up your skills as a developer.
I think the issue isn't so much the "hack day" but rather your company is trying to get more golden eggs out of it, rather than looking after the goose.
by elintknower on 2/21/24, 12:57 AM
I thought hackathons were dumb in college (most people just cheat and bring pre-baked projects) and it's still dumb after that.
If you want to get out of it, just send an email explaining your health and productivity is implicitly tied to your sleep. Worst case just do what I did and get a doctor's note that staying up too late for non-work essential tasks is damaging to your physical well-being.
by jjice on 2/21/24, 2:23 PM
The best speed/quality ration of features came from hackdays for us because we actually cared about what we were implementing.
by skp1995 on 2/21/24, 11:29 AM
When I was working full time, my idea of "hack days" changed quite a bit. I took it as time to work on the weird idea in the back of my mind. My demo's were not impressive by any means but I learnt quite a bit out of it. I also think its part of the team dynamics, some teams embrace hack days while others do not. Think if the tech lead of a team actively encourages hack days the vibes would be completely different say compared to just doing your day job and planned activities.
by sounds231 on 2/21/24, 12:55 AM
by infotainment on 2/21/24, 5:21 AM
At my old company, people would often go and work on projects that were somehow meaningful to the business. It's no wonder people like that didn't enjoy it. Go work on a VR first person shooter game based on your company's mascot; that's what's gonna get the votes!
by catchnear4321 on 2/20/24, 10:00 PM
if you include the hackday as a day that counts towards velocity, then you will fall behind. because that’s hackday. if your scrum master is doing this, call them out on the dishonesty. make it their problem. let them complain about the velocity hit, and you have some hacky fun.
ultimately you have to make the call - are you too fed up to collect that paycheck? or are you comfortable leaning into the insanity for a buck?
by elpalek on 2/21/24, 4:38 AM
by 082349872349872 on 2/21/24, 5:38 AM
by paulcole on 2/21/24, 2:04 PM
If you hate hack days that much, interview and find someplace to work that doesn’t do them. Or help your company “just fix” their normal planning process. Or take PTO on hack days.
You’ve got plenty of options. The idea that the company has to change to make you happy is the wrong way of looking at it.
by roarcher on 2/21/24, 4:47 AM
by JohnFen on 2/21/24, 5:54 PM
by swman on 2/23/24, 8:31 AM
by anemoiac on 2/21/24, 11:20 AM
by kypro on 2/21/24, 12:14 PM
Specifically instead of running hackathons just give a team a very open ended business problem and ask them to investigate how they can use tech to improve or solve the problem. Give the team a month for an initial investigation and if they come up with something interesting provide them time to develop a POC.
Hackathons in my experience just end up with people rushing into mostly useless POCs because they neither have adequate time to investigate a problem or the time to actually build something interesting. You'll generally just get devs building things that already exist with whatever the new hot tech stack is at the time.
I'll also add that corporates generally do these things because a management consultant like McKinsey told them it's a good idea. It's the same reason why agile is so poorly implemented in corporations because they have no real care or understanding of it, they're just implementing the guidance given to them to the letter.
by koliber on 2/21/24, 9:47 AM
You can sit down and plan out a route along the map. That will work. You'll find a way to get there. It will feel safe and controlled.
You can also wander, drop into an alley, and potentially find a shortcut through a park. That path was not on your map, so you would not have found it had you followed your map. Along the way, you might discover something that will make your trip memorable and unique.
Many companies follow a planned approach to feature development. The draw up a map, and then follow it. A hack day allows people to wander around the idea space and solution space unencumbered. Sometimes, a hack day brings forward a shortcut, a novel idea, or shows off a piece of functionality which would not see the light of day with the traditional approach. Often, it's a matter of catching someone's attention by showing them a good idea™ in action. Companies are sometimes in a rut, and a hack day creates a chance for new things to surface.
Are hack days fun? For some people, sure. For others, no. Do they serve a business purpose? Absolutely. It isn't all fun and games, even if it feels like it.
I have personally seen "hack days" accelerate concrete and valuable functionality.
by whoopsie on 2/21/24, 2:19 AM