Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Programming

Developer Burnout Fueling Great Resignation Staff Migration (itprotoday.com) 33

Developer burnout is helping to drive an exodus of software developer talent from organizations, as part of a larger trend known as the Great Resignation, according to a report released on April 13 by MuleSoft, which is a division of Salesforce. From a report: The MuleSoft report was based on research conducted by Vanson Bourne in February 2022 across the U.S., U.K., France, Germany, and Australia. Eighty-six percent of respondents indicated that in the last two years it has become increasingly difficult to recruit software developers. One of the reasons why is the larger macroeconomic trend of the Great Resignation, where employees are leaving their employers en masse during the COVID-19 pandemic as they seek a better work-life balance.

Burnout is also a large challenge for developers, according to the report. The top causes of developer burnout are increasing workloads and the challenges of learning new skills to adapt to emerging technologies. "The pandemic was a massive accelerator for the need of digital tools," Matt McLarty, global field CTO and vice president of the Digital Transformation Office (DTO) at MuleSoft, told ITPro Today. "Non-technology companies were ultimately forced to become technology companies overnight, and we saw nearly every organization require developers to help them achieve these new goals on high-pressure deadlines, all at once."

This discussion has been archived. No new comments can be posted.

Developer Burnout Fueling Great Resignation Staff Migration

