Can You Feel the Burn? – InApps Technology 2022

One of the big headlines this week in the world of programming comes in the form of a single statistic: 83% of developers suffer from burnout, according to a study by Haystack Analytics.

As a developer, you’re likely not surprised by this statistic — unless, statistically speaking, you’re part of the 17% that feels just fine. Unsurprisingly, an equally large number of respondents — 81% — said that the COVID-19 pandemic was partly to blame for an increase in this burnout, with “increased workload” cited as the main reason.

When much of the world’s knowledge workers suddenly went remote last year, I suspect that commutes and in-office meetings weren’t the only things to suddenly disappear. Rather, hour-long lunches and somewhat more strict boundaries around working hours also dissipated, as leisure time and activities melted into the general day-to-day. And confronted with this suddenly remote workforce, my own hunch is that companies looked for ways to ensure they were getting the same bang for their buck, pushing their workers to constantly verify that they were indeed working.

I really mean this: every software engineer worth their salt should drop everything else and come work on the Death Star. The upside is enormous. There is almost no downside. If the Empire disappears you’re still a developer, i.e. HIGHLY employable by every company in the galaxy.

— Beth (@bethcodes) July 14, 2021

As someone who has worked remote for the greater part of the past decade, I’ve been a first-hand witness to the tug-of-war around remote work and accountability, with (some) companies requiring me to account for every minute of every day using time tracking apps. Friends’ stories of companies tracking their remote employees, making sure their online avatars never go idle, are commonplace, and I can only imagine an increase in this behavior over the last year. And hey, if you have no commute time, you can get more done!

So, is anyone really surprised that developers are feeling burned out? I know I’m not.

To make matters worse, InApps Technology’s Lawrence Hecht looked into the numbers and found, beyond the basic headline, that young, female developers were even more susceptible to burnout than their male counterparts, to the tune of 16 percentage points, due to “‘unrealistic demands’ on the part of management.”

Meanwhile, when headlines such as this are made, wait just a beat for the flurry of articles on “how to beat burnout” to make the rounds, alongside some corporate emails offering tips and apps as solutions. Not to worry, as publicist Ed Zitron is here to take this to task in his blog post about how the burnout conversation is a corporate tool to turn your suffering into marketing.

“If you are a company that cannot work out why people are burned out, let me simplify it for you: burnout is caused by working with seemingly no end. It is a form of exhaustion. It is not, at its core, a mental health issue — it is an issue with being overloaded and having no respite from said overload, and trying to solve it by offering ‘mental health’ and ‘wellness’ and ‘meditation’ stuff is disingenuous,” Zitron writes. “They want something that will have the optics of dealing with the problem, and will make people feel as if they care, without doing the thing that they should actually do to deal with burnout — pay people more, hire more people so that work is spread across more people, and actively, aggressively police how much work is being put on people’s shoulders,” he also wrote.

Until the time that that happens… good luck out there.

Rust, Java, C#, C pic.twitter.com/x2rgE9abKF

— Jaana Dogan ヤナ ドガン (@rakyll) July 15, 2021

This Week in Programming

• OpenSearch Hits 1.0: Earlier this year, AWS completed its fork of ElasticSearch with the first release of OpenSearch. If you haven’t followed along, the whole affair was a bit of a tug of war between AWS and Elastic, with AWS eventually coming out seemingly on top. After Elastic changed the licensing on ElasticSearch in an attempt to prevent AWS from selling a service based on the then-open-source project, AWS forked the project to release OpenSearch under Apache 2.0, effectively preserving its open source status. Now, OpenSearch has reached 1.0, which AWS says not only “marks the first production-ready version of OpenSearch,” but also introduces “multiple new enhancements,” such as data streams, trace analytics span filtering, report scheduling and more. The 1.0 release also involved quite a bit of code cleanup, removing proprietary code and marks, and adds the ability to upgrade from ElasticSearch to OpenSearch as if you were performing a normal upgrade of ElasticSearch. If you’re interested in learning where the project is going, head on over to the public roadmap to learn more.
• Visual Studio 2022 Preview 2 Adds Live Preview: Following the first preview of Visual Studio 2022, which introduced 64-bit, Microsoft has released Visual Studio 2022 Preview 2, which it says focuses on “the themes of personal and team productivity, modern development, and constant innovation.” More specifically, it brings things like localization for more than a dozen languages, the latest version of the C++ build tools, and, notably, Live Preview for both XAML and web apps. On this last point, it means no more recompiling just to see the smallest visual changes — instead, you will see the difference in real-time. Preview 2 also adds C++ support to its Hot Reload feature, which similarly means that you can edit your C++ and .NET apps while they are running. For the full list of features, check out the release notes and check out the video summary.

• Serverless COBOL? I must admit, I briefly chuckled at the headline when I read it — just thinking of a 60-year-old language going serverless — but AWS is not joking around when it talks about serverless COBOL and its method for rejuvenating legacy COBOL code using AWS Lambda and GnuCOBOL. After all, last year we saw what happens when you think languages like COBOL aren’t worth learning anymore: legacy unemployment systems crash under the weight of pandemic-induced layoffs. Perhaps serverless COBOL could have helped out here? If COBOL is still running on your systems, perhaps AWS’s series of posts on taking the language serverless could be of use.
• The Copilot Saga Continues: GitHub’s “AI pair programmer” Copilot has only been out a few weeks now, and it has a giant target on its back. The service is in technical preview, but the internet-at-large is finding fault with the AI-based code suggestion service at every turn. We’ve already looked at how many argue that Copilot violates GPL licensing, as well as how that view may be a result of a generational gap in open source developers, and now the focus is on how the IntelliSense-on-steroids is actually writing faulty code. Security researcher Melissa Elliot, AKA 0xabad1dea, spent some time with Copilot and found the service to be offering incorrect code on a somewhat regular basis. In a GitHub gist, she provides three examples of Copilot doing so, writing that they “did not require any cajoling; Copilot was happy to write them from straightforward requests for functional code. The inevitable conclusion is that Copilot can and will write security vulnerabilities on a regular basis, especially in memory-unsafe languages.” Part of the problem, she surmises, is that Copilot’s training set includes all public code on the site. “There does not appear to be any systematic separation of professionally produced code from beginners’ homework assignments in the model. Neural network see, neural network do.” So, before you go phoning it in and relying on Copilot to write your code for you…

Who named it Go and not Errlang?

— Amanjeev (@amanjeev) July 11, 2021

Feature image via Pixabay.