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.
It’s not that the computer scientists get to do all the code; it’s that they get to do architecture while I do communication, form, and interaction. 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.
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.
And so the Full Stack Developer emerges in the market, like an Uruk-hai emerging from its grimy placenta: stronger, better, problematic.
By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well. This has two adverse effects:
- Poor quality code
- A bunch of people who can (and would enjoy!) expertly writing that code, standing unemployed on the sidelines muttering “WTF”
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.
To a ‘classical’ computer scientist, CSS can be quite elusive. Features like the cascade just don’t feel right. To make CSS easier to write and manage, it becomes subsumed by something more familiar, hence CSS-in-JS.
CSS-in-JS is often characterized as a solution (by practitioners) or a problem (by naysayers) in technical terms. I don’t think it makes the actual CSS intrinsically any better or worse — it’s just a different way to write it. But that’s not to say it doesn’t pose a grave cultural issue:
To conclude, here are a few things I think we need to address:
- We need to identify exploitation. 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.
- 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.
- 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. That’s not to say that if you do take to JS, CSS, HTML, SQL, and C# you shouldn’t be writing all of them if you‘d like to and you have enough time!