As an engineer, my view on days/hackathons is pretty simple: you don't pay me enough for my good ideas. If I had an idea that could make the business $5M, I'm better off going into business for myself. Instead, I'm going to do whatever I can to try something new and different to learn

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!

As an experienced and seasoned engineer, this is exactly my view. Though as a new college grad I used to work overnight for hackdays. Now I see new college grads doing the same.

I get paid for a job and I do it really well. But, I don't get paid enough to overthink creative ideas, burn midnight oil to meet an arbitrary submission deadline that only benefits the company.

Not to mention that if I don't meet my OKRs, mentioning that it's delayed because I was working on a hackday idea wouldn't help me at all.

Whilst I agree that these hack days should be considered a learning experience this sentiment has annoyed me:

> you don't pay me enough for my good ideas. If I had an idea that could make the business $5M, I'm better off going into business for myself.

In a knowledge based role, your good ideas are exactly what the company is paying you for. If you have an idea that could make the company $5M it is very unlikely that it would do so sustainably and profitably in isolation as a new company. This is why companies exist, to pool efforts. I work for a company that has billions in turnover and I'm directly involved in decisions that affect our profit or market share and making decisions to save or create millions is a normal part of my job.

You are paid to create value for your company that far exceeds your salary. Maybe this doesn't apply to you but this attitude annoys me because I've had experience of working with colleagues who are unmotivated and coast along doing the bare minimum then complain that they are bored or never promoted. Often their colleagues end up picking up the slack. I understand that many people don't want to exert any energy in return for their paycheck but personally I spend about 6 hours a day working and prefer to put some effort in so that I enjoy it more. If you are unmotivated & unrewarded financially or intellectually then perhaps find a new job.

He sounds plenty motivated. He's willing to start his own business to chase a $5 million dollar idea.

In a knowledge based role, the company is paying you to churn out solutions to their problems because the technology stack is setup to serve the CTO's purposes.

He has to start a new company to change the setup.

Your annoyance sounds like sour grapes.

Exactly what GP and you are saying.

If I am not the CTO, I am just a servant (based on the word "service"), whom you are paying to execute to do what you deem needs to be done.

And no one reaches this level of cynicism in one day. Things almost always go the non-ideal way- week after week, month after month.

And most people are in employment because they have to. Most people aren’t passionate about their current employment.

Sour grapes at somebody's imaginary $5M business?

> your good ideas are exactly what the company is paying you for.

Yes, in a limited domain, this is true. However, my employer does not own my brain. Any idea I have that isn't directly related to whatever projects my employer is paying me to be part of are mine, not my employer's. Particularly if they are potentially valuable.

“ You are paid to create value for your company that far exceeds your salary”

Most people have very little insight as to how much value beyond their salary they create so we can assume there is a base level of value created factored in for doing the bare minimum. In many cases that’s just keeping the business going. If the company wants innovation from the rank and file then they should be willing to pay for that.

>> I work for a company that has billions in turnover and I'm directly involved in decisions that affect our profit or market share

and

>> I spend about 6 hours a day working

Which company is this?

> As an engineer, my view on days/hackathons is pretty simple: you don't pay me enough for my good ideas.

That depends on how you interpret hack days.

A lot of great hack day projects I've seen aren't introducing a new product line, they're "what if we used this new framework, what's possible?" "What if we used transformers to replace our convolutional neural network" etc. - things that aren't a new product, but have a shot at improving the development flow/end user experience by 20+%, but are speculative enough that are hard to get scheduled in normal flow of development.

> At our most recent company hackathon, we focused on a new way to do the old thing. A lot of what great hackathons are.

Most hackathon projects are not something you'd be able to start a company around, if they are, maybe you're doing it wrong and overindexing on demos to PMs rather than potential company impact.

We are in agreement :)

> If I had an idea that could make the business $5M, I'm better off going into business for myself.

One of the most naive things I have read today. Ideas are cheap. If you were capable of just "having an idea" and turning it into any considerable amount of money you would have done it already. Let's face it, most "software engineers" aren't anything special. We aren't founders. We aren't innovators. We are just glorified bluecollar workers slinging code.

However we are the closest to the product, we should know (or at least be able to imagine) lacking features and thus hackathons are a good way to try to tease out potential future paths plus it gives your average coder a chance to explore new technologies or just try different shit.

