
The Problem with Full Stack - Brajeshwar
http://www.heydonworks.com/article/reluctant-gatekeeping-the-problem-with-full-stack
======
danielvf
> “We need to address the undervaluing of HTML and CSS for what it is: gender
> bias.“

And with that, an interesting article, putting forth an already controversial
proposition, lost any hope of rising above a comment flame war.

~~~
tbirrell
I think one of the comments on the article summed it up pretty well.

> I think I disagree with half that statement. I agree that HTML is
> undervalued, but I've never seen that as gender bias along that line. [...]
> I think it's an issue of, "declarative languages simply can't be hard"

------
ivanhoe
IMHO it's a huge misconception that full-stack dev has to always equal a one-
man band. Yup, if you're building small sites as a freelancer you probably do
everything alone, but on any bigger projects you'll have a team - and there
full-stack is simply a player who can play more than one position good enough.
You have that in sports too, e.g. in basketball that might be a player who
plays mainly a wing but can double as a playmaker. In programming it's say a
node dev who can jump in before a big presentation and help out the react team
to finish the project faster. You can move between positions, you can
communicate with different teams on an equal level, you can understand the
wider picture because you know their work and that is good for the team.

Another misconception is that full-stack dev has to be a wizard in everything
to be helpful - no, you just need to be good enough to get the job done and be
a useful member of the team, just like everybody else. If you're a wizard
great, but I'd trade a wizard for two responsible and capable average seniors
anytime.

------
propter_hoc
"CSS, which makes things look ‘pretty’, is considered feminine"

What an absurd statement. In my entire professional career and in my entire
time reading tons of great discussions about CSS on HN, I've never seen anyone
say anything like this.

Please try to find anything remotely resembling this attitude in this recent
post, for example:
[https://news.ycombinator.com/item?id=18753358](https://news.ycombinator.com/item?id=18753358)

------
vinceguidry
Full-stack is what you get when you can't afford to have team members
specialize. Of course you won't get the same quality with one guy doing the
work of three. Or with three guys with exactly the same skill set rather than
three specialists with overlapping specialties. I don't know why people seem
to think this is even worth mentioning.

But we really shouldn't look a gift horse in the mouth. If you look at the
stratification of specialization other fields have you wouldn't wish it on
yourselves. 500 mid-sized arenas compete for the attention of 5 highly-skilled
sound engineering specialists and the 50 other guys knocking at the door can't
get jobs. If one of those guys makes a career-ending mistake, his career is
well and truly _over_ , no arena is hiring him again.

Great for the 1%, horrible for the 99%. The fungibility of software talents
works as much in our favor as it does for businesses. I personally don't mind
working across the entire web stack, but ask me to switch frameworks and
you'll be looking for someone else soon.

------
Glyptodon
I don't particularly believe in full stack (a team with some specialists
should be better than a team without any), but plenty of us have to be and
maybe aren't as entirely terrible at it as is stereotyped in the article.

Though I also think the author fails to appreciate business trade-offs that
are involved in some of what's complained about, particularly in environments
that need to use full-stack developers. Perhaps it's not ideal, but doing
perfect "beautiful" CSS/html is often not the thing with the greatest marginal
benefit, particularly with time considerations involved. And the places that
need this kind of developer don't feel that they need the quality of output
that would come with larger, more specialized teams, or can't afford it.

(Though I also don't believe that anywhere with more than a half dozen or so
developers is avoiding appropriate specializations.)

------
the_gastropod
I don't like the general premise of this. Cooking dinner, driving a car,
paying taxes, and doing laundry are all VASTLY different tasks. Yet we can
trust most able-bodied adults to do these things without much trouble. Just
because tasks are different, doesn't mean they require a specialized human to
do them. Humans are quite capable of being competent in many areas.

Hyper-specialization, while probably useful at Google, NASA, and Honda, is
just not something I think most business software needs.

~~~
kbutler
Sure, I can do all of those things.

But I have no competitive advantage doing them. Any time I spend driving the
car (O($10)/hour job) is time I'm not spending developing software
(O($100)/hour job).

The counter argument to that could be that if I don't enjoy some Dev/Ops task,
I'm more likely to automate it away, so maybe it is good to have devs doing
tasks they don't care for.

