We need more well rounded people that also fundamentally understand how their code is executing on the backend so performance and cost can be optimized.
App/mobile and web developers are stretched beyond belief as it comes to skills expected of them. This handbook gives a reasonable overview of the scope of a front-end developer:
https://thoughtworksinc.github.io/front-end-handbook/en/
Yet it's still incomplete, most of the cloud stuff isn't even included.
We're over-asking people. Take Spotify. Has an army of quite decent engineers. They had to actually build a homegrown platform to shield developers from the ops tooling madness. The average developer struggles to understand just git. Even senior ones do.
Front-end developers were a joke 20 years ago. Not taken very serious, not "real" developers. Now it's one of the most complicated programming jobs there are. You have to know...everything.
As for performance, there I do agree that a programmer has a responsibility.
I’d also argue that if a senior developer does not have control over their VCS, they should rethink their title.
These are tools in a toolbox - you don’t need to be an expert in all of them, but seniority requires, at a minimum, proficiency.
EDIT: FWIW, I don't value titles like "senior" and never took them to be meaningful.
In my opinion (for whatever that's worth!), no (although I would say VCS in general, not git specifically). I personally consider being able to properly version control your code to be a critical skill when it comes to development - regardless of your place on the stack. YMMV.
> FWIW, I don't value titles like "senior" and never took them to be meaningful.
I don't necessarily disagree with regard to the current state of the industry, however as a proponent of development having more professional standards I still believe that we should be attempting to find some common ground on the standards of proficiency and mentorship.
For the simple reason that on most teams, there's no other person.
The breadth of my frontend career has only kept expanding over the last 10 years, it's definitely harder than when I started.
I'm getting old and I feel overwhelmed by the creep of "stuff" that I need to know. For me, it used to be UNIX + C + bash shell was enough to survive. My only defence is to write a small Wiki page for each category of "stuff". After a year on the job, I have built an organic encyclopedia that I can quickly search to remind me about "stuff" that I use infrequently.
And, to be fair, holy shit is modern web programming complicated. I am consistently amazed by the results on a wide variety of platforms.
EDIT
Wow, the link that you shared is amazing. Very well written. Thank you to share.
Think of how much is asked from other white collar professions such as law and medicine.
Some projects seems to be pulling “ops” functionality into a new monolith that is also the languages native environment (deno, vercel)
Still all Linux at the hardware layer and oodles of scripting language state, HTML/CSS. The web is a bloated mess after the “throw spaghetti at wall to try and gain market advantage, boost engagement” efforts of the last 10-12 years
MBAs ran software engineering as if machines were squirting soup into cans.
Make nice spaghetti and it sticks to the wall effortlessly. Make bad spaghetti and it takes 4 people and a dozen rolls of duct tape to get it up there.
I really don't know where the bullshit coming from. Often it looks like every single person is fighting for their lives against it, and yet it keeps growing.
But it's mostly dictated by overarching decisions that constrain both how it runs and how it's made (AKA, outside somewhere). Of course, there exist people on both sides that create problems all by themselves, but those are always easy to solve.
While annoying, there's often a good reason behind those if you can drill down to the engineers that asked for that rule.
Just as an example, it's easy to provide a single HA solution at the infrastructure tier... provided the infra people can make a few assumptions about your app (stateless, can handle multiple copies running at once, etc). It's virtually impossible to build HA that makes no assumptions, and it's incredibly burdensome to support 85 different HA implementations with varying sets of assumptions.
It makes business sense to have infra do the HA instead of each developer team, and that means restrictions on how apps are built and run.
What you're experiencing is the platform-ization of a bunch of aspects of the app.
Making nice spaghetti usually consists of finding the rules, finding the people who made them, and then grabbing them and asking "what does it take for this app to be in prod 15 minutes after we push the last commit?". It sounds like it will be a lot of people because there's a lot of rules, but there's usually like a half-dozen teams that make all the rules.
It will likely force you to build differently than you would have, but it will also mean that you're more likely to have 0 friction and you're more likely to get help with the friction you do encounter.
There's some complexity coming from better usability requirements, but again, it only explains a small part of it. There's something from the even-driven nature of the web never actually making inroads into our toolset (any toolset people actually use), that's a larger one, but again, it was 20-and-many years ago, it can't explain a constant creep-in.
Instead, since the 10's all the large innovations on software development seem to be about standardizing the complexity, and separating it so you can offshore. And yet, every time one of those gets adopted, the complexity creeps in.
I don't think I agree. Complexity--many parts, opposes "simple"--is part of the job; I'm pretty comfortable reasoning at the product layer (I've done devrel and product management) and working down to the cloud or bare metal (sometimes you find yourself wielding strace and wondering what mistakes got you here). Granted, that I have a handle on that complexity is part of why I'm a staff/principal engineer: to do that, and to help others who haven't achieved that level of understanding yet.
But by trying to remove complexity, IME you invariably introduce complication--relative difficulty in comprehending a given part, opposes "uncomplicated"--and that's where the demons lie. You give "the spaghetti maker" a nice, perfectly spherical pasta extruder; the amount of complication introduced by attempting to insulate the person on that side of the house only introduces problems for the other, who in turn must introduce complication to maintain it. That itself in turn introduces new constraints to the guy who just wants to turn the crank on the spaghetti maker and now his world reintroduces the complexity the initial perfectly-spherical-tool tried to remove.
Better, instead, to embrace that there are multiple moving parts that themselves are allowed to be uncomplicated, and work from there. Some complication is inevitable and irreducible, but if you don't treat each part of your system as being on an island, you can manage it and put it where it has the least impact.
- setup cloud cron job
- setup pubsub channel
- create pubsub subscription
- add environment variables specifying the subscription
- make all that work in terraform and run migrations
And that process is different for every cloud provider.
Performance (in particular cold start time) is better than most other similar cloud faas products. Dev ergonomics also.
If you need something more, sure go ahead and use another tool. But very many use cases will be well served by deploy in its current state.
There's also some sort of balance that needs to be struck. As a 'web developer'... to be 'well balanced', I need to understand (or dig in to) the minutia of:
* JS build tools, syntax, oddities, versions, and be able to troubleshoot these in a variety of environment (works locally with these architectures, and runs on production, but the CI pipeline changed to accommodate someone else and now I have to unstuck all this).
* SQL - I need to understand the implications and nuance of various indexing strategies because... hey, PG 14 changed and now our caching approach needs tuning. Should I be using b-tree indices, or something else? Should my indices be clustered? How do I manage replication and backups? And I need to understand the tradeoffs of ORMs vs hand-rolled, vs stored procedures, time-series databases, performance impact of views and materialization. And security.
* Application level - I need to understand various aspects of security at the application layer, and balance security vs usability vs accessibility vs performance vs feedback from various program/product managers and end users. Oh, and I need to be able to troubleshoot the application in a variety of contexts. Oh... and mobile. I need to be conversant and 'well rounded' in various flavors of mobile development (hybrid vs native vs whatever).
* System updates - what? I'm still on JDK 11? WTF? Why aren't you on the current versions? We need to update pronto, because there's too many security issues we'll get dinged on!
* UI - I need to be a CSS master, and if I'm not already on the tailwind bandwagon, I risk losing my job. Or... at least, I'll fall behind as I try to incorporate the new tailwind UI work the new person did because they couldn't be bothered to learn bootstrap 5. And... accessibility - need to be an expert in that.
* Deployment - hey, I now need to be able to understand multiple deployment approaches and processes, be fluent in docker/k8s and various tools, be able to troubleshoot these self-sufficiently. Doesn't matter if these are necessarily the right tools for the situation - someone else dictated this and lobbying for anything else means you're afraid to learn new things.
And... I should be cheery and helpful and positive about all of this being my responsibility. Because when I ask for folks from another team to help, I get told I need to 'own' the project, and I can't just 'throw it over the wall' and expect someone else to do something for me. If I push back on anything, I risk getting labelled "old" and "a dinosaur" and "afraid of change" and "unwilling to learn new things".
tldr - if you actually have teams of people with related yet diverse skills, consider letting each play to their strengths, help support them in their strengths, and organize around everyone doing what they're best at. The 'well rounded' thing has its limits.