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.
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.
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.
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.
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.
Senior platform architect; Lead solutions consultant; Chief user experience designer; Grand poobah et al.↩