Hackathons and fixit weeks are bandaids to deeper problems posted on 04 July 2024

Hackathon and fixit weeks are fun weeks in my opinion – it’s a time where you usually park your usual work on the side and build/fix things. So usually your week is lighter on meetings and you get to write more code (that’s what software engineers like to do right?)

With that being said, the need for such weeks (especially fixit weeks) reflects a deeper problem – engineers don’t have the flexibility/time to hack/fix things during normal time. This is problematic because it’s more efficient to regularly address minor tech debts than waiting a long period and doing a massive rewrite.

Leadership is also often too far from the code to grasp the right balance between tech debt and productivity in many low level situations – the right people to make these trade offs are engineers on the ground, but if they are not given the opportunity/time to perform these tasks, no tech debt is essentially addressed on a regular cadence.

Hackathons are slightly different though – while I think people should hack a prototype anytime the project is impactful, hackathons also serve as social events. Hackathons are an opportunity to work with people you usually don’t interact with. So even if people are entitled to build a prototype at any time, there’s still value in having these social events. It’s a slippery slope though where engineers might naturally wait for the hackathon rather than building their prototype when they need it. I personally regularly build minor tools to make my life easier and don’t wait for specific weeks – but I’m also given the freedom and responsibility to be perform impactful work that many may not have.

What are your thoughts on hackathons/fixit weeks?

LinkedIn post