I'm in the latter camp. I gave up, I can't compete with good frontend devs. But I've yet to meet a good frontend dev that competes in my domain. I really think the two take different mindsets.

If I don't know how to do something, I go and learn what's the best way to do it (by reading documentation, books, or just be asking more experienced devs). That's all.

If a company I want to work for is looking for "JavaScript" devs only (or "Python" devs only), that's a red flag... But if I really want to work for them, I would just apply because if you are a decent software engineer/developer then it does not matter if the job involves JS or Python or PHP. You can learn without too much trouble.

I hear you that there are plenty of "full stack devs" whose competency is mostly in one area.

But (at risk of sounding cocky,) I would consider myself competent on both the front and back end. And I'd say I'm not alone.

"Absence of evidence isn't evidence of absence." You just haven't been around these people. Frankly, I think this is more a statement about the industry as a whole than "full stack". There are a lot of gainfully employed but mediocre developers.

I think having both skill sets affords me the perspective to see whenever e.g. the front end is doing things the back end should be doing.

Sometimes specializing in one area means "you have a hammer, so everything looks like a nail." I've seen _way_ overcomplicated front-ends that would be a much lower long-term maintenance burden if the developer wasn't looking through "everything should be solved with client side JavaScript" tinted glasses. ;-)

Similarly, some know about every Linux error code, and how to tune systems around applications, which is a bit of a lost art.

So sure, fullstack exists in a way, but I still find it too broad a concept for any human to master on both ends.

Like almost anything, it's just a matter of time and experience. Plenty of people in the industry have been around since the Web was young, and have watched the technologies evolve over the years. We've built UIs rendering on the back end and we've built UIs rendering on the front end. We've built back ends that talk to databases and we've built front ends that talk to an API that looks like a lot like a thin wrapper around a database. So many of the skills and so much of the domain knowledge in web development is useful, or at least potentially useful, on both sides of the HTTP divide that it's hard to see the front and back end as significantly different from this perspective.

Once you've got your fundamentals sorted out, the important things don't change very fast in this business. Much of the "rapid development" is just hype and reinventing the wheel, and every time a new generation of young and enthusiastic developers thinks they've discovered a radical, game-changing idea, which in time they will discover the old fogeys had been using since the last millennium. Again like anything else, with enough experience you can easily see through most of that, but also learn to pay more attention to things that might actually matter. This is true in front-end development, back-end development, usability and accessibility issues, databases, visual design...

To put this in concrete terms, if we say (just to choose a number) that someone reasonably conscientious with 3-5 years of professional experience behind them could be proficient with the technical details of current front-end or back-end development, is it really so implausible that someone with 7 years of professional experience behind them could not have developed and maintained similar proficiency with both?

Yes. The world doesn't stop spinning so you can learn both. In the time you're focused on one, the other changes. Computer science fundamentals are going to be consistent, but the problem domains of front-end vs. back-end are vast. You can have skills from either, but ultimately either one is complex and wide enough that an individual focused on just one won't master it but merely be more than competent.

Also, just keeping track of the tech either side is discarding is enough to fill one mind. Keeping a pulse on useful best practices from multiple domains while the world races forward is no small feat.

That is true, but the world seems to spin a lot slower from the right perspective. Most of the "progress" in web development really isn't. Game-changers come along every now and then, but much more rarely than hype. Someone who is already proficient with both front-end and back-end work can easily keep on top of the developments that actually matter.

Also, just keeping track of the tech either side is discarding is enough to fill one mind. Keeping a pulse on useful best practices from multiple domains while the world races forward is no small feat.

Yes, professional development takes work, and keeping up with technology requires some of your time. But once again, the more you already know, the less any given development is likely to make a profound difference to you, and the more quickly you can scan what's happening and focus in on anything of real interest.

For example, on the front-end side, I probably find one or two articles or videos per month that offer some genuinely new insight or understanding. I might find one or even two front-end tools per year that are sufficiently interesting to be worth investigating in more detail and potentially adopting for future work. It's not that I don't read or watch more than that, but I filter ruthlessly and rarely waste time on anything that doesn't have either an immediate benefit or obvious potential. This also means I usually haven't wasted much time on tech that didn't stick around for long.

Statistically speaking, I'm probably a more experienced developer than most here, but I make no claim to being unique or superhuman. I imagine there are others reading this discussion whose experience is not so very far from mine.

Aside from being a software engineer. I also have various hobbies that I cultivate with above average level, graduated from 3 degrees in unrelated field, and know three languages.

And I know there are plenty of people who do more than me.

It isn't a stretch by any means. I believe plenty of people are very capable than what they think they can do. Human capabilities are more able than you think. Little by little knowledge compounds. i.e. if you can play guitar well most likely you can pickup bass quickly.

As you said, most full stack devs tend to have an area they're strongest in, and know enough to be able to hack things together for the rest. As a team, there should be someone with skills in each field that can be utilised to tackle harder problems and for guidance, while simpler tasks can be completed by any team member. You don't need 5 years of experience as a JS dev to add a loading spinner to the UI or 5 years as a Rails developer to add a CRUD endpoint.

I like to describe it as being analogous to an infantry squad, you have the machine-gunner, the grenadier, and the designated marksman, but everyone on the team is capable on some level of using a machine gun, a grenade launcher, or a sniper rifle.

