There's been some controversy about the term "Full Stack Developer" recently. There was this image floating around for a while:
“5 minutes to go” - a concept art piece that depicts how people think of what full-stack engineers work on - i.e. - “They’re all back end”
I understand the concept. No one can be an expert in everything. No one should try. It makes sense to be deep in some area, and broad overall, but to expect any developer to be able to pick up anything on any given web app, software product, infrastructure project, etc, is a real management fallacy, and that is a problem if that's what your organization counts on.
Well, at first I was offended.
Because I think I'm filling in the detail on the entire horse.
Except, of course, I'm not.
My work is very much front-end these days. I write a lot of React code, and need to understand the triumverate of web programming languages JavaScript, HTML, and CSS very well. I have about 10 years experience of writing Ruby, especially in Rails, but also as a general-purpose lanaguge. Developing web apps also requires understanding of system and shell languages, as well as understanding how databases work and the languages associated with them. My practice has included working as a business analyst, to uncover users' needs and translate them into actionable requirements for developers. I've worked in quality assurance, as an engineer, to develop processes that ensure customers and users get valuable and useful products. I've worked from deep in the guts of a unix kernel, writing device drivers, to the front of a dashboard control panel for network administration.
I am a generalist. But more important, I'm a problem solver. Sure, there's no way I can solve every problem, but I can pretty much understand problems well enough to find out who can solve it, and understand how it fits into the whole. So what does that make me?
While I'm writing a React component, I'm deeply interested in how the user experience of it manifests in solving a problem for the user interacting with it. What task are they hoping to accomplish, and am I writing the version of this component that's going to fulfill (part of) that task in the best way for the user?
While I'm writing that, am I going to be able to interact with our services and databases without taxing them or costing us more in infrastructure and/or support system nightmares?
In the specific area I work in, I'm using GraphQL, and there is no one else on the team who understands how to write a GraphQL API into our backend, so I do that as well.
So what does that make me? A unicorn? I don't know if it does. We have a small dev team (just enlarged by 2 people, but then diminished by losing our tech lead / manager); we all need to work all over the app. Some specialize in specific knowledge, but we also need to share knowledge of the product so it doesn't get lost and so people can review each other's work. I've spent the past couple years as the primary front-end dev without anyone to bounce ideas off of, or give solid review feedback; the team is super supportive, but mainly it's feedback like "Looks good to me!", "We trust you!", and so on; i.e., not constructive even if quite supportive. For the first 6 months, another team mate was also newly working on the mobile app; we couldn't even really give each other constructive feedback in that time. 2 years ago I wasn't working on the front-end at all. No question my breadth of experience over the years has let me make it through to here, but it hasn't been easy. So maybe this horse's front end is just a stick figure. But it won't stay that way.
I do think there is space in this world for generalists, but I don't think expecting such generalism to equate to being capable of all things anywhere in the product is doing anyone a service.