Don't Call Me a Front-end Developer

During my career as a web developer, I’ve sometimes encountered people that insist on classifying web developers.

“Are you a front-end or a back-end guy?”

To those not in the biz, this sounds like a strange question. Although I’m familiar with these terms, I find myself slightly confused and off-put by this question.

To those not familiar, these terms are designators that split the web development discipline into two distinct groups. “Front-end” developers work with HTML and CSS and write JavaScript–basically the stuff that the browser uses to display and run web pages–to build user interfaces. “Back-end” developers write the code on the server that retrieves and saves data in databases and performs other tasks–everything that makes up the infrastructure needed to serve the web pages.

These designations are harmful for a variety of reasons.


First of all, the distinctions I made above are completely arbitrary. I made the front-end / back-end split based on a client-side (browser) and server-side split. But on company blogs or job postings, I’ve seen organizations make the split where the front-end includes the browser-side stuff as well as the entire web application layer on the server (the Ruby / PHP / Python code) and the back-end in this case goes one level lower, to a C-based (or Java, Scala, Haskell, or some other language depending on the server’s tech stack) layer. Other organizations have designers who work with the HTML and CSS and the developers stick to just writing the code. Because of this hazy line in the sand, one organization’s front-end comprises another’s back-end, and one organization’s front-end is another’s realm of the designer.

So many different layers

Organizations usually make these back/front distinctions to separate teams so that programming work on different application layers can be done concurrently. But concurrency only goes so far, since the work on all layers needs to be complete in order to execute an entire feature on a web app–so dependencies, delays, and performance problems on one layer affect the entire product.


Within some development corners, the implicit prevailing attitude is that back-end developers, by working “closer to the metal,” are “hardcore coders.” They’re working on “hard problems” employing harder-to-use lower-level languages. These hardcore coders scoff at things like usability and user interface design. Front-end developers aren’t solving hard or complex problems; by working with UI and usability designers, front-end developers are CS lightweights more akin to designers than engineers.

I don’t know where or when this misconception came from, but it is just a misconception.

Some of the hardest problems in software are people problems. Finding and implementing better ways to make software interfaces more usable is hard. Working on the first line of defense against the most hostile software environment out there–the web and web browsers–isn’t easy. Most back-end developers aren’t all neck-beards. Back-end developers can have an aesthetic sense and design skills as well as any front-end developer.

Both “divisions” require a ton of skill and expertise; but because there isn’t always a lot of overlap without intentional effort to keep them bridged, these divisions within the discipline can become wide. And so grow the misconceptions and stereotypes.

Comfort Zones

A lot of the back-end / front-end divide has to do with developers’ comfort zones. It’s easier for back-end developers to scoff at front-end developers than it is to learn to use modern JavaScript, improve design skills, and stay up-to-date with new browser APIs and tools. It’s easier for front-end developers to continue writing JavaScript than to move deeper and work with compiled languages.

It’s easier to remain an expert in a smaller domain than to seek out new domains where you become a complete novice again.

I find myself getting defensive when labelled a front-end developer.

While it’s true that I enjoy building user interfaces and some of my greatest areas of expertise and experience lie in HTML, CSS, and JavaScript, I’m not deliberately shying away from hard CS problems. I write just as much server-side code as I write code that runs in the browser. I really don’t mind jumping up and down the stack. I’ve written plenty of C in my day–although I much prefer the happiness that dynamic, higher-level languages now provide me.

I don’t know if the front-end label upsets me because it somehow implies that I’m soft on CS techniques, or if it pigeonholes me into a specific area of development when I consider myself more of a generalist capable of solving a problem in any area of software.

Like most job titles in the tech industry1, adding a descriptor in front is basically an empty affectation. Front-end / back-end is ultimately an arbitrary label that, while implying several things, doesn’t accurately define the many roles and skills of the designee.

I’m a software developer. I build software. Often it’s for the web.

  1. Senior platform architect; Lead solutions consultant; Chief user experience designer; Grand poobah et al.