The Right and Wrong Ways to Have Hackathons for Devs

Transcript is auto-generated and may contain errors.

Hey folks, we're going to go to the experience dev subreddit and we're going to talk about hackathons. Um, this post was kind of framing it as a question around um around product management hackathons. Pardon me one sec. And like the the open question being, you know, if you have hackathons, does that imply that um that you're like product managers are prioritizing the wrong things? And so I thought this would be an interesting one to talk through because um the word hackathon means a bunch of different things to a bunch of different people. And I this is one of those topics where I think if you were to just express an opinion about hackathons, right? Like if you agreed or disagreed with what this person's saying, I think that you could have the same I don't know scenario and pick either side of it. But I also think that there's many different scenarios that when we just talk about hackathons like what's actually happening.

So, um I I always find topics like this are super interesting because we can actually break down like different variations in this case of what a hackathon is. Uh talk about the pros and cons of those things and then really kind of notice that this question itself is kind of like it's making an assumption about uh some things which may not be true. So, just a reminder for this channel, if you uh have questions about software engineering or career stuff, leave them below in the comments. I'm happy to try making a video response for you. Otherwise, you can go to codecommute.com and submit stuff anonymously and I'm happy again to make a a video response for you. Okay, so hackathons, um just for context, I have done this kind of thing uh at work at a startup. I've, you know, we do this at Microsoft quarterly.

Um, at least in uh Microsoft 365, it's quarterly. I think Microsoft globally has them twice a year and they're week long. When I've done them at a startup before, uh, we did 24-hour hackathons. Um, you might already have questions when I say 24-hour, like what does that mean? Why is there time allocated that's outside of uh work hours? Uh I've done uh while at the startup we did a hackathon sponsorship. So I got to kind of go and be uh be a representative for our company uh operating a booth and then going around and like helping out people that were working on their hacks. Uh so I've seen different sides of this. I am certainly not um like a hackathon expert. I I'm it's not like a a thing I do regularly uh as a I don't know as a hobby or someone who's like actively participating in these all the time.

So uh I'll be sharing more about like my my perspective on them from like a a work setting. So um when we talk about hackathons I think there's a a handful of things to consider right it's like one is the intent because I think that varies dramatically I think one is the timeline and the expectations so there's a bunch of different factors that we have to consider here um let me let me talk about timelines right because I think this is an interesting one uh I think there's something to be said about having compressed timelines for hackathons and the reason I say that is because I think there is like when we're thinking about engineering uh in general engineering we're always focused on different constraints and optimizations within those constraints right so um there's always going to be more than one solution to things doesn't mean there's uh you know more than one good solution but I think you could solve problems in different ways.

And so given that you can solve problems in different ways, it's about optimizing within your constraints. And I think something that's interesting is that when you shorten the duration of a hackathon, you're imposing a constraint, right? The constraint is the time. You don't have a lot of time. So what can you do if you have a goal, right? If you have a a big challenge that you're trying to overcome and not a lot of time to do it, something interesting that I find happens. I don't have like data to to back this up. It's anecdote, right? It's not like I have stats. Uh but I I believe and have you know my observation is that when you have big challenges in a short amount of time, you have creative solutions. It doesn't mean that you end up having, you know, the best written code that's ever happened, but you have like creative solutions, right?

You have these really difficult constraints, right? Hard problem to solve, not a lot of time to do it. Okay. So, like it kind of forces you to be creative because the reality is that I think for a lot of us it's not well I guess we just fail and give up. It's no like we're going to we're going to try things to see if we can make happen. So I think the the time constraint is super helpful as a factor, right? I think in my opinion this is a really important thing to consider. Now one of the tricky things is that when we have time constraints, this is like we have to factor in that what we're talking about is work, right? A hackathon is work, right? Uh at least in this context. I'm not talking about like I don't know like hackathon events that you go to outside of work.

I mean work sponsored hackathons. It's work. And so there there's a whole debate you could have here around like, you know, some companies might say, "Oh, we'll let you do a hackathon, but it's not a you know, that's not going to count uh as work hours, right? like it's extra. In my opinion, that's the wrong thing to do. Um, we can I'm hoping to kind of touch on this more after, but the the limitation that we're going to kind of get stuck with is like we want to compress time to kind of force creativity. But then one of the challenges is like well to give you an example uh some of the if you're working in larger companies and stuff like that uh there might be a lot of red tape to get through to get some things set up. So you want to go hack on stuff but just to get permission to some system or whatever else.