The important part is to ensure that there are people with enough experience in each area to be able to provide technical leadership and mentoring. If you have a bunch of backend devs trying to hack away at JS and reviewing each others code, with no concept of best practice, you're going to get an amateur end result.

The challenge here is that, at least in the front-end (I'm a front-end engineer), it's not so much the case that there are certain problems that are hard and you need help with, but that there are things you should know you're doing wrong, or at least suboptimal.

For example, you can add a loading spinner, but you need to do some extra work to make sure people relying on screen readers, for example, know what is going on. After you've implemented a loading spinner, there is nothing that is really pointing out to you that you forgot that.

Though I guess the same holds true for the back-end: if I write a really inefficient database query, everything still appears to me as if it worked just fine. Only when it blows up later will it become clear that I lacked knowledge there - and let's hope that I did have enough knowledge to properly instrument the logs.

Of course, this isn't necessarily problematic. When you're a small team, getting something out the door that can load data even though the UX for some people sucks is better than not being able to do anything at all. But if you can afford specialists (at least in the sense that e.g. the front-end will typically only be touched by those who are strong on the front-end), you can get higher-quality products.

In my last job, I entered as a frontend developer and moved into more backend work in addition to frontend work. There was strong engineering vigour, rigorous code reviews and careful coding standards to ensure consistency. I'd like to think I was competent across the field and at least equal to my peers but that's not for me to judge. My peers and those to whom I reported were very pleased. This suggests externally-verified competency.

I find it better to enter as either a frontend developer or backend developer and then demonstrate internally competency at both rather than trying to sell yourself as full stack from the outset.

It helps to have been developing web-related software for the past 25 years. Over time you learn new things because they fascinate and interest you.

Recognisable competency throughout the stack is achievable by anyone with enough curiosity to explore combined with enough experience to know how little you actually know.

That said when I say I'm full-stack I say there are parts of the stack I am more comfortable with than others.

I think I'm equally good at the frontend and middle layer, the data layer I am passable, the backend processes - meaning receiving data/pulling data from other sources for insertion in my data repositories, processing data, queuing data, optimizing processes for images, anonymizing data etc. I hack stuff together and it looks pretty ugly to me (unless processing XML where I am very good), but I can get it done. It's not a different mindset that makes me less competent in those areas, in my opinion, just inexperience.

on edit: and of course one will always be less than perfectly competent in every part of the stack, because the stacks cover a lot of ground. I think I'm pretty good at CSS, but really am weak in use of some parts, what I'm better at in CSS than most developers is understanding the cascade rules and when things will conflict.

Personally, I work as the architect/leadership level, but I'm still pretty handy at DevOps, SRE, RE, Back end, and have even delivered a few front-end projects in my time (mid 30s).

I'm not claiming to be the best, but I'm good enough that I mentor engineers that are senior and costing >$250,000, and I did not gain these skills simply from being a generalist.

What I simply cannot do is keep up with 10s of engineers changing a code base when I spend a lot of the day in meetings. My choice is to be the bottleneck the project and cause discontent, or let the team roll with it and pick up the pieces that fall through the cracks.

Does this means that I could never again be an IC which specialises in any part at a reasonable enough level? I doubt it. But pragmatically, there are few people who see the bigger picture who have enough technical chops to get disparate specialists working together, so rather than be the 10x engineer, I try to focus on amplification and making my team a 10x team.

The funny thing is that 10x engineer drains mindshare from the teams, rest of the org, and will lack diversification, like architecture, testing and Ops.

It's mostly due to the sheer amount of things you have to keep in mind at any given time. Not the core things like algorithms and such, but (Javascript + Typescript + React + Redux + GraphQL + Apollo + .... ) + (Java + Spring Boot + MySQL + BigQuery + PubSub + Datastore + ...). All the different libs, and the ways to communicate, and idiosyncrasies specific to different languages and different libs.

There's never time to get good at something, as you're pulled apart :)

Now I work on a complex React app in TypeScript with a GraphQL backend in TypeScript. I can build a feature end-to-end. From domain modeling to an API to UI with animations. Optimising SQL queries.

There are people like this. Software engineers who have experience across the stack.

I don't do devops but I've met someone who can do full stack app development and devops pretty well too.

Perhaps your views are more a reflection on people getting pigeonholed at large companies, or otherwise choosing to specialise? Or something like that?

I personally think it's hard to be a _really_ good frontend dev without a chunk of more general development experience. What wider experience will you draw from to solve hard frontend problems otherwise? If your Angular/React app isn't performant enough because of the computations it needs to do or allocations it needs to make, how big is your mental toolbox to fix that if you haven't done more general backend dev work? It's all just software, ultimately.

These days I'm a devops-engineer, whatever that means, and I think my background of low-level understanding/coding has been very helpful.

Developers these days who can do amazing front-end things tend not to understand how computers work, how servers work, and how to debug problems under pressure. I'm sure they're entirely capable of doing the obvious/basic things, but their experience doesn't often qualify themselves to work from the bare metal upwards.

I don't feel defeated or obsolete, just the nature of an ever evolving curriculum I guess.

But I think there are far more front-end developers who know (and are amazing at) CSS, Javascript, react, and all that stuff - and have no ability to diagnose, or resolve server-side problems (be they overheating CPUs, bad RAM, flaky DNS, or other problems).

At the end of the day what we do is to solve problem.

Even if you specialized in let say just front end, that itself can be broad enough to master.

I think you just haven't seen them yet.