The Problem with Full Stack(heydonworks.com)
heydonworks.com
The Problem with Full Stack
http://www.heydonworks.com/article/reluctant-gatekeeping-the-problem-with-full-stack
23 comments
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.
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.
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.
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?
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?
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
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."
"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
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."
> 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.
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.
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.
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.
> “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.
And with that, an interesting article, putting forth an already controversial proposition, lost any hope of rising above a comment flame war.
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"
> 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"
Can we have one opinion article that doesn't devolve into some form of identity politics? Can't we talk about full stack development without it somehow being that men are sexist against CSS?
Yeah, that comment was really unfortunate. HTML & CSS is undervalued, but it has very little, if anything, to do with gender bias. It has a lot to do with the fact that a) it's really hard to write requirements for those things and b) the minimum bar for getting any results at all is a lot higher for programming, so that tends to get the most attention.
If it is undervalued, it's probably because it's a safer environment that many people work with. It's hard to write css that's going to leak information or allow root access. There aren't a ton of performance gotchas either. However, I believe an expert who can make things right on the first try instead of tinkering and copypasting their way around should fetch a good salary.
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.
Hyper-specialization, while probably useful at Google, NASA, and Honda, is just not something I think most business software needs.
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.
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.
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.
"specialization is for insects"
http://wiki.c2.com/?SpecializationIsForInsects
http://wiki.c2.com/?SpecializationIsForInsects
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.
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.
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.
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.
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.)
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.)
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.
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.
"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
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
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.
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.