Are there a lot of other jobs out there were people have time to themselves to do stuff that they find interesting or fun?

I certainly hadn't ever got that impression. None of my friends and acquaintances in other professions ever have that either.

A friend of mine is a retired doctor, and told me that he studied music theory during down-time at the ER. Also, shopkeepers and anybody else who depends on walk-in customers or has intermittent demand.

> Also, shopkeepers and anybody else who depends on walk-in customers or has intermittent demand.

Until you have a boss demanding to do cleanup or whatever during low-demand times because they're too beancouter-ish to hire staff dedicated to keep up appearance.

Yeah apparently they never had a boss who loved to say "if you have time to lean, you have time to clean".

Government work. Almost impossible to get fired from there, and the work ethic is near nothing.

As soon as I'm rich enough I'm going to go back and work at a university lab. It's so much better.

Jobs that require creativity should allow for free time, to let inspiration come to you rather than try to summon it. I think programming is one of those jobs. And if you are always coding, always against a schedule, it's easy to burn out because you went against the essence of your work.

Most programming jobs are as creative as brick laying. So yeah there is some wiggle room to put your own style but you are just implementing CRUD(in it's different complexities and variations) and integrating APIs.

Are you sure CRUD is as creative as brick laying? They can't just copy paste stuff from Stackoverflow when they run into problems :)

Once you get the option choose between using browser native fetch or Axios, the sky is the limit.

in brick laying your brain can wander and think about other things, listen to the music and imagine you are living in perfect world without any problems at home. Your hands will be tired, but your brain can take a rest

in most programming jobs, even though you are doing CRUD, your brain should direct you into specific direction (open file.js, put after if (x > 0) block and so on), which tires your brain.

consulting firms have "bench" periods where consultants are expected to learn new things and train themselves up. some take that time to work on side projects; others learn entirely new things

You need to introduce firebreak sprints. Take a week off every fourth sprint (or whatever) and give devs the freedom to build whatever they think will need doing to make the system better overall. You’ll get a bunch of preventative maintenance that you knew needed doing but never found time to do, but you’ll also get the occasional mad idea that turns out to have big benefits.

I dont see why those ideas couldnt be identified and sprinkled into regular sprints.

The idea of a forced break to do these things implies they arent important. Otherwise they should already get picked up.

I've been in orgs in which developers are considered grunts and no one listens to their feedback. It's not that they aren't important, it's that the PMs/managers/whatever know better.

I see firebreak sprints as a symptom of an org not valuing engineer feedback. "Let the grunts blow off some steam or they'll get disgruntled and leave."

because sprints don’t allow the idle time that’s often needed to come up with such ideas. I could probably work for a year on “oh I’ve been meaning to look into that” tasks that have no clear outcome

Firebreak tasks (not sprints) should be taken naturally as prioritization chooses them over other tasks.

Sadly, with higher interest rates, there is a pressure to produce results in the short-term, at the expense of long-term investments.

Higher interests or not the pressure to deliver value and growth every quarter has always been present. In tech especially as we're seen as a hypergrowth model and not growing quickly every quarter is a sign of failure to the expectations of the market™.

I've been working in this industry for 18 years, in different countries with different central banks rates and macroeconomics conditions, it's always been the exact same.

My team has an operational excellence day per sprint where we have to work on tech debt.

Except that day is not counted in sprint planning so we don't have points allocated to it, we have meetings during that day and are also expected to perform our normal duty such as helping customers onboard, and 95% of our tech debt tasks would take more than a day to fix anyway.

The result is that we have 10% of our time supposedly assigned to tech debt, but in 11 months in that team I have only worked on tech debt once during those days.

I took a job where I was told engineers could work periodically on improving open source projects relevant to our work. In the two years I was there, I was given exactly zero time to work on such things.

I think these kinds of arrangements are dangled as a carrot in front of engineers, while the person doing the dangling knows full well that they are selling a lie. Now, such an offer is a red flag in my eyes, unless I hear a credible story firsthand from every engineer that interviews me.

Next time I am offered such a carrot, I basically will need to see it put into writing before I believe a word of it. I suspect you have learned a similar lesson from your own experience.

And it's not like a day every now and then is enough to tackle the hairy issues that have been festering for years and are a pain point in your everyday work. Past bad architectural decisions embedded in the codebase for years won't be solved by taking a day to clean up every week, it requires focused work to pull strings around, experiment and start a solution that will be rolled out over months.

I hate the view that allocating a fixed percentage of time every X week(s) instead of allocating proper time as a project to fix issues affecting the productivity of the whole team/engineering org is doing something. It's just another source of frustration.

I, too, think this has a lot to do with it. Developer sprints help, but I don't think they come often enough. Also, I think there should be a day between sprints to decompress and do some non-creative work.

If you’re building large new features on a product then I really recommend Shape Up’s model. Long period of driving the build followed by an explicit cool off period. They recommend 6 weeks of build followed by 2 weeks to cool off, but we’re such a small team that we halved this and found it worked way better - it’s four weeks which is an easier transition from two week sprints imo.

It gives time to just polish off those little rough edges that build up over time and gives developers a lull in which to work on low stress 9-4.30 kind of work.

I really don't like agile. It feels like you are always racing to the end just so you can start a new race. There is never a pause.

I think there might be something here. I've written about it and I wonder whether the current interpretation of Agile is just another manifestation of our can-do, 'get-ahead', 'achievement society'- - which is perhaps the ultimate cause of burnout. As someone who has tried to promote agile mindsets within organisations, it's deeply concerning.

https://nealdtaylor.com/burnout-trumps-agility/ https://nealdtaylor.com/agile-burn-out/