Maybe you're already like, you know, you're blocked completely because the the process for reaching out to some different org to get some permission is like, I don't know, takes hours or I don't know, whatever it is, there's going to be all this red tape for different systems to kind of get to a position where you can even start, right? So, like, okay, so do you extend the duration of the hackathon to account for that? Do you um you know do you tell people ahead of time like hey hackathon date like make sure you have all this stuff set set up ahead of time like there's ways that you can kind of work around it but my opinion is that the the longer you make the hackathon in terms of uh like number of days then I think the more you get into uh this situation

of like you're you're relaxing the the time constraint like benefit Um I think the other thing to consider too is like say say at Microsoft and this would be the case for lots of companies but if you have you know lots of people or you have uh cross geo teams and stuff like that people in different time zones like the reality is that if you made it a 24-hour hackathon right or just let's simplify it the hackathon is on one day if we're talking cross geo let's call it 24h hour just because it's some allocated period across the world if you have a situation like this like it's really really really challenging because the amount of I don't know like availability for people is reduced to a single 24-hour period right for those of you that work on cross geo teams uh or you interface

case with lots of teams regularly, you may have noticed that sometimes it's extremely challenging to get uh a time slot booked for a meeting or something with with lots of people, right? So, you know, trying to go across a company or an organization and schedule something like that is uh is of course super challenging. So I can understand, you know, expanding it to a week or something like that maybe to help give you more more room for overlap, but I think this is just a consideration around hackathons is like how do you structure them from the time perspective? Uh back to the 24hour thing, right? This one is kind of uh I don't know it's it's tricky because when we did this uh at Magnet Forensics where I was before Microsoft uh especially in the beginning like I think it was a hard cell for us to be like we should do a hackathon because there was this and this is where the conversation is going to head to.

There's this kind of feeling of like, well, are we just going to let people work on random stuff? Like, they could work on anything. Like, that's not like we're a startup. That's not a really good use of time, right? Like, shouldn't we all be focused on that's got to get done, right? It's a it's a startup. So, there was this this conversation around like, well, what what is the the point of doing the hackathon? like what is the intention? I will continue that a little bit more later. So that that idea of like even getting buy in was challenging and then well you know well how much time are you actually asking for for this right? It's like, well, just just one day, right? It's it's one day. Maybe we'll do this quarterly. Maybe it'll be, you know, twice a year, whatever it is. It's not it's not every week we have a hackathon.

So, like, could we get a day to do this? And it's like, okay, that's fine. Yeah. Like, we'll make it happen. But then we realized like back to this time constraint thing within the workday was like challenging, right? Because yes, it's a work day. Yes, it's a time constraint. Back to what I said earlier, you might say, Nick, wouldn't you argue that would allow you to be more creative? Um, yeah, I don't know. Um, I think that from our experience, at least my lived experience through that was that having the workday to just like, you know, sit down and like try to, you know, crank something something cool out then for us it was supposed to be anything, right? did not have to be explicitly workrelated. You can work on anything because the goal the goal was to be learning, right? It's a it's a morale event.

It's a learning event. It's like how do we get people together uh to work on hard problems together, but you can be creative and learn about sort of any domain you want. Um, what I found at least was that you'd be you'd get people together. We'd be like, "Okay, like we have this here's what we're going to do. We're going to make this happen and we're working on it." Like, and it's super exciting, right? Time is flying by. You'd reach like you'd look up and it's like there's like an hour left in the day and we're like, "Well, we just want to keep going, right?" So what ended up happening is like these hackathons we would we would make them over 24 hours and that wasn't again cuz you're like well that's that's a shitty idea because you're going to have people you know they're

doing work for 24 hours and it's like the point like you didn't have to no one was forcing you to stay later but it was actually like because it's over 24 hours we will have food and activities and things like that after hours for you because if you want to hang around and work on your stuff then hell yeah like please feel free we want to support you to go be creative and learn and work together right so it's optional the company like for the company it's not optional like there was HR supporting us through it right uh people would like like there'd be volunteers to kind of stay late and and help out with it so that was all tremendous, but it's not like we forced anyone to go do that, right? So, if if it was agreed that like people were like, "Nope, 5:00's going to hit.

I'm going home." Like, okay, at least the option is there, like, you know, if you want to work on stuff, we will have activities and food and all that, but you don't have to. And um I I thought it was a ton of fun. Um I think it was really cool that people would go run different activities. There was like yoga. Uh, I feel like at the time there's like rock band and whatever else. Like just lots of fun stuff. But it was, in my opinion, it was a good way to to bring people together, give them enough time that you're not cutting off like their creative focus. Um, and it's I don't know like I I don't know what the magic number is, but I feel like if we would have capped it for like the eight hour workday, yeah, we got stuff done,

