Baldur Bjarnason

The deskilling of web dev is harming the product but, more importantly, it's damaging our health – this is why burnout happens

– Baldur Bjarnason

Even before the web developer job market became as dire as it is today, I was regularly seeing developers burn out and leave the industry. Some left for good; some only temporarily. Many have outright destroyed their health through anxiety and burnout.

The only other industry I’m familiar with that has the same levels of physically-demanding anxiety and worker churn is trade publishing – and that’s an industry famous for literally paying below-subsistence wages for the cities they’re based in.

“Maybe I should try to find a job that doesn’t involve web development?”

Even those still in web dev are feeling burnt out and the reason for that is – unfortunately – quite straightforward:

We’re expected to keep up with multiple specialities that, in a sensible industry, would each be a dedicated field.

Of course you’re having problems keeping up with everything that’s happening in web dev. Of course!

You’re expected to follow half-a-dozen different specialities, each relatively fast-paced and complex in its own right, and you’re supposed to do it without cutting into the hours where you do actual paid web development.

Worse yet, you’re not actually expected to use any of it directly. Instead you’re also supposed to follow the developments of framework abstractions that are layered on top of the foundation specialities, at least doubling the number of complex fields a web dev has to follow and understand, right out of the gate.

This is immense – an expectation so mind-boggling that we need to acknowledge just how remarkable it is that each of us has managed as well as we have.

The framework knowledge itself is also perishable. Not because your memory or physical coordination deteriorates (though that happens too), but because frameworks change more and faster than the underlying platform.

I learned how the CSS Grid works over a decade ago. Even if I hadn’t kept up with CSS, everything I learned back then still works today. I could use the basic techniques of the CSS Grid as it existed in 2014 and that code would work unchanged today.

The recommended semantics for HTML have changed, but the basic principle of list or table markup is the same as it was over twenty-five years ago, when I first began. If twenty-something Baldur was cast forward in time to the year 2024 and asked to put together an HTML table that rendered in a modern browser, he’d probably have a harder time figuring out the modern browser UI than with the coding task itself.

But the React skills I have are all out of date and obsolete. I would effectively have to start from scratch even if I wanted to get back into React work. Everything React has changed in ways that are fundamentally incompatible.

The same applies to my skills in Svelte. I first got into Svelte with version 3. They’re now releasing version 5 and are completely changing their approach to state management. My old Svelte skills are obsolete but they’re still there, useless and cluttering up my memory.

Framework skills are perishable, but are easily just as complicated as the foundation layers of the web platform and it takes just as much – if not more – effort to keep them up to date.

We’re expected to do everything, keep up with everything, adapt to constant changes, and understand multiple conflicting architectural paradigms ranging from immediate mode rendering, to relational databases, to REST API designs, to both imperative and declarative programming, to complex state querying languages like GraphQL, to all of the various intricacies of how CSS handles rendering.

We’re made to do all this while watching our peers lose their jobs, our employers savage society through pervasive surveillance and collaboration with authoritarian companies, and our data centres suck up the entire water supply for entire municipalities.

No wonder we’re all fucked up emotionally and mentally.

This is what deskilling looks like #

These are all distinct specialities and web dev teams should be composed of cross-functional specialists.

You shouldn’t have to be figuring out both front end and server-side programming. That’s two separate skill sets.

Companies should have CSS specialists on their teams who take care of the complexity of providing stylesheets, with class and attribute hooks, that work well with the project’s architecture and design. Those specialists should be working with the front-end engineers and the UX designers to figure out how best to implement in CSS what the project needs.

Once you understand this, it becomes obvious why Tailwind is so popular among developers: Tailwind provides a loose approximation of the experience you would get from having a dedicated CSS expert on board. “Here are some classes and attribute hooks. Just use them in your markup and everything will look great. Of course I’ve also written documentation for you. What do you take me for?”

That abstraction falls apart quite often because Tailwind is too thin of a layer to hide the complexities of CSS. Nodes in the DOM can affect the rendering of both their ancestors and descendants and it’s very easy to run into a situation where, for example, position: sticky doesn’t work and the utility class model makes figuring out the issue much harder.

Unlike a collaboration with an actual expert, Tailwind demands its own expertise and quickly begins to require an understanding of how the underlying CSS stack works, undermining much of it’s own purpose.

But the promise it offers is tantalising: it’s your CSS buddy so you don’t have to know CSS.

Of course developers love this. Why wouldn’t they? I’m sure they’d love having a friendly real-life specialist that takes care of all things CSS even more, but we all know that’s not going to happen in our current deskilled industry.

So Tailwind it is.

This is deskilling. It lets employers and managers pretend that web project teams don’t need CSS expertise – or even just pretend that CSS expertise just doesn’t exist at all. This is what Tailwind is for.

Instead of learning from history, we double down and make things worse #

Organisations that hire web developers and ship web-based projects could have responded to recent changes in the tech ecosystem by re-specialising.

Cross-functional teams of specialists are almost certainly much more productive than a team that consists of identikit full-stack developers and a mostly untrained PM who lives in a constant state of anxiety and panic.

Specialists cost more because you either need to pay more to hire them, or you need to pay for the time it takes for somebody to become a specialist. But the productivity improvements should more than outweigh the cost. Especially considering that a junior specialist often has the same capabilities in their field as a senior generalist, which means a whole host of previously intractable technical problems suddenly become tractable when your teams are composed of cross-functional specialists.

But instead we’re all-in on deskilling the industry. Not content with removing CSS and HTML almost entirely from the job market, we’re now shifting towards the model where devs are instead “AI” wranglers. The web dev of the future will be an underpaid generalist who pokes at chatbot output until it runs without error, pokes at a copilot until it generates tests that pass with some coverage, and ships code that nobody understand and can’t be fixed if something goes wrong.

If you think companies are going to pay “AI” wranglers senior-level pay in the long term, or that they’re going to pay for the time it takes to rewrite or properly comprehend the code being generated, then you’re missing the point of why employers are adopting the technology.

The point is to pay fewer of us less: replace senior coders with junior, specialists with generalists, and the trained with untrained.

We’re left in a world where we still suffer from the same anxiety, pressure, and burnout as before. Except this time we get paid less, if we have a job at all.

This is an obviously worse way of making software. It makes for software that’s less reliable, less effective, and less productive for the end user.

But the market dynamics of tech – the global dominance of a handful of oligopolies that aggressively lock out their competitors – mean that software quality doesn’t matter. Competitors that make better software won’t be able to grow unless they get past the gatekeepers. Software that’s outright awful will still succeed because it genuinely doesn’t matter whether Microsoft, Google, Adobe, or Apple products actually work.

We still have to use them if we want to use our computers and work in a modern office.

The ongoing labour arbitrage – the deskilling of developers – can only be addressed with collective bargaining and union action.

But the overall monopoly or oligopoly dominance of tech can only be fixed with pro-competition anti-trust regulation.

And nothing coming out of either the US or Europe comes close to addressing the true problem, which is that these companies are simply too big.

The tech industry will never be a genuinely free market as long as big tech companies are allowed to be as big as they are today.

What we have today is a centrally-planned economy by MBA sociopaths, operated as a looting ground for the rich.

It will never function on normal competitive, supply-and-demand market principles.

Because, even though a healthier market is the only thing that has a hope of a return to the fast-growing tech industry of prior decades, it would also require big tech companies to accept a smaller slice of the overall pie and allow new competitors to grow.

Why do that when you can strangle the market and keep the entire corpse for yourself?