~~~
ivanhoe
But if you combine the right skills it can be a huge advantage. The money is
in the cross-sections of your expertise, that's niche where you rule. Say a
translator with an inside knowledge of a particular industry is worth her
weight in gold, ask anyone who had to deal with the technical translations
done by non-technical people.

------
bespoken
First, there is no guarantee that a backend and frontend developer together
perform better than 1 full stack developer. It really depends on who's doing
the job. I'm a full stack JS developer, and yes I can do pretty awesome CSS if
needed, or is that considered to be impossible?

Btw, how would the author go about building a nodejs SSR React application? 1
backend, 1 frontend and 1 HTML/CSS guru? I've actually never seen that, even
in large companies.

I see there is some frustration about CSS in JS while writing in object
notation is not any more difficult than CSS or SCSS, my 12 year old daughter
would learn that in a snap. I can imagine it is frustrating for people that
are good in HTML and CSS that there is not much work if you cannot actually
code, but that doesn't mean there is a problem with full stack.

------
andrewmcwatters
I don't see anyone saying CSS is sexist except people like this, propagating
it from an imaginary world where no quotes or references from significant
industry figures are made.

I've worked with more women who were doing systems, back-end, or app work than
front-end, and I'm a front-end web developer.

I'm wary of people who make everything political without looking at root
causes, which this article is a fruit of said tree.

------
FennNaten
The thing is, considering the current state of web development, "front-
end/back-end/full stack" labels just don't hold up. Knowing cache strategies,
all the subtleties of consuming full blown services, orchestrating computing
distribution, etc. used to be deemed "back-end" because the webserver did it.
Now with service workers, background workers, fetch api, indexedb and many new
browser apis and frameworks, you can run all that in a browser. Does that make
it in fact "front-end stuff" ? And all the complex tooling to set to do
efficient SSR/code splitting, with all this transpiling and bundling, forcing
you to understand http, resource and module loading, file system,
componentized architecture... Is it more "backendy"? I recently interviewed
for a "full stack" job, first thing I did was asking what they imagined the
daily tasks to be. Turned out, it was mostly about dealing with stuff
involving data and request flow orchestration spanning on both services and
browser, and wiring up some react components to handle the data flow /
rendering. The "UI" components are handled by a team of specialists in
UI/UX/semantics/accessibility/animation... So what should the job be called ?
Client-server app developer? Glue developer? Backend guy who knows the browser
as an app platform? Developer of all the stuff you can't see on screen? I've
seen other companies using "full stack" for other meanings. "UI guy who knows
how to deploy", "service guy who knows enough to diagnose and patch the front
when UI guy has higher priorities", "guy who make templates render data", "guy
who will be able to perform maintenance tasks accross all the layers while
specialists handle the features"... So for me, the true problem is that we are
collectively bad at describing what we do, and give to non-tech people some
umbrella terms that spread more confusion.

~~~
em-bee
indeed.

a decade or so ago, we had designers who did html and css, and back-end
developers who nudged the html into templates and did all the rest.

i used to be a classic back-end developer.

nowadays i am happy to code front-end, because my work hasn't really changed,
it's just that many things that i used to do in the back-end are now done in
the browser. i am still working with designers who do html and css, and i am
still nudging the html into templates.

the one reason i don't like working with css is because most decisions to be
made around it are design decisions, which, not having any experience in
design are decisions i feel unqualified to make so i dread making them.

------
madhadron
In the 1990's, being "full stack" in web development wasn't that hard: HTML
3.2/4.0, the first release of CSS, some modicum of JavaScript and jQuery,
Apache and CGI or PHP, and the database, which was probably the biggest
surface area of all. If you hired someone to build a web application, it was
entirely reasonable that they would be able to do that.

Fast forward to today and you can complicate that stack beyond belief.
Meanwhile the business side says, "I could hire a full stack developer to
build a web app twenty years ago. Why can't I do it now?" It's an entirely
reasonable assumption on their part that somehow saying that's not reasonable
anymore is prevarication and trying to hide the fact that we screwed up.

It's interesting trying to make the case that we haven't. Off the top of my
head:

\- We added accessibility, which makes it possible to comply with the
Americans with Disabilities Act or comparable legislation elsewhere. \- We
know that faster interaction improves conversion rates, so we can make a case
for at least some of the JavaScript to speed up a user's interaction. \- Video
and images can have better conversion rates than just text, but that can
adversely interact with the last point, so we have to work around that.