but I I often feel like people were maybe by that point in time just starting to like hit some cool momentum and be like, "Okay, like we see it coming together. We really want to get it done." Um, but yeah, I I I guess my personal take on that is like I think if you force people to work 24 hours or like that's the only way it's going to happen is if you're you're working extra time, I don't think that's fair because this is a worksponsored thing, right? The the intention is not to make people work longer. Um, the intention was that if you're sort of in the zone and you want to keep going, then like then we we want to make sure that you have an enjoyable experience doing that. Okay, let me let me kind of shift a bit to talk about the intention because I think that's more of like what um this ask was about on Reddit.

So hopefully so far I'm kind of framing some things up for you. Right at just for what it's worth at Microsoft uh the hackathons we do are are week-long. Like I said there's two global weekl long hackathons and then in Microsoft 365 there's another two on top of that. So we align two with the global and then do two extra. They're a week long. Um I I don't honestly for the global ones I'm not sure. I think they fly some people around and stuff. It's not um it's not like everyone in the company is flown around, but I think that there's some teams that use that as an opportunity to like uh to colllocate stuff like that. Uh but yeah, there there's there's a there's more that goes into the global ones just because it's uh it is companywide. I just don't know, honestly, I don't know all the details of what those extra things are.

Um, I know that for, you know, for us doing hackathons when we participate, I don't think we're doing anything out of the ordinary um, like extra support events, things like that. There might be, in fact, I should say there probably is, but I just I just don't know. Um, personally, I feel like the fact that it's spread out over a week, I'm I'm not really super focused on that. uh on the extra stuff. Now, I will talk more about the intention right now because I think there's a there's a very big difference in how we were doing hackathons and how they're done at Microsoft and probably um I wouldn't say they're at polar opposites, but I think they're different and there's probably space in the middle and space on either ends.

So at Microsoft when we're doing our hackathons it's called fix hackle learn so FHL and so I don't know if the global one is called FHL it might be called the global hackathon and maybe the Microsoft 365 one is specifically called FHL but it's fix hackle learn and so the learn part is supposed to be open-ended learning right so what's really cool I love this because if you think about uh big company like Microsoft and I'm sure I'm not saying we're the only place that does this but like because it's a big company and there are lots of uh you know super smart people they do a lot of learning sessions so they send out an agenda that's for the entire week if you were to look at any time basically any time of day there's a learning session that you can go tune into and learn about tons of different things right especially now there's lots on uh AI related things.

Uh not everything is specifically tech. There's some stuff that's like uh maybe more on like leadership, soft skills, different experiences. Like there's there's so much going on that if you're like, I want to take this week and just not specifically code things or build things, you don't have to. You can tune into all of these really cool learning sessions. And I think that's awesome. Um, but that is in the spirit of what we were doing at Magnet Forensics as well, right? Like take this opportunity to learn because that is one of the goals. But I would say one of the big differences is on the the fix and hack part. Uh at least for for my time at Microsoft, it's very much been like this is your chance to like to kind of dabble in some of the uh maybe it's with different teams and participate in different areas, but it's going to it's likely going to be product focused.

And so to me that's very it's on the actual building part like the the fixing and the hacking that to me seems a lot more like we are aligning to uh very specifically to like to things that we're already doing. Right? So maybe there's this opportunity where you're like I want to prototype something that we've been talking about for a long time. I'm going to go do it. Right? Uh or I've had this idea where we could refactor something or rewrite something. like I'm just going to try my hand at it. Um or uh you know especially now with with so many different things for AI like I want to try using AI build an agent do whatever for this scenario that we experience and uh hopefully it's a helpful thing and we'll learn about it. So there's a lot of this kind of stuff going on but very much like work focused.

Now at Magnet Forensics it's not that we had nothing that was work focused. There were some people that were like, "Hell yeah, like I have a really cool product idea and I want to like try building it or a new feature and I want to try building it into the product cuz I think this would be super cool." Um, and like they weren't forced to do that. People were just like they had the option to work on literally anything they want. So some people would they'd be like, I have a really cool idea for a feature that we I think we should build in and I'm going to go, you know, demonstrate that I'm going to go build it and show it off. And then others, like a lot of the time, I wouldn't do that.

