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