
I’m sorry, but this “Full Stack” meme makes me mad/sad - fagnerbrack
https://dev.to/cubiclebuddha/i-m-sorry-but-this-full-stack-meme-makes-me-really-mad-sad-35hi
======
dahart
> What do you think? Has your company pushed too hard for split UI/Backend
> teams?

I haven’t see this personally, I’ve only seen the opposite, companies pushing
for full-stack devs. And from what I’ve seen, people self-select frontend vs
backend despite teams pushing and hoping for more full-stack activity from
every person on the team.

Frontend and backend and ops are specialized activities, and those domains are
only getting more specialized and more complicated over time. Writing an API
and designing CSS almost couldn’t be more different, and they’re both full
time problems.

When I started a company with a friend, we both wanted to be full-stack and we
both tried multiple times, but we just automatically drifted to me on the UI
and him on the bots. After a while, when I would try to write bot code I would
screw it up despite good intentions, strong knowledge of the code, and unit-
tests in place. I would forget important security or schema details, or not
quite understand the way my partner’s code had changed structurally even when
we talked about it for hours. He’d get tired of explaining it and just write
the code. Same thing happened the other way when he’d dip his toes in the
frontend. If two people who want to be full-stack and communicate non-stop
can’t make full-stack happen, I’d guess it’s a hard problem.

~~~
mbostleman
At my company, the product team leads want full stack for the flexibility of
having any dev pick up any story. But the devs gravitate to their preferred
side. Personally, I tend to avoid the front end because I'm weary of learning
yet another js paradigm there every year or two and because I'm just more
passionate about the back end than the UI anyway.

~~~
testvox
This is also what I have seen. The push for "full stack" devs and teams came
from product because they don't like to have to coordinate multiple people or
teams in order to get a project done.

------
rossdavidh
"Full Stack", in my experience (which is anecdotal and just my own), means "We
want Front-End but can't find enough people so we're going to hire you as
'Full Stack' and then give you all Front-End work, but you wouldn't accept the
job if we told you that's what it was". In other words, "Full-stack" means
"Bait-and-switch", when coming from an employer.

Not saying that you shouldn't want Front-End work; if you enjoy that, great,
and I am happy to support you with that API in a timely fashion. Happy to work
closely with the designer and/or Front-End dev to make sure you get what you
need so that things look good on the front end. But, I prefer Back-end
development, for the most part. When I take a job that's described as "back
end" it usually will involve every once in a while doing a bit of js, html, or
css, but not much, and it's understood that it is not what I am going to be
doing most of the time.

Again, this may not be other people's experience, but it's mine.

~~~
cholantesh
>When I take a job that's described as "back end" it usually will involve
every once in a while doing a bit of js, html, or css, but not much, and it's
understood that it is not what I am going to be doing most of the time.

Do you feel that 'reporting' (of the SSRS variety)falls under the backend
umbrella?

~~~
rossdavidh
Tough question. It's kind of like, does "data science" count as back-end, or a
separate category? I tend to think both reporting and data science (which are
at different parts of a spectrum of data-oriented roles) are different enough
from other back-end jobs to deserve a separate designation.

In practice, I've also seen a similar "bait-and-switch" where people get told
they'll do data science, and then get pressed into back-end development
instead.

------
bluetidepro
> I think it's just a cheeky joke. The point it underlies is rooted in truth -
> that it's really difficult to master both frontend and backend development
> in real life.

That comment on the post sums it up perfectly, in my opinion.

~~~
masukomi
Agreed. The JavaScript world is evolving at a crazy fast pace. Front end
development has become inextricably linked to it. No-one writes Vanilla JS +
CSS anymore.

It's unrealistic to think someone can be an expert an the front end stuff
(changing by the month) and be an expert at the back-end stuff with its own
completely separate set of skills and knowledge.

It's like asking for a back-end dev who's also a DevOps expert and can handle
all 100+ AWS services. Hell, good DevOps folks can't handle that _without_
trying to become good back-end developers too.

