I don't think Full Stack should mean "every technology out there". Rather, I think of it as meaning "having touched every layer", however you want to define layer (database, business logic, UI, network, etc).
Of course nobody has done every language and framework. But plenty of people could do any language or framework.
I think there's a certain stage you get to as a dev where you can more or less pick up anything. This goes especially for things like OO languages. The reason it works is that you're rarely in the far reaches of your new language/framework. There are certain things that are common in OO, and if you swap languages, the learning curve isn't that steep, and you'll mostly be doing things that have an analogy in what you already know.
This article is built on a misconception held by many people.
That is - treating mobile apps as something simple. They are not. Mobile apps of Android and iOS are full stack native client apps.
Building mobile apps is far closer to building your classic Windows desktop applications than an UI for a Web Application and it shows on the astronomic costs of the mobile apps - compared to Web Apps.
I guess that is because user interfaces tend to seem simple and the devices which run these applications are small and seem simple.
TL;DR: Mobile Developers are Full Stack Developers in their own right and the person writing the article should know better.
The impression I get is that this is a bit of projection on the part of the author. Since they can't keep up with web, server, and mobile fronts, probably no one else can either.
Having highly specialized engineers for each technology in a project might be nice save two things: 1. small companies and startups may not being able to afford the minimum upfront resources needed to do this and 2. overlap of expertise in a team is essential to a cohesive effort and a solid product (I have worked in places where people all specialized and did not stray from their neat little box; the results were never pretty).
I also have a tough time taking the author seriously on this subject when their GitHub account is 5+ years old with no activity [1] — no repos, no commits, not even a starred project.
Just FYI, that only shows his public activity. My own Github activity chart looks sparse even though I push to it hundreds of times a week. Almost all of those commits, except for the odd bugfix to an open source project, are to private projects. When I see my own chart, it's dense but when I view it as an anon it's barely checkered.
The author's definition of "full stack" is rather strange, as others have noted. But as the client side of web applications becomes more complex, it's true that it's harder for the same programmer to develop both the client side code (which may involve developing a sophisticated client side architecture in Backbone or Angular) in addition to the server side code and API layer. I see more programmers now who call themselves "front end developers" and aren't just UX designers with HTML/CSS knowledge, but can program a complex client side MVC application, working with a separate backend developer who focuses on the API.
I think this trend will accelerate as web applications are increasingly broken into loosely coupled services, with a rich client tying them together in the browser.
> I see more programmers now who call themselves "front end developers" and aren't just UX designers with HTML/CSS knowledge, but can program a complex client side MVC application
It's almost misleading these days for a designer with HTML and CSS knowledge to say they can do front-end development. If you can't navigate your way around a client side MVC framework, I don't think there's much you can contribute.
The author has confused the audience with his own definition of full stack. Full stack in traditional sense only meant server and client side development. Mobile, Cloud, Machine Learning are other independent horizontal offshoots.
Seems like his expanded full stack is due strictly to an expansion of platforms that it's become standard to deploy on (i.e. you don't just release a website, but also have a native ios and android app)--excepting machine learning, which I can't see a reasonable argument for including as integral to a canonical web development stack. He suggests we will resolve this through a change in methodology--but this problem isn't new and it seems to me that we're as likely to sort it out with technology instead.
That and buzzword compliance. Why are MongoDB, Scala, and machine-learning on the list? What customer-visible advantage do they give your startup that your existing Rails/Django app on MySQL/Postgres doesn't have?
If you want to use machine-learning effectively anyway, you need to have a bunch of other technologies, like crawling & unstructured data extraction, or custom log processing & millions of users, or some other way to get the raw data that your machine-learning algorithms can process. Without data, machine-learning is useless. But that's a problem for an established company, not a startup, and established companies have long wanted specialists anyway.
If I were to shoot for the most charitable reading of the article, I would abstract a way from particular brands and replace Amazon with "cloud hosting(AWS, azure, GC, ...), mongo with "scale out database", scala with "modern language", and machine learning with "data science".
With such replacements the article looks fairly reasonable - larger scale demands newer technologies, proliferation of client platforms demands more suppor for them, and growth in computing power and science makes users expect some smarts they did not demand a decade ago.
Except that within the context of startups, it's still not reasonable. You don't need to scale when you're first founding your startup: your biggest challenge is building a product that one person finds useful, let alone one million. You can run such a service off your favorite shared webhost, or a single EC2 micro instance for like $10/month, or just use the free Heroku plan.
If and when your service catches on, then all the article's points become valid. But then you'll have resources available to hire specialists - and the full stack developers you hired in the early phase become full-stack integrators managing teams of specialists, assuming they have the ability & inclination to grow with the company. You're going to have to rewrite your code and throw out your early technology choices anyway: you might as well take advantage of the full stack developers you can find to get to the point where you can afford the specialists.
"I'm sort of skeptical about the long-term necessity for native apps for most businesses."
This says it for me. There's a ton of work for enterprise app developers out there, without the slightest need to address the iOS or Android ecosystems. Deliver your goods via the browser already. Yes, it is insanely complicated, but it works. And I know a bunch of full-stack developers, fwiw.
Nobody would call for a 'full-stack' automobile worker who can assemble engine, chassis, interior and paint the whole thing (o.k. paint is done by machines nowadays). 'Full-stack' is a sign of an immature industry that hasn't figured out division of labor yet.
Using this automobile production analogy, I would say that a full-stack tech engineer is analogous to an autoengineer who understands all levels of the production, with some direct experience in the types of relevant manufacture processes of all components of the automobile, as opposed to only understanding based on the blackboard theoretical description of auto production. They know the design principles of engines and of electric systems, and materials science, and the relevant history of the industry leading up to the state of the art. They could join the division-of-labor sub-team for any arbitrary process of production, because they understand any arbitrary process at the blackboard level and have some general experience in the types of any arbitrary manufacture process -- though they are never actually permanently required to stick to just one sub-unit of operation. And thank $deity someone does understand the whole picture, otherwise no one would, and you're just waiting for some new problem to bring down the whole cargo cult operation.
This is in contrast to someone doing one aspect of the division of labor, who knows his division, but doesn't understand the full stack of automobile development. "I just make sheet metal into body parts. Engines and electrical systems are magic to me."
Not all code production houses need full-stack expertise, because they actually can operate in their niche without it thanks to our system of finance and contracts. Most don't, in fact. But big operations (a la a major automobile company) had just better be sure they have engineers who understand automobile production from design to showroom (reverting to the analogy).
I stopped reading when they substituted a relational database for MongoDB. Nevermind that they both solve completely different problems.
This post must have been written by an incompetent business analyst who feels all warm and fuzzy when he parrots the most popular buzzwords of the month. This kind of shit makes our jobs harder because managers see this stuff and decide that "our next project will be built on MongoDB and Amazon Cloud... it's bad ass rock star tech!"
The issue is that even though most of us have the spare time to hop on a plane and go mine some rare Earth metals ourselves, while tweaking an ARM chip specification, in fact when it comes time to building a foundry for it we are too gunshy to lay down $1B-$2B. As Wikipedia states, "Prices for most common pieces of equipment for the processing of 300 mm wafers range from $700,000 to upwards of $4,000,000 each with a few pieces of equipment reaching as high as $50,000,000 each (e.g. steppers). A typical fab will have several hundred equipment items."
Well, either that, or full-stack doesn't mean what the author thinks it does :)
What does mobile app dev have to do with a full web stack for example :)
> What does mobile app dev have to do with a full web stack for example
While the author's definition might be too expansive, I can answer that one: Design your APIs to support mobile clients that sync, for which you'll need an experienced mobile architect, or your mobile clients will be stuck not taking advantage of local storage for better performance and resiliency in situations with unreliable connectivity.
If you treat mobile as an add-on, it will bite you in the ass.
Full stack: Someone who can build one (1) stack which fulfills the business requirements. Database to backend to frontend(s). If you're using rails and Django at the same time, and your full stack engineers have to take on an unnecessary cognitive load, that's your problem.
I think as a joke there should be a 3/4 stack developer trend as the new hotness -- it should signal "I am competent in one area as opposed to a jack of all trades, master of none"
If I was looking for positions I put that on my resume.
Most programmers never do or use machine learning, and in fact most people who call themselves "data scientists" don't know the first thing about it. Knowing a package with some canned algorithms in it is not one tenth of the battle. If you can write a logistic regression or SVM from scratch (not that it has to be as good as the existing product; in practice, you'd probably to use an existing QP solver, for example) we'll talk.
I also don't think Scala is part of "the full stack". Worth knowing? Sure. Powerful? Yeah, it's quite a large step up from Java. You'll want to know it to use Spark, and it's a great "gateway drug" for Haskell. But I don't think it's on the list of things that a person needs to know to call himself a "full stack web developer".
Anyway, someone needs to write a terrible language that isn't so bad that no one uses it. Take all the worst features of C++ and Java, bolt on some enterprise crap, make your shitty ORM a first-class citizen, and then sell the shit out of it. (It can't be unusable like Brainfuck, but it can be worse than Java and still sellable to the enterprise.) It'll be a nine-figure effort, but I'll spot the first $200. Here's the one rule: this shitty language has to be named FullStack. Then we can be done with this shitty buzzword because "Full Stack Developer" will mean something else. Bonus points if it's attached to a "hip" but broken database system called Big Data.
Of course nobody has done every language and framework. But plenty of people could do any language or framework.
I think there's a certain stage you get to as a dev where you can more or less pick up anything. This goes especially for things like OO languages. The reason it works is that you're rarely in the far reaches of your new language/framework. There are certain things that are common in OO, and if you swap languages, the learning curve isn't that steep, and you'll mostly be doing things that have an analogy in what you already know.