Uh, I would try to go build all sorts of random like we built we built a an accidental horror video game where uh an Easter bunny would chase you and in Unity and we like kind of like goat simulator we kept in all the bugs. So this bunny uh was put in and when we first tried it it was like it was backwards. So this this horror rabbit would chase you backwards. um through like this I don't know this like crabby unity level but it was it was a lot of fun right so we built all sorts of stuff the I think that's a a major difference I see between the two is just uh sort of the focus but the learning part was very much common and I personally think that's a huge a huge factor that should be considered if you're focused on hackathons my take is that the intention should not to um to go try to squeeze more work out of people.

The intention in my opinion is learning. Morale and when I say morale, I mean like uh it's it's multifaceted cuz like learning opportunities I think is a huge part of that. Um that that includes like providing people resources, that includes letting people explore and that also means like teamwork, right? Um, so being able to work with your peers or work with other people that you don't get a chance to, I think there's a huge component to that where you can like you can really uh get this opportunity to work with others. Not that you should have to. It's not in my opinion should not be forced that you need to be on teams. You have to go work with other people, but it gives you this opportunity to do it. So my take is a lot of the benefits of hackathons are like these uh what's a good way to say this?

Like nothing about it to me should be a forced work thing, but it should all be about optional opportunities. That's how I see it. And that means that is a trade from the company. You're saying you're not going to be working on work things. And I personally think that such an opportunity uh given to employees is actually a tremendous benefit to companies. Even if you're losing a workday or you're losing a week, the benefit is like outrageous in terms of uh you know, I think if you structure them properly to to get morale up in different ways, right? you get people interested in technology, interested about learning, giving them the these opportunities where if they've been focused on projects, they can kind of zoom back out and say, "Cool, I want to like I want to go try this out." Um, I I think there are so many benefits that are uh sort of almost intangible, like I would say hard, probably not easy to measure.

um and it's not a huge uh time commitment honestly. Now given that in both cases I was saying you know at Magnet Forensics and at Microsoft we're going to have people that are doing some work things right you're going to have people that are I I wanted to go fix this. I wanted to go rewrite it. I wanted to make a new feature. Um, to this person's point on Reddit, does that mean that product managers are prioritizing the wrong things? Um, I think the answer is no. Uh, like you can't make that claim as a universal truth. I think that's unfair. Uh, is it possible in some cases? Sure. Right. Like I I think that's uh I think there are situations where a hackathon happens. Someone builds something and we go, "Holy shit." like we should we should go do that, right? Um I think that's a totally fair statement as well.

It's uh one does not sort of mean the other is impossible or wrong. But I I don't think it's a fair statement to say that just because you can have a hackathon and just because that can result in a new cool idea uh being shown, I don't think that means that product managers are therefore doing the wrong thing. Right? Prioritization is a very challenging thing. Right? You can we have to think about the inputs that go into prioritization. So do you have um you know customer asks that are coming in? Do you have from a business perspective are there uh like revenue opportunities? Are there are there costs that have to be uh figured out? Are there technology changes we need to account for? Like there's so much that goes into prioritization even from the product side. Uh and you know arguably like the tech engineering side even before we have the conversation of like you know who should be working on this?

Is this a single point of failure? Is this a learning opportunity for someone? Like all these other things prioritization is very challenging. So I think the the claim or the statement is is not accurate or not fair. But I do think that that highlights that if you're doing planning, right, if you're working at a company that does planning, you're working with product managers, product owners, whatever, if if you are never taking input from engineers and developers and the other individual contributors, if you're never taking that input, I think that's a huge miss. I think that's an enormous miss. So if planning conversations like what we should work on, if that only ever flows one direction, I think that's a miss. That does not mean for what it's worth, I'm not saying the exact opposite that developers, other IC's should only be the ones driving like they only have the best ideas.

we should we should immediately drop everything we're doing for what they're proposing. That's not the claim. So, uh it doesn't just negate everything, but I I think that there's a balance. And so, I think that sometimes when we have these opportunities, you get to see that someone under some really challenging constraints was able to get very creative and showcase something. And that might have been honestly because the business itself has been under a lot of you know maybe one part of the business for this team is under a lot of pressure for delivering things and from a business perspective when you're optimizing for that path and prioritizing that makes the most sense. When you interrupt that flow and then you introduce like here is something completely tangential to that. you may uncover that there's you know something very interesting there.

