back to article Report: 83% of UK software engineers suffer burnout, COVID-19 made it worse

A report on the wellbeing of UK software engineers (developers and DevOps professionals) found 83 per cent suffering from some degree of burnout, with most agreeing that COVID-19 was partly to blame. This survey [PDF] was conducted in June 2021 by pollsters Survation, on behalf of DevOps company Haystack, and although the …

  1. elsergiovolador Silver badge

    Empty coffer

    I'd say the problem is low salaries and high tax. UK engineers make much less than their colleagues in the US and other countries.

    You work harder and harder and then you look at Zoopla and you find you still cannot afford anything decent to live.

    Years of learning, sacrifice, working your bottom off for what?

    I personally can't wait for Universal Basic Income so I can quit this circus.

    1. Anonymous Coward
      Trollface

      Re: Empty coffer

      Marxist.

      1. elsergiovolador Silver badge

        Re: Empty coffer

        In the neo-marxist world we live in, the real workers are the shareholders and you are just the mean of production that they own.

      2. Version 1.0 Silver badge
        Joke

        Re: Empty coffer

        "Marxist." - clearly the commentator missed it - he thought it was Visual Basic Income... not Universal Basic Income.

        1. B83

          Re: Empty coffer

          Haha, you never know how many legacy systems are out there in VB. The company I work for have developers that solely use VB and have been in the company that long nobody dares gets rid of them.

          A Visual circle or should that be vicious?

      3. Snowy Silver badge
        Thumb Up

        Re: Empty coffer

        Some information on UBI https://www.youtube.com/watch?v=kl39KHS07Xc

    2. Disgusted Of Tunbridge Wells
      Facepalm

      Re: Empty coffer

      Who do you think is going to pay for you to doss about on the dole?

      Bloody UBI.

      1. elsergiovolador Silver badge

        Re: Empty coffer

        Big corporations that got rich out of our sweat. They have not been paying right amount of tax for decades and persuaded governments that they can tax them by proxy by taxing the workers.

        1. Disgusted Of Tunbridge Wells

          Re: Empty coffer

          > Big corporations that got rich out of our sweat.

          No they didn't. And if you didn't like what was being offered then you could go elsewhere.

          > They have not been paying right amount of tax for decades

          The "right amount of tax" is what they owe. If you have evidence of tax evasion, feel free to share it with the police. If not, wind your neck in.

          > and persuaded governments that they can tax them by proxy by taxing the workers.

          Are you even old enough to pay tax?

          Jesus Christ.

          1. jospanner

            Re: Empty coffer

            If their wealth didn't come from labour, then I'm sure it'll be fine if everyone goes on strike. Right? They'll be raking it in without all those pointless salaries to pay out! Great thinking.

            1. Disgusted Of Tunbridge Wells
              Facepalm

              Re: Empty coffer

              See icon

            2. veti Silver badge

              Re: Empty coffer

              You want to go on strike, nothing is stopping you. You get right on that. Let us know when you've brought your employer to their knees.

          2. Anonymous Coward
            Anonymous Coward

            Re: Empty coffer

            Funny you should say that.....

            I worked for a big IT corporation. They were NOT paying the right amount of tax. There was evidence. They were reported anonymously. They were raided and had to cough up.

            It does happen!

            1. Version 1.0 Silver badge

              Re: Empty coffer

              I worked for a company back in the 80's and watched them sell lots of stuff through a subsidiary - and they billed the subsidiary for "management fees" at the end of every December ... the subsidiary always showed a loss on the tax returns.

          3. Pascal Monett Silver badge

            Re: if you didn't like what was being offered then you could go elsewhere

            I am very happy for you that you are in a position to change employer whenever it suits you.

            Guess what ? Not everyone has that privilege.

            There are various possible reasons, but some people just have to slog it out whether they like it or not.

            You can understand or not, you can be empathetic or not care, but it won't change that fact.

            1. Disgusted Of Tunbridge Wells

              Re: if you didn't like what was being offered then you could go elsewhere

              The alternative to this is everybody having much lower living standards, including the people you apparently care so much about.

              1. Anonymous Coward
                Anonymous Coward

                Re: if you didn't like what was being offered then you could go elsewhere

                Yes, because countries with high wages and low costs of living (compared to the UK) like Switzerland and Germany have *appalling* living stanards, don't they?

                1. Disgusted Of Tunbridge Wells
                  Paris Hilton

                  Re: if you didn't like what was being offered then you could go elsewhere

                  Congratulations on the disingenuous post. You must be very proud.

                2. Bbuckley

                  Re: if you didn't like what was being offered then you could go elsewhere

                  Switzerland is a low tax country with NO welfare state aids other than very meagre and time-limited rescue support until you get the f**k back to work. Personally, that suits me just fine. Germany is a socialist country where single workers pay very high taxes but families get all sorts of concessions. Not my cup of tea. I don't think you can put Switzerland and Germany into the same bucket as they are chalk and cheese.

          4. Anonymous Coward
            Anonymous Coward

            Re: Empty coffer

            Jeff, is that you?

      2. Paul Kinsler Silver badge

        Re: @Disgusted Of Tunbridge Wells

        Given your claimed location; and just in case you manage to stop spluttering into your soup for long enough :-), you might find this interesting,

        Discovery of Bayes' Table at Tunbridge Wells

        David C. Schneider, Roy Thompson

        In 1755 Thomas Bayes expressed an interest in the problem of combining repeated measurements of the location of a star. Bayes described a tandem set-up of a ball thrown on a table, followed by repeated throws of a second ball. Bayes' table has long been taken as a billiard table, for which there is no evidence. We report the discovery of Bayes' table, a bowling green located half a km uphill (SE) from the meeting house where Bayes served as minister for two decades. Bayes' drawing shows a rectangular space marked off in yards, which allows calculation of an interval measurement of uncertainty. The Bayes rule interval from 2.5% to 97.5% is from 0.56 - 0.42 = 0.12 perches equivalent to 0.61 m. The discovery of Bayes' table establishes the physical basis for Bayes' symmetrical probability model, a fixed parameter binomial ({\theta} = 0.5). The discovery establishes Bayes as the founder of statistical science, defined as the application of mathematics to scientific measurement.

        https://arxiv.org/abs/2107.05145

        1. Disgusted Of Tunbridge Wells

          Re: @Disgusted Of Tunbridge Wells

          I'm not from Tunbridge Wells.

          It's a famous pen name from when a local Tunbridge Wells newspaper wasn't receiving enough letters from its readers.

          The editor apparently had the staff write letters. Many signed with things like: Disgusted, Tunbridge Wells. It's become quite famous and I'm definitely not the only Disgusted Of Tunbridge Wells on the Internet.

          Unfortunately as a fictional character, your post went straight over my head.

    3. Anonymous Coward
      Anonymous Coward

      Re: Empty coffer

      High tax? Take a look at the tax levels in the rest of Europe. The UK is not a high tax country despite the whining of the Daily Hail brigade.

      Low salaries? Adjust for exchange rate, adjust for not having to worry if losing your jobs means you and your family no longer have access to health care and it soon gets close.

      1. Anonymous Coward
        Anonymous Coward

        Re: Empty coffer

        I agree that the "high tax" argument is a misnomer, but can't agree on salaries. The average salary for a sernior software engineer (with 20 years experience) where I live is under £45,000. A 55m2 2-bed house is in excess of £350,000 (southern England but NOT London). Similar positioins in Germany, France, Switzerland, etc, have significantly higher salaries.

      2. Anonymous Coward
        Anonymous Coward

        Re: Empty coffer

        High tax on what? This comes well within the purview of "lies, dammed lies and statistics".

        Picking an example list of tax comparisons will show somewhere in the smallprint words such as

        "This is a list of the maximum potential tax rates around Europe for certain income brackets. It is focused on three types of taxes: corporate, individual, and value added taxes (VAT). It is not intended to represent the true tax burden to either the corporation or the individual in the listed country."

        Because In the UK we pay fuel tax and then the fuel tax is taxed with another 20% VAT. If another country doesn't tax their tax then this puts more money in your pocket. No council tax, but you have to pay for healthcare? You end up with a lower monthly bill.

        Let's skip it all and look at the totals taken from us by the government.

        UK government raises over £820 billion a year in receipts – income from taxes and other sources – equivalent to around 37% of national income, as measured by GDP.

        source

        Assuming that HMRC is doing it's sums properly, which we all hope they are.

        In 2017, the total public revenue in France reached 427.4 billion euros.

        So in the UK it appears that our state manages to tax us more than twice as much as our immediate neighbours despite the GDP listings showing we are roughly even:-

        United Kingdom: (GDP: 2.83 trillion)

        France: (GDP: 2.78 trillion)

        There are lies, dammed lies, and statistics.

    4. EarthDog

      Re: Empty coffer

      though in the US I was paying 25% of my monthly take home pay for health insurance.

  2. Pascal Monett Silver badge

    "the same old type of business calling themselves Agile"

    That is the unavoidable problem when you have a methodology that does not require certification to be adopted. I can call myself Agile, I can put it on my CV. I can (and have) made multiple commits to production environments on the same day. I have stand-up meetings, mainly because I come with a question and I need the answer right away.

    But I am no Scrum master, I code what needs to be coded in the order required to solve the problem at hand. I am not Agile, I just provide solutions.

    For companies, there should be a certification to call oneself Agile. Sorting the wheat from the chaff.

    Won't happen though.

    1. My-Handle Silver badge

      Re: "the same old type of business calling themselves Agile"

      "I code what needs to be coded in the order required to solve the problem at hand"

      Same here. Our company has -no- formal software development processes. The line in the article that said something like "when management expectations are not in line with what is achievable..." had me twitching.

      I solve what problems I can, in whatever order I think best. Because when management dump five 2-day projects on me, all with a 1-day deadline, they have shown that they cannot / will not prioritise and it falls to me to do so. Now that's the kind of behaviour that breeds burnout.

      1. Mike 137 Silver badge

        Re: "the same old type of business calling themselves Agile"

        "Our company has -no- formal software development processes"

        No company I've ever consulted with in the last couple of decades has had any formal software development processes - or any adherence to formal standards - just locally developed habits. That's why it's not "software engineering" - just coding, because engineering is fundamentally a rigorous approach, not merely a body of knowledge.

        One of my more thankless tasks has been to try to introduce some formal processes and standards into established development teams. Typically they don't want to know. It isn't just management pressure - I suspect it's to a large part self confidence. But the results often indicate the self confidence is misplaced.

    2. Warm Braw Silver badge

      Re: "the same old type of business calling themselves Agile"

      I'm far from convinced of the value of any business process certification, but Agile is less susceptible of certification than most.

      Firstly, no-one can really agree what it is. But secondly, it's predicated on a close relationship between software development/deployment and business stakeholders (product owners, users, etc).

      When I talk to Agile practitioners I hear that there is rarely the level of involvement from the business side in terms of creating requirementsstories or defining test criteria because they either can't be bothered with the minutiae and/or don't really understand the business processes they're supposed to champion.

      In practice, what Agile seems to mean is basically just some form of accelerated incremental delivery. I can't see how it should be inherently better to deliver changes on a daily basis than on a weekly or monthly basis: you can clearly knock out trivial changes very quickly but not all changes are trivial.

      It's also not clear who frequent changes actually benefit. I have a prepaid debit card to allow carers to shop for an elderly relative and every time I use the associated App it is seems to require an update to add features I don't require and will never use. I had to actively decline its latest "innovations" today and it demanded to know why I had the temerity to refuse.

      And that's the ultimate problem with certification of any kind: it assumes there is a rational and logical process at work. In the real world it's mostly about people jostling to justify their jobs for another day.

      1. Pascal Monett Silver badge

        From what I've seen about the Agile process, it's a lot of meetings, and a lot of management patting themselves on the back and gargling themselves with all these new terms (Scrum master appears particularly appealing).

        However Agile they call themselves, their projects are invariably late, don't have the functionality required, and take way longer to finalize than planned for (if they ever do).

        But hey, they can make several changes per day !

        None that will actually benefit the user, though.

        1. John Brown (no body) Silver badge

          That's why I thought this...

          "divides teams from "Elite" (multiple deploys per day, cycle time of less than one day) down to "Low" (deploys less than once a month, cycle time of one to six months)."

          ...sounded a bit strange. Teams doing multiple deploys per day are "elite" and teams doing deploys monthly are "low". So a team pushing out hourly changes to help files correcting typos can be "elite", while the team doing the hard coding work pushing out changes monthly are "low". Yeah, great for team moral!

    3. doublelayer Silver badge

      Re: "the same old type of business calling themselves Agile"

      "For companies, there should be a certification to call oneself Agile. Sorting the wheat from the chaff."

      I'd like to see some suggestions on how they'd do that. The main problem is that nobody knows what "agile" is. I've theoretically been "agile" for a while. It's not much different than not being agile. It comes with a variety of words which replaced other words and means the same. A meeting is now a standup meeting. Sometimes they're really short. Sometimes it's an hour long and I'm wondering whether I can fall asleep. Sometimes it's an hour long because we actually have an hour's worth of stuff that needs discussion.

      To me, any business is going to write the code using the internal habits and culture. Announcing that they'll be doing this in an agile way just tells me what the various things will be called. It doesn't mean that anything is different for the people doing the work, and it certainly doesn't mean anything useful to preventing burnout. An agile company can still demand that someone write something impossible, stay up late to do it, or handle support requests without assistance. A non-agile company can still look at what their workers are feeling and try to prevent things. This is up to managers paying attention to the needs and status of their workers; we're all doomed.

    4. veti Silver badge

      Re: "the same old type of business calling themselves Agile"

      Oh, come on. When did certification ever solve - well, anything really? Are you trying to reinvent ISO9001?

      Self certification is as good as its enforcement, which is to say, generally it takes complaints from suitably motivated agitators to make any improvement. How would you foster a climate in IT where whistleblowers are celebrated and welcomed by their next employer?

      External certification means a whole framework of oversight board, advisors, auditors... Who would pay for all that, and why?

      Basically, the big effect of either one is to favour the bigger established players who can put the appropriate effort into making sure the required boxes (and only those) are checked. Most startups and smaller players - including, most likely, the most genuinely exciting companies to work at - would be excluded because they've got more interesting things on their minds.

      1. claimed

        Re: "the same old type of business calling themselves Agile"

        Bang.

        Exciting? When has a real engineer described their job building bridges and buildings that are safe and don't fall down, as exciting?

        If you want quality, it's boring, precisely because humans in general get bored and would rather wander off and play than finish the task at hand if it's 80% done.

  3. James Anderson

    Never ask a barber if you need a haircut.

    To quote the venerable (and stinking rich) Warren Buffet.

    Survey paid for by Agile tools company finds you will be less stressed using Agile tools -- surprise.

    In reality agile puts more stress on software developers. The lack of attention to process, the obsession with rapid deployment.

    "Customer Collaboration" over "Contract Negotiation" is a recipe for scope creep.

    Rapid deployments puts extra burdens on testers -- more releases with more bugs.

    Agile may work in a funky Web2 startup, but, in large organisations there are very few success stories.

    1. yoganmahew

      Re: Never ask a barber if you need a haircut.

      Absolutely @James.

      Agile in a large organisation is a recipe for sprint sweatshops. The treadmill is expected to go faster and faster, the few people who know what they are doing are stretched ever thinner providing direction to code monkey teams who only code, have no domain knowledge and never get the time to gain any.

    2. My-Handle Silver badge

      Re: Never ask a barber if you need a haircut.

      "puts extra burdens on testers"

      Don't forget, in many companies testers == developers.

      This is the case for my current employer. And my previous employer, a national company with an IT team of between 20 and 30 devs / project managers, had only brought in their first tester a couple of months before I joined.

      1. Nifty Silver badge

        Re: Never ask a barber if you need a haircut.

        In many companies testers == customers.

        1. Anonymous Coward
          Anonymous Coward

          Re: Never ask a barber if you need a haircut.

          In many companies, requirements = testes

        2. My-Handle Silver badge

          Re: Never ask a barber if you need a haircut.

          That too.

          Myself and my colleague do as much testing as we can on our work before and after it goes to production, but once we finish up the customer services supervisor is usually my first port of call. Officially to tell her that a new feature is now live (in case customer services get questions about it), but also to ask her to let me know asap if customers start reporting anything even slightly odd. It doesn't happen often, but it does happen.

          1. John Brown (no body) Silver badge

            Re: Never ask a barber if you need a haircut.

            "Myself and my colleague do as much testing as we can on our work"

            That's good. But as you have probably discovered already, testing your own work makes it incredibly easy to miss faults. You know what to expect and often, that's exactly what you get. Someone unrelated to the project will more likely find the faults because they don't have the expectations you have. It's just the way most people are wired. Just reading over some code you wrote can mean your brain seeing code you expect to see and missing the glaring typo that is actually there :-)

        3. veti Silver badge

          Re: Never ask a barber if you need a haircut.

          That's what "testers == developers" really means.

      2. B83

        Re: Never ask a barber if you need a haircut.

        Yep, got agree with Agile and sprints. The date is set for the sprint to finish and higher up management expect you to meet it.

        Never actually understood that myself since you always encounter unknowns that take time to resolve, but higher management don't give a f*ck since a date was set.

        1. Doctor Syntax Silver badge

          Re: Never ask a barber if you need a haircut.

          The date is set for the sprint to finish and higher up management expect you to meet it.

          Perhaps manglement would understand a car analogy:

          Your car is in for service and is to be collected at 4 pm. An hour after it goes in the garage rings up and says "We've discovered a problem with the brakes, The parts won't be here until tomorrow morning. You can have it working at midday tomorrow or collect it at four today as agreed but it won't be fit to drive. Which do you want?"

      3. Doctor Syntax Silver badge

        Re: Never ask a barber if you need a haircut.

        For cycle times of less than a day it sounds as if testers == users. If i were a user in that situation "elite" wouldn't be a term i'd apply to the developers. They might look elite to those selling tools to them, however.

    3. Jason Hindle Silver badge

      Re: Never ask a barber if you need a haircut.

      "Agile may work in a funky Web2 startup, but, in large organisations there are very few success stories."

      I think the problem for large companies, with existing applications to maintain, is that they are agile in neither the architectural or infrastructural senses. The code just isn't there. In other words, adding that rapid new feature leads to a great deal of regression testing on the rest of the product. And the tools often aren't there to support the rapid deployment cycle. What was designed to give engineers agency ends up being quite the opposite.

      Me? I'm happy with the vaguely conventional/waterfally process while picking up various tools and ideas that sprang from the whole Agile movement as and when they fit.

  4. Khaptain Silver badge

    What about the admins

    If the devs think COVID has changed their lives, what about us in the admin corner.....

    COVID presented a whole shebang of challenges that required huge amounts of effort in order to "keep" things running.... And now that we are moving towards Back to the Office we are now in the position of dealing with WFH and In the Office simultaneously....

    Grrrrrr, when I were a lad........

    1. John Brown (no body) Silver badge

      Re: What about the admins

      And not forgetting the front-line helpdesk staff who, while also working from home, had to deal with double or triple the calls, also had to troubleshoot home users ISP connections, VPN connections, and sometimes their home PC connections (at least in the very early day when not enough kit was available)

      Of course, thanks to you admins, for making it so the help-desk people had work to do and beefed up the remote working servers/VPNs etc at very short notice so the users had something to try to connect to :-)

  5. Howard Sway

    Agile methodology

    It's a logical contradiction. A methodology can never be agile because a methodology is a set of rules that you must follow. And in practice, it's just a load of managers clueless about what actual programming work entails congratulating themselves for being so fashionable by believing they have somehow adopted the compulsory buzzword trend. And they do love sets of rules.

    The only way to truly be an agile software developer is to work for yourself : no incompetent project managers, no time wasting waffle meetings, no project charts to fill in, an 80% reduction in unnecessary email, far fewer phone calls, nobody interrupting you asking you to do their work for them..... the list of negatives and time wasters could go on here for a long time. In 20 years of working in companies I never saw an efficient programming team of more than 3 people, with every good team having one developer who really knew their stuff. And I saw a lot of companies when I worked as an external consultant. Same dreary management-inflicted inefficiency in every single one of them.

    1. elsergiovolador Silver badge

      Re: Agile methodology

      Basically Agile is a framework facilitating exploitation. When organisations pay little and treat workers badly and there is revolving door, the workers need to release as quickly as possible anything that works, so when they are gone, there is still progress visible for the shareholders.

    2. teebie

      Re: Agile methodology

      "A methodology can never be agile because a methodology is a set of rules that you must follow"

      It's a methodology about how to do agile developing, not a methodology that is necessarily agile itself. In the same way that most hat salesmen aren't hats.

      It does seem to add to the admin though, I can't argue with that.

  6. tiggity Silver badge

    Not convinced

    That 17% claimed no burnout....

    Agile or non agile methodologies, problem always is manglement wanting the outcome in a timescale that is not feasible without corner cutting (e.g. poor code quality / bugs, lack of tests, some functionality problematic (e.g. edge cases) or even missing etc. ) and the general continual treadmill of no chance to take a breather, improve your skills (lots of employers make nice noises about training, work life balance etc., but reality so often tends to be that any (significant, as opposed to a few token hours here and there) upskilling you want to do is in your own time as workload allowances not adjusted accordingly).

    Maybe I'm unlucky, but I have worked for companies ranging from small to huge, and as perm & contractor over the years, but always the case of someone high up agreeing to an unrealistic deadline & those at the coalface suffering the fallout.

    As others have said, at UK pay rates, its a lot of stress for a poor salary (& plenty of studies to show that a better salary makes people better able to deal with high stress because at least that removes the general "struggling to get by financially" elements of general life stress & so only leaves you with job related stress & non economic based general life stresses).

    1. veti Silver badge

      Re: Not convinced

      With such a small sample size, the question of how the sample was selected is very important.

      I'm ppretty sure that, given the resources of a smallish consultancy, I could arrange for surveys to show any level of burnout you care to ask for, just by selecting the interview subjects correctly.

  7. Anonymous Coward
    Anonymous Coward

    Yup

    Last 18 months working in the NHS directly on COVID related projects. Yup, just yup.

    Burned out before so I know the warning signs and when it's time to put down the keyboard and "Go and Do Something Less Boring Instead"* but still the pressure has been immense and relentless.

    * cough.... ah misty eyed memories.

    1. cornetman Silver badge
      Happy

      Re: Yup

      > "Go and Do Something Less Boring Instead"*

      So Why Don't You?

      1. cornetman Silver badge
        Facepalm

        Re: Yup

        Evidently at least *one* person didn't watch the same kids TV that we did. :D

  8. Magani
    Meh

    Agile...

    Agile: First entry in the list of approved software development Buzzword Bingo terms.

  9. Anonymous Coward
    Anonymous Coward

    You keep using that word. I do not think it means what you think it means

    I've worked at many companies that claimed to be Agile. None of them came close.

    Faux agile gives Agile a bad name and it's worse than all the incorrect methods it replaces. There's only one thing worse than waterfall project management - waterfall project management with all the Agile industrial complex bullshit on top.

    I'll relink the original Agile Manifesto link here (https://agilemanifesto.org). You might be surprised to find out it's just four lines long! No two day training course required here. The (12) principles are worth a look too (https://agilemanifesto.org/principles.html). It's not rocket science. I'm betting this is nothing like most people's experience of Agile. Agile is less - not more.

    Agile is not a management fad - it's just a pragmatic acceptance of the realities of software creation - it's a knowledge gaining exercise - more akin to finding a cure for the common cold than a civil engineering project. You can't plan this shit up front, salami slice it into two weeks chunks and spread it around siloed teams that you harass with meetings and metrics. That's not Agile.

    Management just don't get it. Just look at the focus on velocity, estimates, 'accelerating', etc. This is manufacturing talk. It's got nothing to do with creating something that's never been done before. Once you've got the knowledge written down (aka the code) you can have your velocities et al: Produce a million copies for the price of one; Deliver it anywhere in the world - almost instantaneously, etc, etc.

    If we managed R&D projects like we managed building motorways they'd be a disaster. They'd all under-deliver, late and over budget - just like software projects.

    Please don't give up on Agile, it really does work, the hardest part is just getting the company leadership to understand it and buy into it. This is difficult because it challenges traditional roles, but if they do it the company will destroy the competition (because they will be doing faux Agile which sucks).

    1. Doctor Syntax Silver badge

      Re: You keep using that word. I do not think it means what you think it means

      "If we managed R&D projects like we managed building motorways they'd be a disaster. They'd all under-deliver, late and over budget - just like software projects."

      Cross Rail belongs to the same branch of engineering as motorways. Just saying.

    2. doublelayer Silver badge

      Re: You keep using that word. I do not think it means what you think it means

      The manifesto is indeed very different from its application, but that doesn't necessarily mean it's good. Here are a few parts of it which I have seen go badly:

      Through this work we have come to value:

      Individuals and interactions over processes and tools

      Working software over comprehensive documentation

      Customer collaboration over contract negotiation

      Responding to change over following a plan

      Sorry for the repetition, now I have to take some separately.

      "Working software over comprehensive documentation": Yeah, everybody seems to love this. You know what happens? I have to be your comprehensive documentation when people email the developers asking for help (I don't know if not having any support staff is part of the company's agile plan or just something they do). I'm not calling for a weighty manual documenting every line or giving a paragraph on each option, but document what it does and how and keep that up to date. If the software works and nobody other than the devs knows how to use it, it's about as good as it having a bunch of bugs.

      "Customer collaboration over contract negotiation": If you have a good customer, of course. If you don't, get that away from me. A bad customer can ask for lots of things that aren't going to work. Whether that's just adding useless features, complex extra requirements at the last minute, or even asking for the impossible, it always happens when you've already done the core stuff. The requirements should be set forth at the beginning, so you can decide whether you can do them. Asking for some minor changes halfway through is fine. Asking for a major feature halfway through is painful but sometimes there's a valid reason. Asking for an overhaul about 90% of the way through is something from which the devs need insulation. Which brings us to

      "Responding to change over following a plan": Again, it depends what the change is. Maybe something previously required isn't needed but a new thing is. Respond to that change. Maybe someone had a good idea and you can implement it without pushing out other important things. You can respond there too. But in general, you should have planned for most of the likely changes and you should follow that plan. In that case, you don't have to respond to change every day, meaning you can give the appropriate consideration every time an important change happens. The way management usually messes this one up is to consider anything they decide to be a change to which the developers need to respond. They started caring about something on Monday, so now the devs have to drop everything for it. On Tuesday they don't think it's as critical as they used to, so now it needs to be dropped again. That attitude is appropriate only for bugs which have been newly discovered or found to be more damaging than previously thought. Otherwise, it's a method of moving very fast and going nowhere.

      1. pip25
        Boffin

        Re: You keep using that word. I do not think it means what you think it means

        When I was first confronted with the above lines during Agile training, I was somewhat skeptical as well, similarly based on past experience. What put things into perspective is the fact that the manifesto does NOT say that there should be no documentation, neither does it say that no contract should be negotiated or no plan should be made.

        What is says is that, obvious as it might sound, you should not let the need for comprehensive documentation get in the way of making something that works. That the fact that you have negotiated a contract does not mean that you should never talk to the client again until the software is ready. Or that as good as your plan might be, you should not value it above the actual needs of your client, which may indeed change over time.

        The manifesto assigns priorities, it does not want you to throw stuff out and do something else instead exclusively.

        1. doublelayer Silver badge

          Re: You keep using that word. I do not think it means what you think it means

          Under that interpretation, it basically doesn't say anything. I could reverse each line and it would mean about the same. Document the code, but don't let it interfere with you getting it working. Have a contract, but don't let that prevent communication. Have a plan, but don't be rigid. If you assume that both things are necessary, then you get a message that says nothing.

          From what they've said and how I've seen it applied, I think they, or at least a lot of them, really did mean to reduce the effort spent on documentation and planning. Even if they didn't, it happened. It's bad that it happened. A balance is needed, and whether they didn't care or those who read it didn't interpret their commands correctly, the result can negatively affect both the customers and the developers. I don't have to blame them for this when a lot of blame can go to management and that's more fun, but neither will I laud their manifesto when it has had such a detrimental result.

          1. pip25

            Re: You keep using that word. I do not think it means what you think it means

            I assume we have both worked on waterfall projects. The scope was set in stone and was part of the contract, everything that deviated from that was a CR that had to be negotiated separately. The contract listed a set of documents the client had to receive for the project to be accepted (and thus we'd get paid).

            It is the above practice that the manifesto argues against, and provides a stark contrast to. As much as I have seen Agile being used as a mere buzzword or mutated in horrible ways, it speaks of its influence on the developer community that its tenets may seem trivial nowadays.

    3. veti Silver badge

      Re: You keep using that word. I do not think it means what you think it means

      "Agile" has become confused and conflated with "scrum". Scrum appeals to management precisely because it allows them to maintain the same illusion of control as waterfall, but in truth it's not particularly well suited to agile development.

      Anytime you hear about "sprints" or "standups" as part of "agile" methodology, this confusion has happened. But the inconvenient fact is that scrum works best, and produced all its greatest success stories, when it was parachuted in as an emergency measure to fix a failing waterfall project. Trying to treat it as an independent methodology that can replace all other development methods - misses the point epically.

    4. TheMeerkat Bronze badge

      Re: You keep using that word. I do not think it means what you think it means

      It is a feature of “Agile”, it can only be “faux agile”.

      It is something that exists to support an “Agile industry” providing employment for agile consultants and scrum master.

      It was created by consultants in order to make money consulting. Nothing to do with software developers.

  10. Hans Neeson-Bumpsadese

    I might be an outlier here, but I actually feel less burned out now even though my workload during COVID increased.

    The reason is work/life balance. I have more work to do, but by saving at least a couple of hours per day in commuting I have capacity to fit that in, with some time left spare. Couple that spare time with being able to adjust my working hours, I'm fitter because I'm able to get out for a long walk each day instead of being stuck in the office or in a car during daylight hours.

    Home office has a comfier seat, background music, better coffee, flexibility to combine thinking time for work with odd domestic chores like emptying the washing machine.

    Also, money saved by not spending a small fortune on commuting costs means I've been able to afford a few extra treats for myself.

    That's just my personal experience of course, and I'm sure YMMV.

    1. Nifty Silver badge

      I've had a few jobs where the journey to work was an attractive, 20 minute brisk, traffic free cycle ride and there was a pleasant town centre a short walk from the office. This is the one scenario where I would be unhappy to WFH all the time. Regrettably such jobs don't last forever...

      1. Anonymous Coward
        Anonymous Coward

        Which country? That doesn't sound common for the UK; sounds more Scandinavian to me!

        1. Roland6 Silver badge

          Milton Keynes...

        2. Nifty Silver badge

          Germany and also a market town in the UK. Apparently the Milton Keynes cycle network is a squalid affair with gloomy underpasses, right-angled corners and people chucking bottles down into them.

          Harlow and Bracknell have surprisingly nice cycle paths.

    2. Roland6 Silver badge

      I suspect some were feeling "left out".

      It's a problem in my household.

      I spent the first part of lockdown working all hours helping clients to enable their workers to work from home. I spent much of the second lockdown helping clients adapt to the new reality. I'm now helping clients become fully virtual organisations ie. the new business as usual. Additionally, my partner works in a CoViD essential business and also has worked throughout lockdown; therefore we've missed out on the furlough lifestyle...

      What I don't get is how the "increases in "digitization" is the main factor." in increasing workload of software developers; with the increased digitization among my clients, we've not had to engage any software developers. Eg. I purchased a bank card reader, I filled out an online form, connect reader to network and ready to process cashless transactions, no software developer involved.

    3. getHandle

      This! 100%

    4. Anonymous Coward
      Anonymous Coward

      You've just summed up my last 18 months!

      The workload has gone up like crazy but I feel much better able to cope with increased workload as I'm in a better mental state. I get up early, go for a long walk, think through my day ahead. I then plow into it, usually at least an hour earlier than I would if at the office, I take exactly 1 hour alloted for lunch eating food I actually like, often fresh bread baked by my wife! I then head back to work and work an hour past my normal finish time. Sometimes I quit early, take a walk and then do 2 hours in the evening just to pass the time. I go to bed later knowing I haven't got a mad rush anywhere next morning.

      We'll all go back and employers will ask, "Where's all the productivity gone? We gave you flexible working and it failed! Everyone back in the office full time! NOW!".

      Only 10 years to retirement....

  11. Anonymous Coward
    Anonymous Coward

    Elite?

    I'd probably say teams deploying multiple times a day is more Deadly or Dangerous. Just why the hell does any system need that level of deployment unless you are pushing out shite in the first place? Has the seeming push towards this approach improved software quality? No. Never knowing where a button is going to be in something like Teams the next time you need to click it is just ridiculous.

    1. Anonymous Coward
      Anonymous Coward

      Re: Elite?

      One place I worked, well before Agile appeared, the management seemed to think that any changes that didn't need to be patched up later had had too much time spent on them first time round.

      1. John Brown (no body) Silver badge

        Re: Elite?

        Probably for budgetary (Or manglerment bonuses) reasons. Like having capital for new shiny and nothing for repairs and maintenance.

        Local Authorities are great like that. Like the 100m long "wall of fountains" arrangement on our sea front. Lasted about 2 years before they turned them into flower beds.

  12. a_yank_lurker Silver badge

    Agile as a Concept

    The real idea behind 'Agile' was not a formalism but a philosophy of frequent collaboration between the various groups involved as a project evolved. It was not about the frequency of releases or any other formalism. It was about making sure the specs were understood correctly and were correct with conversations between the programmers and other parties taking place as needed with all the required parties being involved. If there some areas that were vague they would hammered out as the project evolved. Agile, correctly understood, is about breaking down internal silos within an organization.

    Agile really means as a programmer I can directly talk to the submitter of the specs as needed. We may have formal meetings, it may be relatively informal. We may have others join the meeting as needed from other groups. We can hammer out the issues, update the specs.

    A common failure is in most Agile formalism is the failure to understand someone has to write an initial spec describing what is needed from the programming team. This can be done with assistance from the programmers but the business has to describe what they want. The business side needs to know what they want done not develop it 'on the fly'.

  13. HenryCrun

    A very good report, but sadly like ones I have seen almost every year in my 40+ years in the computing field. The other big problem is we are repeating over and over again the same mistakes from previous years. I can't wait for retirement and that thought really annoys me as I used to get such a kick out of my job.

    1. Bruce Ordway

      problem is we are repeating over and over again ...can't wait for retirement

      >> I used to get such a kick out of my job.

      Yes, seems like most of my time is spent reworking old "stuff" because of system upgrades.

      Sure, it is nice to have some work/income but... it can get pretty boring too.

  14. xyz Silver badge

    I ucking hate agile..

    Dont get me wrong, the manifesto was bang on, however all that has happened in the 20 or so years is that effin group wank called scrum, devs not listening to clients whilst they try to shoehorn the latest CV must have into the project and a lot of sticky notes on walls that never get to 100%.

    Rant over.

  15. EarthDog

    Aleays remember

    agile is an adjective

  16. Dan 55 Silver badge
    Alert

    If there's anything that's going to contribute to burn-out...

    ... it's fucking Agile.

    We have disorder and chaos as far as the eye can see and people going round mopping up the mess afterwards, but if we call it Agile it sounds fantastic.

  17. Proton_badger

    Wagile

    Yeah, have been through a number of companies that tried to adopt agile and wouldn't let go of waterfall and ended up with a bastard child, every time exactly the same when a creative engineering manager was gonna revolutionize the way we worked with his original brain child - agile but with a few "improvements". I'm sure many here have seen it also.

    Mind, both waterfall and agile can work well with talented managers and total team buy-in but project managing is really hard and there's a shortage of truly good ones, including good support from above, and team morale is often a problem for a number of reasons. And ofcourse Wagile usually just ends up a mess.

    1. Anonymous Coward
      Anonymous Coward

      Re: Wagile

      "talented manager" is far too often an oxymoron, sadly.

      All too often they are a manager because they have the ego to think that they can "manage" others, but without sufficient knowledge of the domain and tech to understand what is and isn't possible and/or the realistic timescales actually required to achieve the desired results.

      If there were more good managers, and especially those with the ability and willingness to listen and hear, things would be a lot better in many places. An actual wise manager should recognise that colleagues are a source of useful and relevant knowledge that the manager may not have detailed understanding of, that helps the project to run more smoothly, rather than being mere underlings to be trodden on to reinforce their fragile ego.

  18. Trollslayer
    Happy

    I was fortunate

    Four weeks ago I retired early for two reasons:

    1. I have built up a good pension and my outgoings aren't that much.

    2. Testing embedded systems isn't fun, it's more like a chimpanzee in a lab pressing a space bar for peanuts, sometimes it took 10-15 minutes to get back to reality.

    3. Where I live is the best in my life, I want to enjoy it.

    Just over three years early.

    1. Roland6 Silver badge

      Re: I was fortunate

      >3. Where I live is the best in my life, I want to enjoy it.

      So not setting up a PC support business then :)

      1. John Brown (no body) Silver badge

        Re: I was fortunate

        Almost everyone I know who has retired is now wondering how they found the time to spare to go in to work :-)

  19. Anonymous Coward
    Anonymous Coward

    It's a shame...

    If 83% of Devs are burned out then at least 150% of the engineers supporting them are burned out.

    It's a long hard thankless job supporting Devs.

    To save myself some time to today and other infrastructure guys I'd like to say one thing.

    It's not the proxy / webserver / load balancer / bind that's broken.

    Fellow engineers...you're welcome.

    ...and for fellow engineers support Devs deploying .NET.

    Bad gateway is not an NGINX issue. Your workers are falling over because SQL can't keep up.

    I know, I know...it works fine in staging...but testing on staging with only yourself as a user a proper test does not make.

    Yep...less IOPS on the staging etc I know, I hear you...but your rage needs to go uphill not downhill...you need more money for more resources or you need to cut your SQL queries down to only 50-60 joins and unions and please investigate your SELECT * FROM BiggestFuckingTableOnEarth.

  20. adam 40 Silver badge

    A Waterfall is more soothing.

    You ever sat next to a waterfall, or even a weir? Quite soothing and relaxing. Even Kaieteur falls.

    Waterfall _has_ to be less stressful than Agile, the planning is done up front, and you know where you are with the timescales, deliverables, milestones etc.

    1. Trollslayer
      Mushroom

      Re: A Waterfall is more soothing.

      The problem is when the objectives change repeatedly.

      Some directors think Agile means you can change from a paddle steamer to a nuclear submarine without impacting the schedule.

  21. daeus

    Though workload is kind of up to the individual the way I see it, you can always move companies if you dont agree with their work ethic.

  22. Anonymous Coward
    Anonymous Coward

    Meh

    If they had a proper job it wouldn't matter. If you code things for medical equipment or the fire service though I sympathise.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021