------
frou_dh
I remember seeing a snarky tweet saying something along the lines of "Try
asking your full-stack developers which direction the stack grows on x86"

~~~
Redoubts
This was the kind of joke I was expecting, based on the title.

------
choeger
The idea of naming developers based on the tools they are currently using is
akin to name an mechanical engineer a wrench guy or a carpenter a hammer guy.

Of course not everyone is a computer scientist but even then everyone who is
worth their salary should be able to get up to speed with a new language or
deployment scenario.

That being said, how many job postings do you know that explicitly mention "we
work with XXX - do you think you want to, too?"

~~~
ohaideredevs
I think devs who think they can do everything are lying to themselves. Sure, I
can do Java and understand the environment. Sure I can do React and there is
nothing special about it. But I am better at C#/.NET/Angular, because I have
been working with edge cases for the past x years.

To say I can lead a team in a Java environment would be a lie, because of all
the minor details.

Just because you can do something in a language doesn't mean devs are truly
universal and "it's all the same."

Can I write some function integration in C/Go/Powershell, etc? Sure, but when
I do, I am not nearly as efficient as when I am using my daily
languages/frameworks.

~~~
JohnFen
> I think devs who think they can do everything are lying to themselves.

I don't think I agree with this, but there's an underlying truth here.

Personally, I have at least dabbled in pretty much everything that I've come
across. I do this intentionally for two reasons -- first, it makes me aware of
what tools exist, so I can make better tooling decisions, and second, it gives
me a little head start if it becomes desirable to actually achieve competency
in one of them.

I'm minimally competent in a very large variety of things. I can accomplish
pretty much anything with a tech if I'm minimally competent with it. It will
just take me longer to do so.

I'm competent in a variety of things, and I'm expert in a handful of things.

An expert dev should be able to at least muddle through with pretty much any
tech, where "muddle through" means that you can produce using that tech, but
it will take you longer than with someone who is at least competent. But you
can still do it, and recognizing that isn't lying to yourself.

~~~
ohaideredevs
I don't think we are in disagreement on "should be able to." The argument is
that it's not an efficient use of time.

~~~
JohnFen
Yes, that was why my assertion was qualified. The part I disagree with is "I
think devs who think they can do everything are lying to themselves."

I agree that devs can't do everything efficiently.

~~~
bryanrasmussen
I think there might be some devs who can do everything, but given that nobody
has ever been tested on everything how do they know - at best you know that
you have never yet been unable to meet a challenge and considering some
challenges you have had you can estimate how long it should take to complete
similar ones.

~~~
JohnFen
Well, if we limit our discussions to Von Neumann machines anyway, the number
of different kinds of problems are not actually unmanageably large. Once
you've touched on each of them a few times, I think you can be confident that
you can figure out pretty much any situation. The only question is work
efficiency.

Different languages don't really matter, because once you've learned the major
types of approaches languages take then everything else is (mostly) just a
difference in syntax.

If we look at mathematical and algorithmic issues, all of those can be learned
if needed. They don't affect the ability of a dev to do them, only how long it
would take.

When I say a dev can do everything, I don't mean that everything is easy or
fast for them. Just possible.

------
gambler
This is not just a meme. This is a mentality.

At my last job at a big company we had HipChat rooms for all kinds of user
groups. The one for frontend devs had constant discussion about their job
(in)security, and every couple of weeks someone posted an article complaining
about the existence of "fullstack" engineers.

I wouldn't care if this ended at chats and picture, but it's these people who
deliberately push for ever increasing fronted complexity to make sure they're
not easily replaceable.

The sad reality is that IT industry is currently in a bubble. It is choke-full
of overspecialized tool junkies with no transferable skills. Certain
complexities you "have to know" to perform basic operations are often 100%
artificial and shouldn't be there in the first place.

