Chris Coyier, a famous web dev whose articles on CSS/HTML/design have helped even lowly me, has a super compelling video my colleague Steven Sacks shared with me. Chris covers the many facets of “what is a front end developer”, the identity crisis the term has, and it’s fascinating. Totally valid in what I’ve seen in the past 8 years.
Now, 5 years ago, I made a video aimed at the skills I saw employers looking for in web development after 6 months of miserable interviews.
Here’s one hiring a front end developer when they really needed what I call a “web designer”, someone with strong CSS chops:
“I need pixel perfect designs. Can you do that?
“No, I build web applications, not websites. You need a guy to code it, I’m you’re man. You need someone to go into Photoshop and convert all those un-flattened layers to CSS, that’s not me. I work with those people to make apps.”
“Interesting… so you don’t build websites?”
“Correct, I build web applications.”
“What’s the difference?”
“90% content? Website. 90% user interaction with dynamic data in the back-end? Web application.”
“Hrm, but that’s what we’re building… and it needs to be pixel perfect on all browsers.” “Ok, who’s going to code it?”
“Same person.”
“You’re telling me you’re going to hire a JQuery developer to use an MVC framework like Angular which still doesn’t support components, with their own Node Restify orchestration layer both of which are deployed with Heroku with their current CICD npm build scripts somehow linked in your Jenkins… that somehow magically got deployed via Docker on some random EC2 which is deployed by your non-existent Ops team using and managing Chef?”
“I’m not sure what all that means.”
“Sir, free consulting advice: You’re looking for a web developer who has HTML and CSS chops. Stop caring about the JavaScript chops, I promise you if they have ‘a portfolio’ with web sites in it, then they can do what you need. Stop telling recruiters you need a JavaScript developer; you don’t. We’re twice the cost of those CSS devs, too, FYI.”
The opposite was those who wanted back end developers who had framework experience, yet pitched it as “an Angular developer who knows .NET” or “a React developer who is familiar with Java”.
“Do you know Angular?”
“Yes.”
“Explain to me MVC, then.”
:: 5 hours later :: “Ok… you clearly know how to program. Great, so what’s your .NET experience?”
“None, I hate back-end, I’ve spent the last 15 years building front-ends and hit everything on the back-end excluding Aida and RPG.”
“Oh… so no .NET then?”
“I can read .NET and C# and VB and could learn to compile it if need be if someone needs fixing, or the XML SOAP needs to be converted to JSON.”
“That’s too bad, sorry, you won’t fit.”
“So 99% of the job is building front-end web applications, configuring grunt builds with various npm dev dependencies to ensure your pipeline accounts for the fact it’s actually deployed in a custom .NET MVC code process because no one spent the time to explain what a Single Page Application is, so you treat it like an artifact in a Java .jar file. You want Bootstrap styled designs with someone who’s aware of how to handle event bubbling so they can hack it into your existing .NET MVC app but not break your modals, yet can get your debug code minified and uglified into a single deployable artifact via require.js + uglify js in that hacked grunt file extension Node script… and you’re telling me that type of person who knows the same design patterns like Observer, Proxy, and Memento like your back-end developers can’t figure out how to tweak a 4 year old .NET service in a reasonable time frame?”
“Yeah.”
“I see… when you guys get bored and re-write your back-end in Node, let the recruiter know and we can repeat this interview.”
It was based on the type of work I wanted to do, and knew was out there, and I knew was coming. Literally 1 year later, I’m interviewing 12 year .NET and Java developers veterans chomping at the bit for front-end Angular/React experience. WAT.
My video even accidentally scored a huge contract for my employer at the time, Accenture. It wasn’t because of me; it was because the skills I outlined consist of MULTIPLE TYPES OF PEOPLE, and large consulting firms can create that village of people, and our client knew that. This “full stack” nonsense had the dumb ones thinking they “could just hire a talented JavaScript developer”. Again, this was 5 years ago.
After watching Chris’ video, it’s fascinating in retrospect to watch mine and see how it is laser focused on “application front end developer”, meaning, I wrote code, avoided HTML and CSS at all costs, and focuses on business logic for the front end browser specifically. My assumption was those watching the video wanted to build apps. Those who already did HTML and CSS with Design would still do the same thing, the industry would just start calling them “Designers” heh… or they’d get pigeonholed into WordPress/Expression Engine/Drupal or even Agency work. To this day, my advice still stands, but so to do the weaknesses. Meaning, if your CSS framework doesn’t support a strong layout story or is even deprecated, a la Material Design Lite, what do you do when all you have is “full stack devs” who don’t have design chops?
You can do one of the following:
- learn CSS and some minor HTML (not happening)
- or more likely find a better component framework
- or even more likely convince your Designer to “design for the component framework”. If you’re building a Bootstrap site, make the design look like Bootstrap; use bootstrap components, use their grid model, etc.
If your company has a design system (and I bet from asking it around, it may have many competing ones if you’re large enough), then you’ll end up encouraging your designer to design around that “so that your team can build things vs. building things to build things”.
As someone who used to interview a ton and has recently only interviewed a little, yet still seen the industry change, I’ve noticed a pattern. In the past 8 years there is a distinct class that I believe Chris Coyier and other UX types are in. Yes, the tree is varied, BUT THERE ARE 2 TREES. They are who I label as “good at CSS” which really means Designers who have extremely good CSS knowledge and write good, semantic HTML that’s easier to make accessible. They still build the web, but because “JavaScript Developers” outnumber them, they’re falsely labeled as designers.
They make websites.
The others, those who are programmers who use JavaScript, also make websites. Most of us don’t really care about CSS and HTML. I don’t think that’s going to change, though.
So what now? There is a huge push for Design Systems in Enterprises. Specifically, something like Bootstrap, Foundation, or Material Design, but branded for your company or department / line of business. You can Google what a design system is specifically (it’s a huge deal and complicated and powerful), but for people like me, the end result is: Components. Meaning, it provides the Leggo’s to build applications. Any front end team building web applications will spend a lot of time “making things to make things”; they’ll take buttons and text inputs to build a form; they’ll use those forms to build input screens for other large components they compose into an application. Doesn’t matter if it’s Elm, Vue, React, or Angular; same problem. You need good looking Buttons to make a good looking, and well functioning applications.
Note I am NOT talking about WordPress, Expression Engine, Drupal, Sails, etc. The “developers” (web designers) who use those types of frameworks already know how to design and build what they need.
Design systems make that possible by 3 important things:
- They handle the CSS and HTML.
- They tailor it to your framework.
- They figure out all the design and branding rules and provide strong guidelines
This is huge. Chris has a great attitude, and alludes to the common theme in our industry of “constant learning” with a positive vibe. That’s great. You can see he also acknowledges that some things will never be learned by particular people because they simply don’t want to and have passions in other areas. HTML and CSS, and their design result in particular with company / line of business branding, requires a massively different skillset than Object Oriented Programming. The person in your company creating design atoms, thinking about accessibility, re-reading Steve Krug, gorging on https://www.nngroup.com/articles/ articles, and iterating on layouts and terms in Sketch is not the same person encouraging your front end and orchestration API teams to leverage Algebraic Data Types as a replacement for if/statements when a compiler isn’t present.
Different people. Different teams. Different skillsets. Same goal, though: Build awesome websites.
Those creating the design system which leads to a component framework like Material Design for React or Bootstrap for Angular are the ones empowering people like me to be effective to build things without worrying about our weaknesses. Specifically knowing the design and layout languages of the web: HTML and CSS.
That’s one thing that should continue to be encouraged. Large swaths of the enterprises I’ve worked with have completely broken interview processes and wrong interpretations of the village it takes to build small and large web applications. If you’re going to continue to hire programmers and designers, but not hire those who know how the web is built, then at least have those who do know and somehow exist in your company empower those who don’t. Let them build design systems that turn into component frameworks that front end web developers can use to make awesome, branded applications.
Lastly, we should acknowledge, despite projects that vary on the skillsets needed, that it takes a village to make great software. If you have even an inkling of custom design, you need at least someone who’s got HTML/CSS chops on your project, or your department to help support the other teams. Else, you’ll get teams that focus on functionality, and less on design intent… because they can’t. They don’t know how, waste time on it, give up, and it validates (falsely) that it’s a waste of their time because it’s not their passion, encouraging less of a care in the future. Ask any designer if the developers they work with take ownership of their designs, and the ones who say “yes” will have the UX types Chris refers to on their team or within support reach.
Those who say “no”, don’t. They may have the will, but they won’t have the skillset.
Below is one of the compelling examples of the myriad of skillsets that make up a “front end developer”.
If you’re hiring front end developers for your company, I highly encourage you to watch Chris’ video. If you’re in a hurry and want the executive summary, watch from 20:00 – 22:15. If you want your head hurt on concepts that validate just how broad front end development is in terms of skills and focus areas, watch 27:15 – 29:31. These developers who used to build the web, and now continue to build “web sites” are not being carried over en-masse into the Enterprise unless they’re willing to lie about their React, Node, and JavaScript skillset or are hired as UX Designers. It’s a mistake. Like Brad Frost says, they are the “Front of the Front” and I’m the “Back of the Front”… and even then, I don’t even do Webpack, the current popular JavaScript compiler. I outsource that to Facebook in create-react-app or Angular CLI or Vue CLI to be the “Back to the Back of the Front”.
Recognize the differences. Communicate that to your managers. Explain the risks of not having people with CSS chops (Design and Product/Business is your ally here) on your team(s). The world has changed how we build web applications, but the core design language, while vastly improved and more complicated, has not. If you know HTML and CSS, your industry has a huge branding problem. Half of them are fine in the Agency world. Those working on websites with that use SPA frameworks, we need to fight for you to be at the same table as us as you’re desperately needed to make our front end team “complete”.