I think a lot of frontend engineers can do backend work and vice versa, but it takes a lot to be very good at both. It's not impossible but also I think it's rare that a backend engineer would voluntarily decide to also become a frontend expert instead of leveling up their backend skills.
Fullstack in my experience arises out of a need by companies and startups to cut costs by having a single engineer do both.
A true fullstack developer is a jack of all trades.
The adage being "A jack of all trades is a master of none, but oftentimes better than a master of one."
A fullstack developer is not two developers in one. A dedicated backend or frontend dev will always overperform a fullstack dev in their side of the stack.
But while a good fullstack dev is not useful to a more mature company, they are invaluable to a startup, early stage company or greenfield project where building fast, lean and "good enough" is the target.
One of the important things about employing full stack engineers at small companies is that the skillsets of frontend and backend don't always meet the needs of the work they're doing.
Consider two examples: sending an email, which requires typical frontend skills but is by nature in the backend code; and configuring invisible backoff and retries in the frontend, which is the opposite.
I call myself a full stack engineer even though my ability to do design-adjacent work is pretty bad because I've spent a lot of time working in this middle ground. When you want to e.g. move PDF generation from the server to the client, or you want to untangle the horrible Redux caching layer that doesn't invalidate things properly, that's a specific blend of skills that's neither fully one nor fully the other. This is less about cost and more about a niche between the two fields.
Consider also data engineers, or teams with a technical lead rather than an EM, or any other role that sits between worlds.
I’ve met people who haven’t solved a partial differential equation in 10 years and still remember how to do it whereas some people barely remember the library they used last week and have to keep a mountain of notes.
The people in the former camp have a lot of very deep knowledge on a lot of things.
Someone who can solve a partial differential equation with an hour refresher after ten years but most importantly can identify a situation where a differential equation is useful even if they can't solve it outright is still useful. If they're keeping a zettelkästen level system of notes and can get back up to speed on the specifics quickly but retain conceptual knowledge then I don't see any reason to dismiss them.
One issue our industry has is how to identity a great generalist. Broad conceptual thinking is harder to test and interview for than specialized tasks.
The second part of that adage was added on I believe centuries after the attestation of the first part. It's still a nice saying, of course. I think there's a third part to the phrase but I can't remember it for the life of me.
That's true, but the original phrase was from the 1500's so added centuries later could still mean centuries of usage.
It's important to not see any iteration of the phrase as either praise or insult. There is nothing wrong with being a specialist or a generalist, only that there are uses for both.
Most of the time being very good doesn't matter, when you're thrown into a process that's designed to extract mediocre work out of everyone, regardless of how good they are.
I'd imagine it's more common that a frontend dev moves to backend dev role.
From my experience a fullstack dev can be a lot more productive than two separate devs when it comes to adhoc work like bugfixes and adding small features.
Also they tend to have very good API design skills, since they understand both sides intimately.
Fullstack in my experience arises out of a need by companies and startups to cut costs by having a single engineer do both.