The Web is Big Enough for Everyone

Next to writing code, front-end developers (myself included) seem to focus a lot on job titles. I mean, crap, I’ve written my own fair share of posts on the topic. Anytime we post about it on CSS-Tricks, it never fails to strike a nerve and result in a flurry of comments.

(Note to self: publish more stuff on job titles and cash in on the web traffic!)

I’m not here to add any clarity to the situation. Job titles are hard regardless of the industry you’re in. They’re often the by-product of how an organization is structured, how a particular team is resourced, pay scale, politics, egos, or whatever the heck else you can think of. There’s clearly no standard, whether you’re a front-end developer, a back-end developer, a bank teller, or stuck in middle management.

It all depends.

What I can do is sum up what I think are the buckets of angst driving the conversation.

The ever-evolving spectrum of the web

I was just talking with a friend this morning about a project we worked on some years ago, like 2009. We spent several minutes reminiscing about the decisions we made back then. Like, web typography just wasn’t a big deal back then. Google Fonts didn’t even launch until 2010, to give you an idea of the time. We cared about a lot of things, mostly newer CSS3 properties that allowed us to ditch PNG images for real rounded borders, add box and text shadows to all the things, and do fun little things like animated image sprites.

Things have changed. These days, yes, web fonts are not only a thing, but arguably a profession unto themselves. My buddy Robin makes it look so easy, but I know he puts a lot of effort in how he chooses and implements fonts. I wouldn’t expect anyone to know as much as Robin does about fonts, no matter how good they are writing code.

And that’s just type. There are plenty of other niche areas of specialization these days and people who care deeply about them:

• Accessibility
• Performance
• Semantics
• Animation
• UI design
• Analytics
• Testing
• SEO
• Build processes
• Copywriting
• …among many others

Did my buddy and I care about these things back in 2009? Heck no. Well, that’s an exaggeration. Some of those were just as important then as they are today, but we definitely weren’t fretting about page speed, unit testing, or which framework to use. We mocked it up and went for it!

I’m not advocating we go back in time or anything; it’s just proof in the pudding that times have changed and the web will continue to evolve. That means the way we work will continue to change, the nature of work will continue to change, and the job titles that people assign us will continue to change. I understand it’s frustrating, but it’s sorta what we signed up for when we decided to work in the Wild West of the Web.

The blurred distinction between the front end and the back end

Hello, JavaScript. You dun got big in the last 10 years, haven’t you? Been hitting the gym lately?

The way JavaScript has exploded in recent years has had a ripple effect on everyone. And, yes, I mean everyone. It’s been exciting to watch, even if it causes me to question my abilities as a “developer.”

I think it all started with Grunt for me. I was mostly a jQuery jockey in 2013 when I read Chris’s “Grunt for People Who Think Things Like Grunt are Weird and Hard” on 24 Ways. I’m guessing it took me four hours to grok that stuff and come up with a light build process that watched and compiled my Sass. Then I went and bought a CodeKit license.

(I’m kidding. I already had a license and didn’t want to mess with any more command line crap. I seriously don’t mind the command line these days.)

But, build processes! Wow. That was an empowering thing for a front-end developer like me. I felt like I had back-end prowess without the back-end gibberish. That’s how I’m sure folks feel today when spinning up a React app, pushing it over to GitHub, which triggers automated tests on the code, then deploys the code to a Jamstack server that loads the site in a split second.

It’s the era of the all-powerful front-end developer.

What that means is that there is a world where there is no “back” end in the traditional sense. Rather, it’s all front-end code doing front-end-y things on the client side. Geez, even CSS is capable of reading a user’s OS settings so that we can design based on user preferences without any dependencies.

@media (prefers-reduced-motion: reduce) {
  /* Strip out the movement! */
}

So, yes. The front is the back and the back is the front and… some of us aren’t quite sure where we fall on that line. I really love Brad Frost’s recent post, because it nicely articulates this new divide within the divide, as in, we have a back-end, then a front-end that is subsequently segmented between “front-of-the-front-end” and “back-of-the-front-end” to help distinguish the difference between those who “design” the front and those who “build” the front. But the post also makes me giggle because it’s probably a matter of time before one of those gets split again.

What does this have to do with job titles? Well, we’re all sorta front-end developers, but now some of us are more like “front-end engineers” and some are sorta like “design engineers.” Something doesn’t feel right about those titles to me, but I get the sentiment and definitely agree there’s a new distinction that needs to be recognized.

The impossible expectations of employers

Have you read a job description for a front-end developer lately? It’s nuts.

For one thing: it’s front-end developer, not frontend developer. If we’re aiming for consistency and standards, then we oughta at least be on the same page on that.

I’m just gonna pick on some random listing on Indeed.com. Here’s the list of job requirements for a front-end developer in Irvine, CA. Emphasis all mine.

• Have an overall focus on front-end development and a solid understanding of all layers of a web application while being aware of overlapping responsibilities shared with back-end technologies.
• At least 5 years of experience building client side web applications.
• At least 3 years of experience working with React.js and/or Vue.js from start to deployment.
• You must be able to demonstrate expertise in HTML, CSS and Javascript.
• Exceptional level of attention-to-detail and the ability to collaborate with designers and content creators to develop robust and user-friendly interfaces.
• A strong sense of ownership and passion to learn.
• Experience using webpack for bundling and task automation.
• Experience with state management libraries (e.g. Redux, Vuex, MobX)
• Experience optimizing web performance (i.e. network, cpu).
• Understanding of OOP principles and functional programming.
• Familiarity with Sass, BEM and Bootstrap
• Understanding the pros and cons of single page applications and when to leverage them or a hybrid approach
• Experience working with Git version control.
• Experience developing projects across all screen sizes and modern browsers.
• This is a client facing role and you will need to have great communication skills.

Um. OK. I mean, none of these are bad expectations on their own, but collectively, you’re looking at a very specific person and I’m not sure how many people actually fit that mold. I know a lot of great developers, but only a couple might qualify for this, and even that’s iffy. Sounds like this person is responsible for the whole dang application, from the UI design and how it renders, to architecting the build process and deploying the dang thing. That requires heavy JavaScript proficiency, design skills and experience with specific frameworks. And what do we mean by “expertise” in HTML? Is this person A+ with semantics and an expert in accessible interfaces? We haven’t even discussed that this person also has to work directly with clients.

I dunno. That’s a pretty tall order. They’ll get lots of applications, I’m sure, but I’d instantly question just how deeply qualified any of them are, not because they’re poor developers, but because that’s just a lot to ask of someone. There are people who are great at a few of those things. But all of them? I doubt it for the majority of folks.

And thus the full-stack developer. The ultimate unicorn of developers. This title is supposed to encompass all of those things, then probably some more. There are so many issues with the term “full-stack” that I won’t even say it aloud unless I’m gawking at it.

But that’s the expectation of many employers. And many of us work so hard to be “full-stack.” I have no proof of it, but I’d imagine burnout and imposter syndrome are largely rooted in “full-stack” expectations.

It’s a great big world…

So, those are what I think are the driving causes of front-end angst when it comes to job titles. There is no world in which everyone excels at everything. And that’s because the Web itself is a world large enough for people to specialize in specific areas. It’s also big enough for someone like me, who is more of a generalist, or someone with shallow, but wide knowledge of lots of things.

Seriously, folks. The Web (capital W) is big and there’s room for all of us, no matter what code we write. All I can say is you do you and keeping being the best you possible. There’s a place for you and we’re all happy to have you in it with the skills you bring.