~~~
dcosson
I never understood this concept at all. Is this a metaphor somehow, or do you
literally think everyone is secretly conspiring to make life more complicated
for themselves and their team because of job security? What about the fact
that everyone changes jobs every 1 to 3 years anyway? The market for engineers
is pretty hot these days, I don’t think most devs even want all that much job
security, much less are willing to go to such extreme lengths for it.

Have you considered that problems you’re not working on may actually have more
inherent complexity than you realize?

From my own experience, and also just based on Ockham’s razor, it seems much
more likely that people are mostly giving an honest effort and trying to solve
real problems. Sometimes they succeed and sometimes they fail to solve the
problem, or fail to recognize the right problem to work on, but overall real
things are certainly getting done in the software world — new products launch
and companies provide real value and gain real customers.

------
Analemma_
Every "full stack" team I've ever been on almost immediately partitioned
itself into "the frontend people" and "the backend people", with people only
crossing sides if there was some kind of emergency fix needed and the "right
person" wasn't available. From what I gather in talking to others, this is
pretty typical. Full-stack development is mostly a myth that we all pretend to
believe in.

~~~
scotty79
Isn't that ability to cross to wherever you are needed actually what full-
stack means?

I was hired as front-end and did angular and css but earned respect of my
back-end devs by pestering them successfully about creating correct indexes on
the tables involved in queries that were mysteriously slow to them.

The other front-end guy just switched to Java were team were short of back-end
capacity.

------
gonyea
I'm a Full-Stack developer at Google, which is fairly uncommon given the
complexity of systems here.

The chief trait of a Full Stack developer, in my opinion, is often just
growing into the needs of the team/moment. I've been weighted in different
directions because that's where the product needed me; I'm currently the
Front-End domain expert on my team.

Self-adulating thought leaders who throw shade at Full-Stack are themselves
just really bad at using more than one language, let alone thinking about
different parts of a large system.

(I'd also expect a Full-Stack developer to understand systems and resource
provisioning/monitoring. Not just JS vs. Java.)

------
benjohnson
I'll admit - I'm that horse drawer.

The converse problem is a brilliant but un-coordinated team of front end and
back end developers that make things that the other team has trouble
interfacing with: the severed front half of a narwhal and the back end of of a
dragon with thousands of JSON/XML ants going between the two distant mounds of
meat.

------
amorphic
A lot of comments here bemoan "Full Stack Engineers" as being Jacks of All
Trades but Masters of None. But that misses the point. Don't forget that the
full quote is:

“A jack of all trades is a master of none, but oftentimes better than a master
of one.”

In a startup or smaller organisation an Engineer with a deep understanding of
a single area (frontend, backend, devops etc) is far less valuable to the
business than an Engineer with "T-shaped" skills
([https://en.wikipedia.org/wiki/T-shaped_skills](https://en.wikipedia.org/wiki/T-shaped_skills)),
a solid understanding of fundamental best practices and the ability to quickly
understand new things as required.

This article nails it:

[https://angel.co/blog/what-skeptics-get-wrong-about-full-
sta...](https://angel.co/blog/what-skeptics-get-wrong-about-full-stack-
engineers-and-why-we-need-them)

------
saidajigumi
> What do you think? Has your company pushed too hard for split UI/Backend
> teams?

One relevant (anti-)pattern I've seen too often: nominally full-stack teams
who fail to value and take ownership of their UI component. In my examples,
this happens when they "require" full-stack devs, but will give full rating to
the "meme horse" developer (weak UI, strong backend) and completely de-rate
the opposite developer: strong UI, weak backend.

That said, I agree with the author's preference for "full-stack team" where
the entire team puts real value in the whole range of competencies rather than
just pushing the full-stack need down onto every individual developer.

------
mizchief2
I think Mitch Hedberg described it best:

[https://www.azquotes.com/picture-quotes/quote-when-you-re-
in...](https://www.azquotes.com/picture-quotes/quote-when-you-re-in-hollywood-
and-you-re-a-comedian-everybody-wants-you-to-do-other-things-mitch-
hedberg-129-5-0509.jpg)

