The deskilling of web dev is harming us all

I'm curious about what the author of this article expects? That all APIs remain frozen in time forever? That new APIs are only something that happens in the frontend?

> 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.

> 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.

I'm lost as to what the author is talking about. I've been using React for... 9-10 years now. There's been two API changes to React in that time - functional components and hooks. Neither of these are rocket science, and they're also able to be completely ignored and you can stick to your existing knowledge if you so chose to. I don't feel like 2 API changes in 10 years is that radical.

I dunno. On the one hand I hate “web dev” more than anyone. I think it has led to such an astronomical decline in software quality that if you described it to someone from the days when computers were 1000x slower, they straight up wouldn’t believe you.

That said… the article doesn’t really ring true to me. What he is saying about the complexity of each part of the stack (http, html/dom, css) is technically true, but that’s not really how it washes out in practice. This whole “CSS is a complex graphics engine!” “HTTP is a protocol you could write a whole dissertation about!” sounds like an argument being made by someone trying to make a rhetorical point about web. In practice for most of web dev you don’t need to understand the deep nuances of CSS or HTTP or whatever. Yes, there is a large breadth of material you have to learn but the depth you actually need in any one area is much less than the author is trying to imply.

And yes, web is trash, but for different reasons. In fact some of those reasons are the opposite of what the author is saying. He says that each part of the stack is so complex it should be a separate specialty. But the real problem is the very fact that things are so complex. Rather than accept that complexity and subdivide the field into different disciplines, we should get rid of all this unneeded complexity to begin with.

I have been saying this for years. The opinion has become even firmer since moving into DB specialization – the horror show of schemata and queries that even dedicated backend teams dream up is unreal. I don’t even really blame them; relational databases are hard. Yes, anyone can install Postgres (or spin up a managed service) and get decent results for quite some time, but at scale you absolutely have to know what you’re doing. There is a reason that DBAs were a thing, and the SaaS industry is slowly realizing that they shouldn’t have abandoned that role.

CSS is easier than it's ever been

I don't fully disagree, but this might be subjective.

For me as a full stack developer working with small teams/startup, I actually don't consider myself full stack. I just want to be able to do whatever it takes to make a product and ship features. Does it need a websocket server? I'll learn how to do that. Does it need advanced client side caching? I can do that, etc.

To some extent "product development" is both art and engineering. In the engineering side, you can think of html and CSS and http and testing as different things requiring a multidisciplinary team.. but if you think just in terms of "building the thing", I like to feel that I can get it done with whatever technology needed. That's why I got into programming in the first place. Not to write code and be an "engineer", but to make the computer do cool things.

AI does expand the capabilities of someone that wants to get things done. I have written in languages that I don't have experience with, and recently was exploring a neo4j db with cypher queries written with ChatGPT (I have only MongoDB experience), something that would've taken me hours to learn.

Still, having experts in specific areas in a team can be very helpful (both to get technically difficult things done but also to have others learn from them).

I just don't want to be 1 part of a team specializing in my limited domain, where I start to care more about the technical part than the actual value delivered or user experience..

I think what might cause me to burnout is too much specializing, too much bureaucracy, people telling me I can't do this, we need to hire a staff level person to this thing etc..