CSS is no longer a core skill

Is it even worth learning CSS these days?

Plenty of organizations in tech don’t understand why they’re spinning their wheels when it comes to styling their site or app, especially early on in a project.

What’s the disconnect? Well, CSS is no longer a core skill in web development, but a specialty skill. And a lot of shops haven’t yet realized it.

In the beforetime, if you had a team of ten developers, each and every one of them had to know CSS. Even the developers who barely knew it, still had to know enough to get things mostly presentable.

You simply couldn’t get through the day without knowing floats and other esoteric rules in CSS. (They’re all esoteric. Don’t ask me how.)

Let’s back up. There’s a closer-to-the-core issue here. It’s an issue of presentation and standards.

Your company is always going to have two sets of presentation standards: One internal and one external.

You should do everything in your power to keep the external presentation standards high, and the internal presentation standards low.

Let me repeat that: Keep your internal presentation standards low. Internal presentation standards creep, like tech debt, FOMO or build times.

High internal presentation standards are a bad signal at any company. Your peacock-to-plumage ratio is plummeting. You’re spending time on media and presentation without the mass media lever.

Let’s back up (within our back-up): High external presentation standards are pretty obvious, right? It’s stuff like consistent design, beautiful art and high framerate in your main product that your customers use. Every little thing you send your users is carefully trimmed and curated, sometimes by a team of people. It’s all beautiful. Duh.

When it comes to your co-workers, though, you can just use a hastily written sticky note. Or an email where you just didn’t bother with the Shift key. It’s about what works, not about how it looks.

There’s a simple idea at work here: If the sticky note works, then any solution that was more complex probably wasted time.

Of course, humans at work are like the humans using your app or site. They respond to nice colors and layout. There’s a strong urge to prettify presentations and other internal communication just to stand out in terms of office chatter. This urge should be resisted. This urge is about 90% wrong.

Unbacking up: What do internal and external presentation standards have to do with CSS? If you have a team developing for the web, everything you build is seen before it’s seen. That first time it’s seen, by the other members of the team, it’s operating on internal presentation standards.

Internal presentation standards are a company-wide mindset thing. If you raise the bar for how documentation or any other internal thing looks, expectations for everything else go up too. This includes, crucially, the first working prototypes of the various features you’re building out.

These internal standards slow teams down, sometimes drastically. They add overhead to every single thing that gets worked on. Worse, internal standards waste time early on in a project’s life, when everyone on it should be enjoying a greenfield effect where everything is fresh and easy.

Going back to our hypothetical team of ten developers: When we think of who needs to know CSS, we think of who needs to know it in terms of external presentation standards. But internal standards are important here too. And here’s where all the gains have been made by CSS frameworks over the past few years: Nobody on the team needs to know CSS--at all-- in terms of internal presentation standards.

For certain very individualistic bull-in-the-China-shop developers, these form vs. function standards are very low. You’ll see the unstyled edges of their products live in production. They are the kings and queens of never wasting time. They ship once and only ever fix bugs. Their ancient interfaces stand, unchanged even today.

But this just-function/never-form development style can’t work for most teams. The reality is that internal presentation standards have to be at least somewhat high or the perfectionist personality types in technology go crazy.

In the beforetime, on our ten-developer team, all ten developers had to know CSS to ship stuff internally. Even the most CSS-averse backend developers would throw their hands over their plain-HTML-containing screens when you walked in the room.

“No, don’t look!” they’d cry, “It doesn’t have any styling yet!”

The beforetime was a time of shame. And text that just ran all the way across the screen.

Then, Bootstrap and the “container” CSS class happened. Since then, the number of developers who need to know “internal CSS” has steadily declined to zero. The number of people needed for external CSS and finished design stuff? That’s about the same.

In the You suck at CSS book I call this set of internal CSS needs the first 95%. Libraries like Bootstrap, Tailwind and Cavepaint (a new one, in fact the one peddled by this very site and its namesake book) accomplish this handily entirely in the markup. They’re so good that any developer can get by in terms of internal design standards without ever knowing CSS. The fundamentals of markup and HTML are still important, but most developers can scrape by without the “/CSS” tacked on the end.

Since everyone no longer needs to know it, CSS drops from a core, web-development-101 skill into a nice-to-have. Something maybe one or two people on the team need to know.

Want to learn more? Want to know what else you can throw out of the boat? Want to know the secrets of truly scrappy design and architecture? Check out the book here.