> One of the most naive things I have read today. Ideas are cheap. If you were capable of just "having an idea" and turning it into any considerable amount of money you would have done it already.

What if I told you that I've done exactly this and very successfully? :)

The second half of your comment is in agreement with the spirit of mine, though. Hackathons are for giving your average coder a chance to explore new tech, try different shit, and basically have a safe space to do something without being penalized for failure.

Yes, I'm all about the experimentation. I feel like often times during work, we don't have time to pop our heads up and look around at tools and processes that might help us do our jobs better or with less toil.

I always tell folks at any hackdays I coordinate: talking about a tool you thought might be used, explored and learned wasn't a fit is just as much a win as a cool demo.

Absolutely. So many times we fall into a rut of using our familiar tools that we don't realize that sometimes there are new innovations that can make our lives easier. Or, at the very least, automations we can put into place to make our lives easier!

At our most recent hackathon, for example, we automated about 80% of project setup. Whereas it used to take 4-6 hours to set up a new project, we got it down to about 30 minutes, and we have a clear line of sight to a 5 minute set up process. It's quite nice!

Going into the hackathon, however, people were like "Ugh, this is too much work to set up a project! Why should we bother?!" rather than thinking "Hey, this is an opportunity to make setting up a project much easier."

So yes, agree completely. Thanks for your insights!

If hack days are screwing up scheduling, that's a scheduling problem. (You'll have to figure that out with your company.)

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.

If the company was capable of solving those problems, the parent wouldn't be complaining...

Instead it just piles up "hack days" on top of those

Maybe.

Another possibility is that the company is capable of solving problems. It identifies a problem, creates a plan, and comes up with a solution. OP feels good in such a process.

Maybe the company is solving the wrong problems and is using hack days to surface novel problems it has not identified before. Maybe the company did not explain the value of the hack day in a way that someone who enjoys working in a structured way will not see it as a waste of time.

OK, but doesn't make it fruitful to treat the symptom instead of the disease.

Often you make do with what you can treat.

It makes no sense to take a student loan and have debt either, but its more feasible and pressing to do than managing to get the system to reduce tuition prices.

I for one really enjoy Hackdays. It's a chance to do something not in your normal line of work and experiment in a different area, or with different people, sometimes even different places (but often remote pairing).

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.

We use hack days (or we call it "spa days" - as in, giving the codebase/product a spa treatment) as a day to fix things up, tidy things that have been bugging you for a while but no one ever got around to doing it, etc.

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.

>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"

Ah, how does that gel with regression testing? We've tried something similar but got swamped by the need to test those code changes and the testers got upset being lumped with additional work while the rest of the team got to play with whatever they liked. Did you forgo testing for the sake of morale or did you come up with another solution?

Idk how far we go into regressions, afaik we don't really have an issue with it... We have a "everybody owns the product" mentality, and so pretty much everyone on the team should know how to use it and where issues might arise or have arisen.

So each code change needs to be kinda demonstrated that it works, whether it's through new tests, or screenshots, video, etc.

Usually if there's a specific bug that's been fixed, there is a test to catch if that bug occurs again. Most of the time it's been good enough.

You mean your company hasn't fired all their testers and made the devs do it themselves yet? I'm jealous.

Yeah, when I'm at work my rule is I need to be getting paid. For those who don't understand this is why some loathe company "offsites" and / or "hackathons" at any kind of event where I'm sent by my employer.

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.

You must be talking about something else. Most companies reserve a day a month or something where people have a little hackathon. They still get paid for it and it takes place during business hours.

I was at a startup once where we had a 24h hackathon. Like Jack Bauer style.

And the next day was presentation of your achievements.

And the day after back to normal.

First day, I "hackathoned" from 9 to 5 and went home. I didn't win...

> Jack Bauer style

I imagine the winner of this hackathon was the plucky and passionate new hire, fresh out of college, who narrowly managed to save the day, the company, and our american way of life, by: waterboarding the CTO for hours to obtain a confession that both founders and the entire board are complicit in a vast terrorist conspiracy, and then proceeded to execute both founders, kill the board, strangle the interns (one of them had a beard), kick the office puppy, shoot all the competitor's salespeople in the knees (thus helping secure a sale to a major new customer), and disarm the EMP.

