A bit of a rant
The cascade is something like a new data structure, and the ways for dealing with it are algorithms you never learned in school. You couldn’t have, because traditional engineering school poo-poos the front-end and web engineering in favor of stale (but still valuable) traditional software engineering.
Nothing works as you expect it to. Your columns won’t line up. You never validated your HTML, and you have a sneaking suspicion that there is an unclosed tag somewhere. You can’t make even the simplest design look right, and you are pretty sure CSS is to blame, rather than your understanding of the technology. This should be just another acronym on your resume, right?
No. Resoundingly, no.
Take for example, calculating the complexity of a given solution. If you were to calculate
O(n) in CSS,
n is adding more pages and modules to the site. What happens to the size of the CSS file? It goes up, right? But does it grow like a fifteen year old boy? If so, you’ve found the CSS equivalent of
O(n^2). When you keep that stylesheet lean and mean by effectively using the cascade, the fundamental solutions are algorithms, but no, your engineering professors won’t have mentioned them.
If you did manage to get a site up and running, you’ve noticed how fragile your code is. You touch it on one side and it breaks somewhere else entirely. You try to sandbox individual components to prevent this, and your CSS file just keeps getting larger. It is unmanageable, unmaintainable, and it doesn’t scale. Again, you think, CSS sucks, with all these inherent flaws.
You think of people who do know CSS as designers, not giving any credit to the engineering prowess required to tame the stylesheet of a multinational corporation because (self-taught as they are) most true front-end gurus don’t speak the same language as you do. Their skill appears to be a black-art, some kind of magic, or internalized instinct for browser flaws. This is your guess anyway, because you simply can’t communicate with them. They didn’t go to the right school, or maybe they studied japanese modern literature instead of databases and sorting algorithms.
Furthermore, you don’t understand why it is so hard to hire them. You said to me once,
“I can sit at the exit of the best engineering schools in the country and scoop up software engineers, but I have no idea how to find you people!”. You’ve been writing CSS yourself for a couple weeks, so you decide you are ready to hire a web developer / designer / front-end engineer. The role is pretty unclear, but in your organization they’ll either be alone in a team full of software engineers, or they’ll report to the Artistic Director in the marketing department. You’ll give them goals like “learn SQL” or “some C++ would be really helpful”.
I once said in an interview, “If we talk about what I know, we’ll arrive at the limits of your understanding very quickly, and if we talk about what you know, we’ll arrive at the limits of my understanding very quickly. So what do we talk about?”. The engineer interviewing me took it well, and I was even more impressed with the company.
By now you have 3-4 weeks of CSS under your belt and you can confidently say, “CSS sucks, our organization will use tables.” Excellent choice grasshopper, if you can’t win, blame the game.
An attempt at a solution
We need your help. Web development and client-side technologies need a dose of best-practices from software engineering. We don’t need you to solve problems for us, nor will our solutions necessarily be the same as yours, but we need to learn from you rather than reinventing the wheel, so that the front end can mature as a proper engineering discipline.
This is virtually impossible unless we develop a mutual respect for each others’ skills, and software engineers make an effort to understand what makes a good front-end engineer. Hint: it may not be exactly the same skill set, and certainly not the same technologies. Like it or not, managers tend to be software engineers, and you need to understand how to work with your developers to improve the state of the art.
You might be an engineering manager, with a self-taught front end engineer sitting before you in a fish bowl conference room you use for interviews. Look for:
- A sense of design, attention to aesthetics. Tattoos, weird hair, artistic hobbies, or slight OCD are good things to look for here. They need to care that the h3 are 1px off from where they should be. 
- Semantics and clean HTML – foundational, if they don’t have this, be very afraid. If you hear
DIV DIV DIV, be very afraid. Note: you may need to study up yourself to judge this. I print out a mockup (psd for example) that I am currently building and ask them to draw squares on the paper representing the different HTML tags. I draw a box around one paragraph to get them started. I’m not looking for perfection, just the ability to comprehend the difference between the meaning of things and the display.
- Approach and problem solving – make the problem concrete and visual if possible, move slowly toward more abstract questions to judge their ability to generalize a solution.
- Algorithmic mind – assume no prior knowledge of traditional algorithms, but they should be able to understand algorithms you’ve explained and tie that back into the code they write. Again, make it visual.
- Complexity and scalability – they might not be thinking in this way (yet!), but if you talk about what happens if there are thousands of pages or an unknown number of user generated modules they should be able to explain the failure points of their code.
- Experience – Be aware of the team the developer will join. If they are alone, you can’t hire a beginner. Their skills won’t develop, and you will be frustrated by the fragility of the code they write.
To solve the communication difficulties, think:
“My web developer is smart, so smart she learned a kind of engineering for which there is no school. The technologies she knows are as relevant, complicated, and legitimate as those with which I am more comfortable. I may never be an expert in those areas, but I can help her learn the vocabulary of algorithms, complexity, modularity, and scalability so that she can write better and better code. Furthermore, I will never again say that CSS sucks rather than admitting my own discomfort with a different problem space.”
Stay after school and write that last line on the board 100 times.
CSS can be predictable, scalable, modular and even object oriented. If it is written correctly, beginners can be productively participating in creating clean, reusable code in 2-3 weeks. It is simply a matter of changing our approach, understanding that the fundamental algorithms for a display language are different than a programing language, and borrowing everything we can from software engineering, so that we don’t spend time reinventing the wheel.
And If you still want to be an F2E?
Check out this F2E skills list presented by Leslie Jensen-Inman at Web Directions North as a part of her dissertation on the state of web education. Note: even the non-acronyms count as skills.
Thanks to Nick Fogler of Juku at Yahoo! for his ideas on aesthetics and F2Es.
 The Ajaxian post that made me feel like ranting: http://ajaxian.com/archives/css-for-layout-another-rant