Ever since Chris Coyier wrote his now-ubiquitous piece on The Great Divide in front-end web development, I've been struggling with how to describe what I do. Not struggling in terms of what I say when people ask me what my job is; that part is easy! I make websites for a living. If they want to get any more specific, I explain who I work for and what kind of projects I'm currently working on. As I said, that's not the tricky aspect.
No, the hard part is when I'm thinking in terms of job descriptions[1]. What do I write on my LinkedIn bio? What about my portfolio? Which terms do I want to be surfaced under on recruitment platforms or on social media? Suddenly, your job title and respective description feel like the lynchpin on which future career trajectories, personal development opportunities, and industry connectivity all rely. Frankly, it's a lot to think about, even if your job title hasn't become horribly overloaded.
On paper, it seems simple enough. My employment contract boldly and succinctly states that I am a ✨front-end engineer✨. Which is... fine. Within the context of my current job, I fully understand what that means and I'm lucky enough for that internal definition to match my personal career desires and interests. But if I was to walk up to another front-end engineer at a meetup or conference (remember those? 😢) and strike up a conversation[2], there's a very real possibility that we would barely be able to understand one another. So if my job title is as vague as vague can be, where does that leave me?
The Front-Front Temporary Fix
Well, following Chris' original article, Brad Frost ended up coining a slightly tongue-in-cheek term that largely stuck. As a result, I began referring to myself as a front-of-the-front-end developer (or engineer, I've never really understood the difference). I increasingly see the term being bandied around on Twitter, so I'm not alone in this. But let's be honest: that's a terrible way to describe what I do. First of all, as a job title, it's a bit of a chonker 😂 Second, whilst I see it being used by a subset of developers around the social web, it feels like it's become a bit of an "in-group" term. If you introduce yourself to someone that way, one of two things happen (from my experience):
- You get a knowing response along the lines of "Ah, right", which can mean anything from "I know what that means and understand"[3] to "That was jibberish but I don't really care";
- Or, they (quite logically) ask you what on earth you're talking about, at which point you have to explain "Well, there was this blog post about the growing divisions in the front-end web community, and it made an argument about..." whilst their eyes slowly glass over.
Neither reaction feels particularly productive, nor is it much fun for either party. Doubly so if one of those people aren't already a part of the web development community.
Which brings me on to issue number three: if you don't know much about web development, it may as well be Klingon. The term "front-end engineer" is already tricky enough to parse if you're not involved in the tech industry[4], but "front-of-the-front" isn't even English any more.
To be clear, I'm not knocking Brad or Chris here. I think Chris' original article is immensely important and Brad's framing of "back-of-the-front" and "front-of-the-front" is both useful and meaningful. As I said back when The Great Divide was first published:
Chris Coyier recently summed up a lot of these feelings of othering and misunderstandings within the front-end space... Reading it myself, it rang incredibly true.
Not only does that article, and those concepts, do a great job of breaking down this weighty subject, it gave those underlying feelings a central focus and voice that has led to continued discussion and a lot of useful community engagement.
But whilst these were great building blocks, formed from a strong foundation, I don't think they're fit for generalised use moving forward. Nor do I think that's what either author intended. I mean, Chris even spent some time in the article discussing how some companies are already addressing the Divide by splitting the term "front-end developer" into different roles, and you only have to idly glance at the comments to see that this is where a lot of the discussion was focused. As for Brad, he's been kicking around thoughts on other terms for quite some time as well.
What Are The Options?
Okay, then, so what other options are there? Well, I've seen a few suggestions, some just knocking around on places like Twitter, and some actually "in the wild", being used on job specs and in recruitment campaigns. One that keeps coming up is a variation on Design Engineer. Personally, I'm not a fan (update: see below). That might fit some people, but it pretty much excludes me from day one because I'm not a designer. I love working with CSS, I centre everything I do around the user experience, and I'm more than happy to make decisions around elements like typography or spacing, but I'm not a designer. You can give me the best brief in the world and all the time you have to spare for me to fiddle around in tools like Photoshop, Figma, or Adobe XD, but anything I make from scratch is liable to be, well, a bit rubbish[5].
On top of which... we've already danced this dance. When I was getting into the industry, the big hot topic of the moment (alongside this newfangled concept called responsive design, just to date myself a bit) was whether all designers should also be developers. Designers that could code were the unicorn, the 10x full-stack engineer (*shudder*), of their day. Now, I'm not saying that there wasn't some wisdom in having designers that understood the practicalities of browser technologies or accessible technologies. There might be fewer forms using placeholder text as labels today if that were the case... 😏
Yet this was really just the same othering of traditional front-end skills that is at the heart of the Divide, just coming from the opposite direction. It targeted designers – an (obviously) incredibly talented group of professionals with a wealth of subject-matter expertise to bring to the table – and told them that they weren't necessary any more, or that those with certain specialisations were somehow inferior. It was nothing more than gate-keeping and the industry, rightfully, pushed back and ditched it.
Whilst I categorically know that those I've seen bandying around the term "design engineer" aren't advocating for a repeat of any of that history, the cynic in me (bolstered by the version of me that worked in the lion's den of a recruitment company for two years) sees it as an easy backdoor for companies to begin down these lines of reasoning. After all, if they're suddenly going to have to split front-end departments into two specialities, why not do so whilst absorbing another speciality in the process? That's just good business logic, right? (Spoiler: it is not)
Plus, as an industry, people who build websites have a nasty habit of repeating the mistakes of the generation before them. Everything in web development seems to be cyclical. Websites are best rendered in the browser; on the server; in the browser; on the server (and in the browser because double-rendering === whooo!). Flash became Silverlight became (hopefully not, but maybe) Flutter. Development should be done locally on powerful machines; remotely on powerful servers; locally on powerful machines... Do y'see what I mean?
(I'm sure I'm barely scratching the service (and made many of these same mistakes in the past myself, and will do so again in the future 😅))
Other terms that get kicked around include a return to "web developer", which just feels a little too archaic/overloaded in its own right; "front-end designer" which, again, feels a little too design-focused for me; "UX engineer" which I don't hate, but have some misgivings about the association with a storied term like UX and worry about watering down yet another discipline; "frontend developer" (as in, make a hard distinction between "developer" and "engineer") which I like the semantics of but see as an immediate area of elitism (I feel "developer" is already synonymous with "inferior" to many in that world 😫); and, lastly (though not definitively finally), my preferred option: UI Engineer (or developer).
It's In The Name
I actually began referring to myself on LinkedIn as a UI Engineer a little over a year ago. Initially, I wanted to see if there was any discernable difference in the interactions I received. I was working two jobs for the same company, effectively overseeing some of the more front-of-the-front technical elements of a new child company/spin-out they were looking into, so it made sense[6]. After a little while, I began to prefer it.
Most importantly, I feel like UI Engineer is a pretty accurate description of what I do: I make the bits that users interact with. From a technical perspective, that creates a clear umbrella for all the skills I feel are most important and interesting for me:
- A solid understanding of HTML, CSS, SVG, and presentational JavaScript i.e. the building blocks of an interface;
- A clear focus on the user i.e. UX and accessibility;
- An element of (but not emphasis in) design thinking, likely with some scope to bring in concepts like design systems and pattern libraries;
- A specialism around browser technologies and APIs, not build chains or specific tech stacks.
(this list is far from exhaustive; these are just some of the things that immediately spring to mind when I think of what a user interface engineer might need to know)
Of course, right now I'm still a front-end engineer on paper (and, indeed, on LinkedIn). But in my mind, I now frame my decisions around the concept of a UI engineer. If I'm in technical company, that's the term I use to describe what I do. It's certainly a lot faster than saying "front-of-the-frontend" and people seem to get it a lot more easily, even if they've never heard the term before. Heck, even in non-technical circles, it seems to provide better levels of context; most people know what a "user interface" is and can therefore work it out intuitively[7].
Obviously, I'm far from the first person to make this suggestion; I think Google even use this terminology in some teams already. Perhaps others have leant away from it for reasons that I've not yet encountered, but for now, it seems to be the closest fit to describe what I do as a job. And whilst a new, shiny name is far from a bridge over The Great Divide, I think it's at least a step in the right direction and possibly a tentative blueprint for what the future might look like.
Update 21/02/21
It's been less than a week since I posted this article, but in the meantime several other people have independently put their thoughts out into the ether, and I wanted to address them (and add some much-needed titles to the above text blocks 😂).
Whilst I'd seen a few mentions of "design engineer" thrown around in recent weeks, at the time of writing I wasn't consciously aware of anyone using the term directly. Less than 24 hours after I pushed this article live, Trys Mudford published the brilliantly written On Design Engineering: I think I might be a design engineer... in which they lay out a pretty strong case for why they think of themselves as a Design Engineer.
Trys does a fantastic job of explaining their reasoning, outlining what a "design engineer" would look like, and arguing why that term particularly resonates. I think it's safe to say that I don't see myself fitting into the bracket Trys details; not currently, at any rate. But I'm now a lot more amenable to the term than I was a few days earlier. I still have concerns about the title being misused to devalue traditional web designers, but the picture Trys paints of forming a bridge between design and development is a powerful one and I'd be extremely happy to have my fears proven unfounded.
One day later, Jeremy Keith entered the chat with an equally excellent piece simply titled Design Engineer. Trys and Jeremy work together at Clearleft, so it looks like their teams may be moving towards adopting the moniker directly. I mean, Trys has even published a post on the subject (also within the last few days) on the Clearleft blog itself.
I was struck reading through Jeremy's post at how many of the same points we hit upon, whilst arriving at two different conclusions. The added historical insight he provides is particularly useful for me, personally, to frame my thoughts around. It also highlighted that I'd been attributing "front-of-the-front-end" incorrectly! It was actually Brad Frost who coined the term; it never appears in Chris' original article on The Great Divide at all 🤯 (this has also now been fixed above).
At any rate, the arguments that Trys so eloquently made and the added context that Jeremy provides have been incredibly useful for me to reexamine my thoughts written above. I still find myself personally preferring UI Engineer over Design Engineer, but my negative reaction to the latter has now been tempered. What's more, I've found a lot of additional inspiration in how both authors describe their work and where they place value in what they do, which is always beneficial.
Coincidentally, I also found the unfolding of events quite anxiety-inducing, which was interesting, to say the least 😁 If you're interested you can read some more personal thoughts on that matter here. I've also released my bookmarks/notes on both articles here and here (linked mainly for transparency/cross linking).