Comments Filter:
  • If you're feeling burned out, just do the Ballmer chant [youtube.com].

  • by zephvark ( 1812804 ) on Friday April 15, 2022 @03:38PM (#62450434)

    >and the challenges of learning new skills to adapt to emerging technologies.

    You mean, the incredible boredom of learning what new words are being used to describe existing technologies. There's been wave after wave of the same thing, now described by completely different words and the, ahem, very latest "paradigm".

    I'm sure that rewriting the existing, debugged code in a brand-new, incomplete language is always a fine use of my time. It must be. I've been paid for that for so many years.

    • by phantomfive ( 622387 ) on Friday April 15, 2022 @04:15PM (#62450556) Journal

      It took me a long time to wrap my head around microservices, with all the terminology and technologies surrounding it. One day I realized that a microservice is just a service, and all the problems you have will normal services are going to exist with microservices (connectivity, flow control, push vs pull, latency, etc). There is no difference except with microservices, there are tools that try to handle some of the problems (like flow control, or auto-reconnect) for you.

      • by Kremmy ( 793693 )
        There are fun parallels with the attempts at microkernels over the years. Let's take the transit problems, and make them fundamental to the designs...
        • Oh yeah, and with microservices, all the problems of asynchronicity appear, and there's no magic solution. Deadlocks and race conditions. Plus you have the additional problems of versioning being more difficult, and setting up a test environment locally (or anywhere) more difficult. The end result is just a mess of bugs that are very difficult to debug.

          Microservices are possible, but they are harder, and if you don't have well-defined interfaces, they are always going to be bad.

          • by Darinbob ( 1142669 ) on Friday April 15, 2022 @05:58PM (#62450804)

            If you make every component incredibly tiny, then everyone can understand each component very well. The problem comes now trying to figure out the full system, which is now vastly more complex because of the huge increase in the number of components.

            • by phantomfive ( 622387 ) on Friday April 15, 2022 @07:24PM (#62450964) Journal

              Oh yeah, and then there's the database problem. Do they share a database? If they do, then it's hard to update the database because you need to update all the microservices that use it. If they don't share a database, then either data needs to be duplicated across the multiple databases you now have, or something like a "data provider" microservice, and suddenly even simple queries become very difficult.

            • The problem comes now trying to figure out the full system, which is now vastly more complex because of the huge increase in the number of components.

              That's not the "problem," it's the "objective." It's a thing called "strategic division of information" and it exists so rich and unscrupulous people can duple the peasants into creating the tools of their own enslavement.

    • Yes, there's not much new, especially in computer technology programmed by the masses (not counting quantum computing, etc). In real tech there is sometimes new stuff but it's incremental improvements. In software though, it feels like everyone studiously avoids learning from the past, and so they keep reinventing old ideas, again and again, only with new terminology...

      "It's web 6.0!"
      "It looks like yet another type of client-server architecture..."
      "No, no, stop living in the past and try to learn somethin

    • Good point. The art of selling us what we already have. Every few days there is another technique with a cute word that makes us feel like we have wasted our previous year. Has the pace of software utilization methodology outstripped both people's ability to keep current and industries ability to actually vet/train/deploy before it's stale or unfashionable?
  • by dmay34 ( 6770232 ) on Friday April 15, 2022 @04:11PM (#62450538)

    They burn out as software developers, what are they going to do? It's kinda a specific skill set that doesn't translate to much else besides "software developer for different company".

    • by Brain-Fu ( 1274756 ) on Friday April 15, 2022 @04:13PM (#62450546) Homepage Journal

      They could easily move to fields that pay a lot more while requiring far less intelligence and effort. Like...management....

    • Being a programmer is about 70%-75% troubleshooting.
      Knowing how to bisect a problem. That skill applies to a very large number of disciplines. Anything that involves fixing problems with anything. A lot of people don't have that skill.

      Btw, if you think there is no such skill as troubleshooting properly, that simply means you don't have that skill. :)

      It's another 10%-15% thinking ahead, so you don't discover that your idea doesn't work AFTER you've built it. The ability to plan a solution and foresee possib

    • Well, most software developers are well suited to a career in online video watching and chair testing. Granted, not a money in those careers right now, but it's the right time to get in at the ground level.

    • by AmiMoJo ( 196126 )

      Often the burnout is specific to that company, so moving on really helps. Being stuck with an ancient, horrible code-base is a common cause. Poor planning and unrealistic deadlines are also quite frequent. Bad bosses too.

  • by rantrantrant ( 4753443 ) on Friday April 15, 2022 @04:24PM (#62450588)
    There's a lot of sectors that had to adapt quite drastically when the pandemic hit. What seems to be happening now as things are opening back up again is that managers are trying to keep the emergency measures going alongside the old business as usual, further stretching & exhausting workers that were already suffering from the pandemic workload, lack of boundaries between home & work, overwhelming & unpaid overtime, distracting environments at home, etc..
  • Agile to blame? (Score:4, Insightful)

    by MrLogic17 ( 233498 ) on Friday April 15, 2022 @06:51PM (#62450922) Journal

    I wonder how much this Agile fad is playing into turnover rates.

    The tyranny of the endless 2 week sprints, with daily "are you done yet?" interrogations... it's crushing.

    • by sordid ( 322222 )

      I fucking HATE scrum.

    • Agile is a complete mystery to me. I have no "Agile" experience, so my 20+ years of programming in 15+ languages seem to mean nothing to anyone. It's like being mocked for not being a pilot, while you're never allowed to set foot on a plane. I would love to purchase some Agile, if it's for sale... but it usually sounds like developers hate it. So, I'm not that sorry I don't have "subjected to daily interrogations" experience - that sounds like hell, but apparently I need a "been through hell" certificat
      • by gweihir ( 88907 )

        Think of "Agile" as the one ture management method bad managers desperately hope will finally make them not suck at their job. Kind of like some wannabe coders are always looking for the one true language that finally will allow them to write good code. Of course that will not work and cannot work.

      • When done properly it's not a daily "are you done yet?" it's "is there anything you need today to do your work?"

    • by gweihir ( 88907 )

      I wonder how much this Agile fad is playing into turnover rates.

      The tyranny of the endless 2 week sprints, with daily "are you done yet?" interrogations... it's crushing.

      Good question. I left a well-paying job in the middle of the pandemic because of Agile. Of course, it was applied to Security Architecture (where using Agile is about the most stupid idea possible) but still. Have decided that "Agile" is on my blacklist of things now that I will never use. You do agile? Do not even ask me whether I want to work for you! Funny side-note: The job I left has now been open for more than a year and they really, really need that security architect. Gives me a smile whenever I see

Term, holidays, term, holidays, till we leave school, and then work, work, work till we die. -- C.S. Lewis

Working...