3 ms·

We could blame Agile for guaranteeing you never have a second to yourself to do anything you think is needful or interesting or fun, but just forever trudge ahe

We could blame Agile for guaranteeing you never have a second to yourself to do anything you think is needful or interesting or fun, but just forever trudge ahead fighting fires and fiddling with format and reworking code for broken libraries you should really be fixing... We could go on and on. But I'm too tired and ... burnt out to continue.

robin_reala 4y ago
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.
- danuker 4y ago
  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.
  - piva00 4y ago
    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.
- nonethewiser 4y ago
  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.
  - VyseofArcadia 4y ago
    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."
  - micromacrofoot 4y ago
    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
JustSomeNobody 4y ago
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.
freddie_mercury 4y ago
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.
- rafale 4y ago
  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.
  - myth_drannon 4y ago
    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.
    - weatherlite 4y ago
      Are you sure CRUD is as creative as brick laying? They can't just copy paste stuff from Stackoverflow when they run into problems :)
      - myth_drannon 4y ago
        Once you get the option choose between using browser native fetch or Axios, the sky is the limit.
    - tuyguntn 4y ago
      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.
iLoveOncall 4y ago
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.
- voakbasda 4y ago
  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.
- piva00 4y ago
  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.
stepbeek 4y ago
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.
wonderwonder 4y ago
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.
nealdt 4y ago
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/burnout-trumps-agility/ https://nealdtaylor.com/agile-burn-out/ https://nealdtaylor.com/agile-burn-out/

robin_reala 4y ago

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.

danuker 4y ago
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.
- piva00 4y ago
  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.
nonethewiser 4y ago
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.
- VyseofArcadia 4y ago
  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."
- micromacrofoot 4y ago
  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

JustSomeNobody 4y ago

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.

freddie_mercury 4y ago

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.

rafale 4y ago
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.
- myth_drannon 4y ago
  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.
  - weatherlite 4y ago
    Are you sure CRUD is as creative as brick laying? They can't just copy paste stuff from Stackoverflow when they run into problems :)
    - myth_drannon 4y ago
      Once you get the option choose between using browser native fetch or Axios, the sky is the limit.
  - tuyguntn 4y ago
    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.

iLoveOncall 4y ago

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.

voakbasda 4y ago
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.
piva00 4y ago
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.

stepbeek 4y ago

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.

wonderwonder 4y ago

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.

nealdt 4y ago

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/burnout-trumps-agility/ https://nealdtaylor.com/agile-burn-out/ https://nealdtaylor.com/agile-burn-out/