Heydon Pickering published a fantastic post called Reluctant Gatekeeping: The Problem With Full Stack. I have about 3 blog post drafts covering similar ground and apparently we see very much eye-to-eye on this, so I thought it might be worthwhile to walk through Heydon’s post and layer on my commentary.
Much of my career as a web designer has been spent, quite happily, working alongside programmers, engineers, people with computer science degrees. In this symbiotic relationship, each party has a secure job with a well-defined role, and gets to work on the thing they are best at and enjoy the most.
We all code, because we work on the web, but we code in different ways to achieve different and complementary ends. But that’s not so obvious to someone who doesn’t code at all: it’s easy to think coders are people who do all the code you’re not doing — because, to the untrained eye, all code is the same.
Hear, hear. I’ve written about my own experience with this misunderstanding.
This was the beginning of my years’ long campaign to help people better understand the role of frontend design and to recognize it as a first class citizen of the web design/development process. I’m certainly thankful there are quite a few fellow travelers on this quest.
This misconception has unfortunate consequences, exacerbated by the non-coder often being the one who gets to choose and hire technical staff. The doctrine of capitalism dictates you should squeeze the most value out of the fewest resources. That’s how you make a profit. If you can find wage slaves willing to do All The Codez, then you can significantly diminish your biggest overhead: people.
I can see full-stack development emerging as a result of capitalistic exploitation, but I tend to chock it up more to a lack of understanding. Think about job postings with their comical spray of languages, buzzwords and technologies. Think about recruiters spamming every frontend developer for an exciting Java opportunity. Earlier in my career, I was on teams where even our project manager didn’t have a good understanding of who does what code and why.
I love how Heydon associates each language with its purpose here. And absolutely while all these languages are code, they do wildly different things. This leads to confusion from the outside, which affects the coders themselves. Again, my own experience:
There’s a fundamental misunderstanding that all coding is ultra-geeky programming, which simply isn’t the case. HTML is not a programming language. CSS is not a programming language. But because HTML and CSS are still code, front-end development is often put in the same bucket as Python, Java, PHP, Ruby, C++, and other programming languages. This misunderstanding tends to give many front-end developers, myself included, a severe identity crisis.
“All code is the same” leads to confusion on the outside, which inevitably leads to the practitioners themselves becoming confused, self-doubting, and anxious. Fun!
This is all to say that, if you put someone in charge of all of these things, it’s highly likely they are going to be much weaker in some areas than others (I’m identifying a trend here; there’s no need to comment with “but I can do all the things”, thank you).
It’s tempting to think that being full-stack means giving equal weight to the whole spectrum. But that’s not how things work. It’s impossible to make everything a priority; inevitably things slip between the cracks.
Worse: they’ll tend to have little interest in improving in areas with which they don’t identify or for which they aren’t rewarded.
This is important. When confronted with the fact we can’t know and prioritize everything, we can take two paths. One path is to acknowledge our own weak spots and take steps to remedy them (by collaborating with people who can fill in those weak spots or to educate yourself). Another path is to write off those weak spots as “easy” or not-all-that-important. The former path comes from a standpoint of humility, while the the other path comes from a standpoint of (what could be perceived as) arrogance.
As an inclusive design consultant, one of the most glaring issues with making Full Stack Developers the gatekeepers of all-things-code is the pitiful quality of the HTML output. Most come from a computer science background, and document structure is simply not taught alongside control structure. It’s not their competency, but we still make it their job.
This mirrors my experience as a consultant. The “full-stack only” organizations I’ve encountered are quick to show off a dizzying array of testing suites, build processes, and optimization tools. And their markup and style architecture is almost always lacking (to put it nicely). That’s not to say those suites, processes, and tools aren’t important pieces of the puzzle; it’s just that they’re not the whole puzzle.
This is well stated. I’ve gotten piled on for poking fun at the CSS-in-JS beehive (which is why Dave Rupert lovingly referred to me as “Beehive Brad”). It’s a different way of doing things, but yeah the technical differences aren’t huge.
componentDidMount(), linters yelling at you, and the whole build blowing up because you forgot to camelCase a style attribute doesn’t exactly lead to a welcoming environment for non-programmers.
While there are some gleeful Full Stack Developers, many are computer scientists given too many responsibilities, and over things for which they are not willing or qualified to be held accountable.
I agree with this. Heydon says a full-stack developer is “in practice, a computer scientist who also writes HTML and CSS” and I agree.
We need to address the undervaluing of HTML and CSS for what it is: gender bias. Even though we wouldn’t have computer science without pioneering women, interloping men have claimed it for themselves. Anything less than ‘real programming’ is now considered trivial, silly, artsy, female. That attitude needs to eat a poisoned ass.
This is an interesting point. I’d love to hear some other perspectives on this, but I’ll say from my own experience that when I’ve discussed my own struggles or poked fun at technology, the inevitable dog-pile that results is exclusively made up of men. It’s important to be able to talk openly and honestly about how this field can be hard, so this attitude (whether real or perceived) has negative effects:
When I talk about this stuff, I have a lot of people — even seasoned, prominent people — quietly whisper to me, “I think this stuff is hard too.” There’s something very depressing about that. I believe that openness and sharing is what makes the web industry amazing, which is why it’s unsettling that these conversations increasingly feel like they’re driven underground. It’s especially depressing when women and people of color tell me now they especially don’t want to say anything too loudly.
So yeah. Whether it’s explicit gender bias or not, it’s important to recognize that people are afraid to speak up about how they feel for fear of getting dog-piled on by a bunch of “real” developers. That needs to change.
Maybe this isn’t really about full-stack or backend vs frontend or any of that. Maybe it’s about the fact that this is all playing out inside of one language. Here’s Heydon’s last two points:
We need to revisit the separation of concerns principle. We simple can’t afford for people to have to know everything just to do something. It’s good that we conceptualize designs in terms of self-contained components now, but that can be a mental model without being a technology-specific land-grab.
Most of all, we need to educate people who don’t code at all just how many different things different types of code can do, and how different each is to understand and write. Hopefully, this way, more of us will be writing the kind of code that suits us best, and not spending our time anxious and demoralized because we don’t know what we’re doing.
It’s fair to say that’s happening. But it seems like we’re taking it a step further:
In any case, thanks to Heydon for writing a really insightful post.