So the web accessibility guidelines and semantic content, form validation on
the fly and any other interactions that can be done within page that would
otherwise require a page load (imagine if commenting on Facebook required a
submit button and a page reload), and image sets and HTML 5 video.

What else can we justify this way?

------
ajmurmann
I used to be fully convinced around 2010-2013 that full-stack was the way to
go. I've since then become much less convinced. All aspects have become more
complex. Back then you need to know CSS, HTML and jQuery and the front end was
under control (at least if you knew how to deal with some of the browser
weirdnesses). On the back end you frequently had a monolith Rails server. Now
on the front end you frequently have a single page app where JS is much more
integral and comes with its own range of frameworks and it's own pipelines
that seem to change every few years. On the back you now likely will have a
bunch of micro services that want to be orchestrated. Not sure if the world
needs to be more complicated, but it certainly often times is.

~~~
collyw
You could just ignore the JS churn and stick with enough jQuery to be useful.
Most SPA apps don't need to be SPA. Backends don't need to be micro services.

------
lkrubner
I had in mind a similar argument when I wrote "The problem with HTML". An
excerpt:

" _I spent 1995 learning HTML and putting together simple websites. I was
thinking this is something I’d like to do professionally. In 1996 my father
and I went to a demo in New York City, where Adobe was introducing PageMill,
their Web page creation software. My father was impressed. My dad wasn’t in
the tech industry, but he was pretty smart about technology trends. He said,
“Anyone who knows HTML just lost their job. This will replace the need to know
any of the underlying technologies.” But that turned out to be wrong. Even
now, in 2017, most companies building Web software still rely on individuals
to hand-write their frontend code. Indeed, from the point of view of business
productivity, everything has been going in the wrong direction. This category
of software, creating Web pages, was eventually taken over Dreamweaver. The
software came from Macromedia which was later bought by Adobe. In many ways,
Dreamweaver is a great piece of software. It makes it easy for beginners to
get started, and it let’s them do some sophisticated things. But it ran into
some limits. Many of the limits have to do with HTML, and the fact that HTML
is extremely fragile in regards to the how elements are placed on a page._ "

[http://www.smashcompany.com/technology/the-problem-with-
html](http://www.smashcompany.com/technology/the-problem-with-html)

I agree there is an element of gender bias here. People working with
Dreamweaver were graphic designers who were more likely to be women than the
current situation with React developers.

The right path forward, for the tech industry, is to have a technology that is
actually meant to improve productivity for graphic designers, empowering them
with more of the production process. And for us to get there, it is important
that we get rid of HTML. As I said in the previous essay:

" _The problem isn’t with Dreamweaver, the problem is with HTML. It was
originally meant to be a markup language for describing the structure of a
document, but it later became the language people used to build graphical
interfaces for most apps going over TCP /IP. Markup languages are a terrible
choice for graphical interfaces. As much as possible, when creating a
graphical interface, you want to use a declarative system. Ideally, a
declarative configuration file can specify your entire graphical interface.
The entire tech industry is largely in agreement on this. Consider that Quark
Express and Adobe InDesign do not use markup languages, internally, to specify
the graphical layout of the documents that they create. Also consider that
before Oracle bought Sun and killed JavaFX, JavaFX was going in a very
exciting direction, with a highly declarative system for specifying graphical
interfaces. Also consider that every web framework ever invented has systems
for specifying a graphical interface in a declarative format. If you have used
Ruby On Rails or Symfony (PHP) or Grails (Groovy) or nearly any other Web
framework, you are aware that you can build a lot of the graphical interface
by specifying configuration data in a YAML file. But you are probably also
aware that all of these systems fail at some point, and they fail because of
the limits of HTML._"

------
draw_down
> HTML, CSS, JavaScript, Python, C#, and SQL may all be code, but they’re
> really quite different kinds of code and are suited to different kinds of
> people.

What does “kinds of people” refer to? What “kind of person” does it take to
code in CSS? The correct frame is to think of all these as skills that anyone
can grow. If a project requires all these technologies, I don’t see why it
absolutely must be done by more than one person.

I’ll agree that someone coding in various technologies will be stronger in
some than others. The question is, how much of a problem is that for what’s
being built? Or to put it another way, does the success of your project truly
rely on the CSS and SQL being top-notch?

BTW, HTML is not a metalanguage.