I don't remember who won, but it certainly was one of these guys out of college who didn't care to show up on Monday at 9am and stay non stop in the office until Tuesday 5pm.

And honestly, younger me probably would have thought it was fun, but 30yo me with a wife and kid was more "f this shit, you're not getting 12h of my family time without compensation."

If the company actually said that it was going to be a 24-hour hackathon, that would trigger statutory overtime provisions in many jurisdictions. For instance, in Britain, that would mean you must work shorter days during the rest of the week, unless you and your employee decided otherwise (they can't fire you for changing your mind later, though).

goofy

The hell kind of hackathon did you experience?

Who is not getting paid to do company hackathon?

I always liked them. We had less work allocated to us on the sprint of a hack day to account for it, so that wasn't an issue (and it never should, that sounds like poor planning by a higher up). We also didn't force results. If you had nothing of value at the end of a hackday, which is pretty common, who cares - it was a hack day. Some people didn't do anything, which was completely fine. The majority of people had a personal vendetta against something in the codebase that they wanted to personally improve or add to, and that's where the results came from.

The best speed/quality ration of features came from hackdays for us because we actually cared about what we were implementing.

I have a love/hate relationship with "hack days". Back when I was an intern I had a lot of fun during hack days. Getting to see a new part of the codebase and getting to interact with new teams is always fun.

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.

Hate them so much. As an iOS eng I feel like I always end up doing 10x more work than others. But it’s also my fault for accepting invites to teams with new feature ideas. Been burned enough times now that I won’t be doing that anymore.

I love them, because they give me an excuse to work on silly joke projects. Usually if you make something amusing enough you can win some award for "people's choice" or whatever.

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!

One developer on my team added basic emoji support to our commenting system. It was a business app and adding emoji support was never on anyone's top feature list. He did it because that's what he felt like doing.

We feature-flagged this buggy implementation and turned it on for our internal accounts that we used for dogfooding. It was an instant hit. We fast-tracked emoji support, made the implementation stable enough to put in front of customers, and released it.

The good news is that it was well received and used extensively.

The bad news is that emoji support has surprising edge case issues (not talking UTF8 and display) and we've carried that burden ever since :).

you haven’t lived until you have watched hackday output, ostensibly made for the lulz, rushed to prod, because customers would love that.

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?

If someone is measuring your team metrics, is narrow-mindedly managing by numbers, and can not incorporate the fact that you had a hackathon into the holistic picture of the team, they are doing metrics wrong.

Re: rushing things to prod, that's what feature flags are for!

In my previous position, management employed the concept of a 'hackathon competition' as a sales pitch to the judges. One team, having received advance instruction, constructed their work in progress as a hackathon demo in advance and ultimately "won". It pissed so many people once it was known.

I always thought "hack days" were a way to officially introduce slack at the end of a scheduling period — not valuable so much for the hack day projects themselves, but as a buffer in case non hack day projects need a final push?

This question is a good example of how companies make decisions to reach their goals, not to make individual employees happy. If your employer could reach their goals but make you miserable, they’d take that trade off in a heartbeat.

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.

I worked at a company that had these and was initially excited about it, but my experience ended up matching yours. The "real" work is planned as if these days don't exist, so I spent all of them on my regular duties so I wouldn't slip deadlines. One day a week was never enough to make significant progress on anything interesting anyway.

I've never experienced these "hack days", and it sounds like I'm glad for that! Employer-mandated "fun events" are pet peeves of mine in general.

Companies that do this kind of stuff are really either late stage where everyone is just cruising and vesting, or it’s on the way down.

Yeah, definitely not a great experience for anyone on a team that already doesn't have enough time to do their actual work...

I've developed the somewhat controversial opinion that anything that can be conceived and built in a day is almost never worth doing. What I've seen work better is companies setting aside some team resource (maybe 10%) for innovation projects.

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.

> I've developed the somewhat controversial opinion that anything that can be conceived and built in a day is almost never worth doing.

I've started several successful businesses based on an idea that I conceived and built (to MVP) in a single day. I actually consider that one of the keys to my success.

Imagine you are in a new city for the first time. You have an old-school printed map in hand. You're trying to find your way to some landmark.

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.

Are you R&D or just D?

Oh, I'm whatever you want me to be as long as I don't stay a minute past 5pm :P