uh there's pro I'm I'm sure there's a word for this in in like computer science when you're uh you're iterate I wish I could remember anything from university you're iteratively solving problems and there's like a sort of like a through through optimization there's like a local minima or maxima that you're you're kind of converging to and in different algorithms you need some mechanism to kind of step you back out of that this is the case I think in some uh like genetic algorithms where you step back out cuz you're like, "Oh shit." Like, yeah, we've been hyper optimizing and that's been going well, but we were kind of like uh in a rut or, you know, some some local minima or maxima. So, if we step back out now, as we start to optimize and converge, we're actually hitting a uh you know, either a bigger peak or trough depending on what you're optimizing.

And I think that's kind of what we experience sometimes with some of these features or ideas coming out. we go, "Oh shit." Like, now that we see this, now that this feels more real, like I I wonder if we should shift gears a little bit. Doesn't mean drop everything. Maybe in some cases it does, but at least there's this opportunity where we can go, whoa, like what what should we do with this? Right? But again, that's a prioritization conversation that has to happen. And for what it's worth, just because it was built in a, you know, 24-hour hackathon or something and someone slapped all the together doesn't mean that go ship it, right? This is another conversation that would sometimes happen because it' be like, wait, we just did the hackathon and you proved you could do it in 24 hours and you're demoing it to us.

Like, oh my god, ship it. It's like, yeah, but you you might have forgot that to make this happen, we cut every possible corner possible, to have something to demo. This goes back to some of my other conversations I've had on this channel about prototyping, right? Just kind of doing something to answer a question. And I feel like hackathons aside from all these other benefits of learning, collaboration, morale um purely on like the the building part is very much like prototyping. And um I I just think there's lots of really cool stuff in terms of software development that comes out of out of prototypes, but you're trying to answer a question, right? It's always about trying to answer a question. And with a hackathon, it's like you have a compressed window of time to try and answer a question. Is something feasible? Can it be done?

So yeah, I think I think those are some of my thoughts. There's some other kind of points around like demoing. Um I think it's really cool opportunity to let people demo their stuff. I think I will always say this as someone who's been uh Oh man, my windshield has lots of pollen on it. Didn't realize. As someone who's been, you know, historically afraid of public speaking, um I think forcing people to demo what they've done is kind of shitty. And I think especially if the reason for that is like, well, we want to force people to do it to prove they were working. I'm like, uh, pardon my language, but you're a piece of if, uh, if you think that you can't trust your employees, you're going to give them some time to go, you know, that is flexible like that and you're like, well, I don't trust that they're going to use that properly.

Sorry. Like, that's a you problem. Um, because if you really don't trust your employees, either either you got the wrong employees or you're the wrong employer. Um, so I think forcing people to do that kind of stuff is shitty. I think giving them the opportunity to do it is great. Uh, lets people have have that opportunity to showcase stuff to if they want to speak and present, they can. If you can record stuff and share it, even better. Um, especially for cross geo teams, getting time alignment is terrible. But yeah, giving giving people the opportunity I think is super cool. Plus, it gives other people the opportunity if they're interested, they can see what other people are up to. Overall, uh, sorry that was tons of random ideas, but, uh, I love the idea of hackathons. I think they're incredibly important. I think time constraints are important.

I think being clear about expectations. My personal take is that um, hackathons should be used for for learning. They should be used for uh opportunity to collaborate, not forcing it. I think they're an opportunity to uh my opinion work on anything, especially if it's not workrelated and you're like, I just want to go learn about something. And I think that uh companies should trust their employees to use that time. If you're trying to, you know, uh chase people down to make sure there's a a paper trail that they were doing stuff. I just think that you're you got other bigger problems uh to begin with that aren't related to hackathons. And so ideally, you know, ideally people walk away from hackathons feeling energized, feeling like they got to learn, like they got to try something cool and or work with other people they don't normally. Um and that it there's a feeling of like excitement.

In my opinion, if you have some of those things at the end of a hackathon, I think that um there's probably it's maybe not a full success metric, but I think it's a a good indicator. Um and like with with anything, I think it's important to get feedback. So, if you do run hackathons or you're participating in them, um there should be an opportunity to provide feedback and see how things can be improved for the next time. Um, that's kind of unrelated, but I do I probably should talk about this more. I think anything we do should have a mechanism that we can continuously try to improve it, right? You run a hackathon, people are like, "Yeah, it was good." Okay. Well, do we do the exact same thing next time? Do we change something? What do we tweak? What do we try? Because if you're not trying different things, probably not going to keep getting better.

So, see you in the next video. Take care.