The official book of California Stylesheets
(and that's okay)
It's a book about writing CSS.
And not writing CSS.
The official book of California Stylesheets
(and that's okay)
It's a book about writing CSS.
And not writing CSS.
The format of this book is probably a little bit grating by now. It’s okay. This is the last chapter.
The idea behind YSA is to realize that not being great at something can actually be a benefit. Not being great at something can lead to not doing that something. Not doing something has a greatness of its own.
Not doing something turns a boring and predictable something into an exciting and fantastic anything. What will you do with the time you save not writing CSS? No book can answer that.
Software developers often have a tendency to do too much. Treat YSAC as a blocker or an enabler of this tendency. Really it works as either.
As it turns out, most people suck at most things. That’s how skills work and it’s why we specialize.
There’s a second part to all this too: Imposter syndrome. I like the spelling with an “E” because it looks like it’s wrong, like it’s posing as the real word.
The tendency in software development is to combat imposter syndrome by just learning a whole bunch of stuff. We’re like carpenters who want to use every tool on a project, just to prove to the other carpenters that we can use a lot of tools.
Actually, it’s all a little ridiculous now that I think about it. Somebody should write a book.
Anyway it goes something like this. The frontend people have to show their work early on when it looks terrible. They feel bad about it. The backend people eventually have to show something, and everything they put together for human viewing looks terrible, because Java and Python eat the part of the brain that does design. They feel bad about it.
But why?
Everything just looks bad and super far away from what everyone ultimately wants early on in the project. This is a reality. Imagine construction workers striving for “pixel perfection,” making each room of a house perfect as they build it. That’s us. That’s web developers.
Teams can gain massively by just accepting that houses (which, to be clear, are software projects in this non-archery metaphor) look bad before they’re finished. There should even be a certain pride in it. The ideal productive path, the path that has the least work and the most gains, looks like crap. Every idea you disprove before writing CSS for it is just a whole bunch of time saved.
Visual design is important, sure. But only to the user. We need to be aware of what it will look like in the end, but we need to get the thing working right first.
In software, form vs. function is a fundamental question. It determines the whole tone of the relationship between software and the user. In software development, form vs. function is not a fundamental question. Function wins. It’s not even close. The teams who are chasing form are wasting time 90% of the time. Snapchat and stuff like it are the exceptions but you’re not Snapchat.
CASS bumps up the standards of your “minimum working design” to a more acceptable level.
Acceptable to whom? The little nagging voice in our head that says “This looks bad.”
It’ll never go away because it’s our inner child or something. But we can make things look mostly okay with CASS right there in the markup. With no tooling or overhead to increase our stress even more.
Then, finally, we can not feel bad about it, and just get some work done.
The Gumroad version contains a secret chapter that spills the dirt on CSS preprocessors, a tech CASS no longer uses.
