We need engineers, we need designers, and we absolutely need design engineers to make that connection across the great divide between the front-of-the-front-end and the back-of-the-front-end. It’s only then that we can make truly great things together.
Tuesday, February 23rd, 2021
Friday, February 19th, 2021
It’s been just over two years since Chris wrote his magnum opus about The Great Divide. It really resonated with me, and a lot of other people.
The crux of it is that the phrase “front-end development” has become so broad and applies to so many things, that it has effectively lost its usefulness:
Two front-end developers are sitting at a bar. They have nothing to talk about.
Brad nailed the differences in responsibilities when he described them as front-of-the-front-end and back-of-the-front-end web development:
In my experience, the term “full stack developer” is often self-applied by back-of-the-front-end developers who perhaps underestimate the complexity of front-of-the-front development.
Me, I’m very much a front-of-the-front developer. And the dev work we do at Clearleft very much falls into that realm.
This division of roles and responsibilities reminds me of a decision we made in the founding days of Clearleft. Would we attempt to be a full-service agency, delivering everything from design to launch? Or would we specialise? We decided to specialise, doubling down on UX design, which was at the time an under-served area. But we still decided to do front-end development. We felt that working with the materials of the web would allow us to deliver better UX.
We made a conscious decision not to do back-end development. Partly it was a question of scale. If you were a back-end shop, you probably had to double down on one stack: PHP or Ruby or Python. We didn’t want to have to turn away any clients based on their tech stack. Of course this meant that we had to partner with other agencies that specialised in those stacks, and that’s what we did—we had trusted partners for Drupal development, Rails development, Wordpress development, and so on.
Overall, our decision to avoid back-end development stood us in good stead. There were plenty of challenges though. We had to learn how to avoid “throwing stuff over the wall” at whoever would be doing the final back-end implementation. I think that’s why we latched on to design systems so early. It was clearly a better deliverable for the people building the final site—much better than mock-ups or pages.
Avoiding back-end development meant we also avoided long-term lock-in with maintainence, security, hosting, and so on. It might sound strange for an agency to actively avoid long-term revenue streams, but at Clearleft it’s always been our philosophy to make ourselves redundant. We want to give our clients everything they need—both in terms of deliverables and knowledge—so that they aren’t dependent on us.
That all worked great as long as there was a clear distinction between front-end development and back-end development. Front-end development was anything that happened in a browser. Back-end development was anything that happened on the server.
That’s why Brad’s framing resonated with me. Clearleft does front-of-front-end development, but we liaise with our clients’ back-of-the-front-end developers. In fact, that bridging work—between design and implementation—is where devs at Clearleft shine.
As much as I can relate to the term front-of-front-end, it doesn’t exactly roll off the tongue. I don’t expect it to be anyone’s job title anytime soon.
That’s why I was so excited by the term “design engineer,” which I think I first heard from Natalya Shelburne. There’s even a book about it and the job description sounds very much like the front-of-the-front-end work but with a heavy emphasis on the collaboration and translation between design and implementation. As Trys puts it:
What I love about the name “Design Engineer”, is that it’s entirely focused on the handshake between those two other roles.
There’s no mention of UI, CSS, front-end, design systems, documentation, prototyping, tooling or any ‘hard’ skills that could be used in the role itself.
Trys has been doing some soul-searching and has come to the conclusion “I think I might be a design engineer…”. He has also written on the Clearleft blog about how well the term describes design and development at Clearleft.
Personally, I’m not a fan of using the term “engineer” to refer to anyone who isn’t actually a qualified engineer—I explain why in my talk Building—but I accept that that particular ship has sailed. And the term “design developer” just sounds odd. So I’m all in using the term “design engineer”.
I can imagine this phrase being used in a job ad. It could also be attached to levels: a junior design engineer, a mid-level design engineer, a senior design engineer; each level having different mixes of code and collaboration (maybe a head of design enginering never writes any code).
Trys has written a whole series of posts on the nitty-gritty work involved in design engineering. I highly recommend reading all of them:
Tuesday, May 21st, 2019
I’m not trying to convince anyone they aren’t a full-stack developer or don’t deserve that particular merit badge — just that the web is a big place with divergent needs and ever-morphing stacks that all require different sets of skills.
Friday, April 5th, 2019
This article by Ian Bogost from a few years back touches on one of the themes in the talk I gave at New Adventures:
“Engineer” conjures the image of the hard-hat-topped designer-builder, carefully crafting tomorrow. But such an aspiration is rarely realized by computing. The respectability of engineering, a feature built over many decades of closely controlled, education- and apprenticeship-oriented certification, becomes reinterpreted as a fast-and-loose commitment to craftwork as business.
Tuesday, March 5th, 2019
How to Think Like a Front-End Developer by Chris Coyier
Alright! It’s day two of An Event Apart in Seattle. The first speaker of the day is Chris Coyier. His talk is called How to Think Like a Front-End Developer. From the website:
The job title “front-end developer” is very real: job boards around the world confirm that. But what is that job, exactly? What do you need to know to do it? You might think those answers are pretty cut and dried, but they’re anything but; front-end development is going through something of an identity crisis. In this engaging talk, Chris will explore this identity through the lens of someone who has self-identified as a front-end developer for a few decades, but more interestingly, through many conversations he’s had with other successful front-end developers. You’ll see just how differently this job can be done and how differently people and companies can think of this role—not just for the sake of doing so, but because you’ll learn to be better at your own jobs by understanding how other people are good at theirs.
I’m going to see if I can keep up with Chris’s frenetic pace…
Chris has his own thoughts about what front-end dev is but he wants to share other ideas too. First of all, some grammar:
I work as a front-end developer.
I work on the front end.
Those are correct. These are not:
I work as a front end developer.
I work on the front-end.
And this is just not a word:
Lots of people are hiring front-end developers. So it’s definitely a job and a common job title. But what does it mean. Chris and Dave talked to eight different people on their Shop Talk Show podcast. Some highlights:
Eric feels that the term “front-end developer” is newer than the CSS Zen Garden. Everyone was a webmaster, or as we’d say now, a full-stack developer. But if someone back then used the term “front-end developer”, he’d know what it meant.
Mina says it deals with things you can see. If it’s a user-facing interface, that’s front-end development.
Trent says that he thinks of himself as a web designer and web builder. He doesn’t feel he has the deep expertise of a developer, and yet he spends all of his time in the browser.
So our job is in the browser. You deal with the browser (moreso than other roles). And by the way, there are a lot of browsers out there.
Maybe the user is what differentiates front-end work. Monica says that a back-end developer is allowed not to care about the user if their job is putting a database together. It’s totally fine not to call yourself a front-end developer, but if you do, you need to care about the user.
There are tons of different devices and browsers. It’s overwhelming. So we just gave up.
So, a front-end developer:
- Is a job and a job title.
- It deals with browsers, devices, and users.
- But what skills does it involve?
It’s taken for granted that you can use a computer. There’s also the soft skills of interacting with co-workers. Then there are the language-specific core skills. Finally, there are the bonus skills—all the stuff that makes you you.
The languages you need to strongly understand to read, write and maintain them.
Peggy believes that as a front-end developer you need to have a basic proficiency in accessibility too. This is, after all, about user-facing interfaces.
The Figma team have a somewhat over-engineered graphic of all the skillsets that people might have, between “baseline” and “supplementary”.
Perhaps we all share a common trunk of skills, and then we branch in different directions.
You could imagine two people called front-end developers meeting, and having nothing in common to talk about. Maybe sports.
Brad says he doesn’t want to be configuring build tools. He thinks of himself as being at the front of front-end development, whereas other people are at the back of front-end development.
This divide is super frustrating to people right now.
Let’s look at CodePen. There’s a little heart icon on each pen. It’s an icon component. And the combination of the heart and the overall count is also a component. And the bar of items altogether—that’s also a component. And the pen it sits under is a component. And the page it’s in is a component. And the URL for that page is a component. Now the whole site is a front-end developer’s concern.
In the past, a front-end developer would ask a back-end developer for an API endpoint. Now with GraphQL, the front-end developer can craft a query to get exactly what they need. Sure, the GraphQL stuff had to be set up in the first place, but that’s one-time task. Once it’s set up, the front-end developer has everything they need.
All the old work hasn’t gone away either. Semantics, accessibility, styling—that’s still the work of a front-end developer as well as all of the new stuff listed above.
Hiring is a big part of this. Lara Schenk talks about going for an interview where she met 90% of the skills listed. Then in an interview, she was asked to do a fizzbuzz test. That’s not the way that Lara thinks. She would’ve been great for that job, but this single task derailed her. She wrote about it, and got snarky comments from people who thought she should’ve been able to do the task. But Lara’s main point was the mismatch between what was advertised and what was actually being hired for.
You see a job posting for front-end developer. Who is that for? Is it for someone into React, webpack, and GraphQL? Or is it for someone into SVG, interaction design, and accessibility? They’re both front-end developers. And remember, they can learn one another’s skills, but when it comes to hiring, it has to be about the skills people have right now.
Peggy talks about how specialised your work can be. You can specialise in SVG. You can specialise in APIs and data.
We’re probably not going to solve this right now. The hiring part is definitely the worst part right now. One solution is to use plain language in job posts. Make it clear what you’re looking for right now and explain what background you’re coming from. Use words instead of a laundry list of requirements.
Heydon Pickering talks about full-stack developers. Their core skills are hardcore computer science skills.
Brad Frost concurs. It tends not to be the other way around. The output tends to be the badly-sketched front of the horse.
Even if there is a divide, that doesn’t absolve any of us from doing a good job. That’s true whether it’s computer science tasks or markup and CSS.
Despite the divide, performance, accessibility, and user experience are all our jobs.
Maybe this term “front-end developer” needs rethinking.
The brain game
Let’s peak into the minds of very different front-end developers. Chris and Dave went to Dribbble, pulled up a bunch of designs and put them in front of their guests on the Shop Talk Show.
Here’s a design of a page.
- Brad looks at the design and sees a lot of components of different sizes and complexity.
- Mina sees a bunch of media objects.
- Eric sees HTML structures. That’s a heading. That’s a list. Over there is an unordered list.
- Sam sees a lot of typography. She sees a type system.
- Trent immediately starts thinking about how the design is supposed to work in different screen sizes.
Here’s a different, more image-heavy design.
- Mina would love to tackle the animations.
- Trent sees interesting textures and noise. He wonders how he could achieve those effects without exporting giant image files.
- Brad, unsurprisingly, sees components, even in a seemingly bespoke layout.
- Eric immediately sees a lot of SVG.
- Sam needs to know what the HTML is.
Here’s a more geometric design.
- Sam is drawn to the typography.
- Mina sees an opportunity to use writing modes.
- Trent sees a design that would reflow and reshape itself well.
- Eric sees something with writing mode, grid, and custom fonts.
Here’s a financial mobile UI.
- Trent wants to run it through a colour-contrast analyser, and he wants to know if the font size is too small.
Here’s a crazy festival website.
- Mina wonders if it needs a background video, but worries about the performance.
Here’s an on-trend mobile design.
- Monica sees something that looks like every other website.
- Ben wonders whether it will work in other parts of the world. How will the interactions work? Separate pages or transitions? How will it feel?
Here’s an image-heavy design.
- Monica wonders about the priority of which images to load first.
Here’s an extreme navigation with big images.
- Ben worries about the performance on slow connections.
- Monica gets stressed out about how much happens when you just click on a link.
- Peggy sees something static and imagines using Gatsby for it.
Here’s a design that’s map-based.
- Ben worries about the size of the touch targets.
- Monica sees an opportunity to use SVGs.
Here’s a card UI.
- Ben wonders what the browser support is. Can we use CSS grid or do we have to use something older?
- Monica worries that this needs drag’n’drop. Now you’ve got a nightmare scenario.
Chris has been thinking about and writing about this topic of what makes someone a front-end developer, and what makes someone a good front-end developer. The debate will continue…
Tuesday, January 22nd, 2019
Something that I am increasingly uncomfortable with is our industry’s obsession with job titles. I understand that the landscape has gotten a lot more complex than when I started out in 2009, but I do think the sheer volume and variation in titles isn’t overly helpful in communicating what people actually do.
I share Andy’s concern. I kinda wish that the title for this open job role at Clearleft could’ve just said “Person”.
An excellent thorough analysis by Chris of the growing divide between front-end developers and …er, other front-end developers?
The divide is between people who self-identify as a (or have the job title of) front-end developer, yet have divergent skill sets.
On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.
Saturday, June 23rd, 2018
A good ol’ rant from Robin.
Before jumping to conclusions, read the whole thing. Robin isn’t having a go at people who consider themselves full-stack developers; he’s having a go at the people who are only hiring back-end developers and expecting them to automatically be “full stack.”
Thursday, December 7th, 2017
I like this distinction between coders and developers.
The Coder is characterized by his proficiency in a narrow range of chosen skills.
By contrast the Developer’s single greatest skill is in being an applied learner.
I’m definitely not a coder. Alas, by this criterion, I’m also not a developer (because I do not pick things up fast):
Quite simply the Developer has a knack for grokking new [languages|frameworks|platforms] and becoming proficient very quickly.
I prefer Charlie’s framing. It’s not about speed, it’s about priorities:
I’m not a “developer” in that I’m obsessed with code and frameworks. I’m a “developer” as in I develop the users experience for the better.
Thursday, September 14th, 2017
In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.
Tuesday, June 6th, 2017
Sometimes our job titles and distinctions feel like the plastic grass in a sushi bento; flimsy and only there for decoration.
Wednesday, July 27th, 2016
Thursday, July 14th, 2016
This is relevant to my interests because I think I’m supposed to be a senior developer. Or maybe a technical director. I’m really not sure (job titles suck).
Anyway, I very much appreciate the idea that a technical leadership position isn’t just about technical skills, but also communication and connectedness.
When we boiled down what we’re looking for, we came away with 12 traits that divide pretty cleanly along those three areas of responsibility: technical capability, leadership, and community.
For someone like me with fairly mediocre technical capability, this is reassuring.
Now if I only I weren’t also mediocre in those other areas too…
Tuesday, December 15th, 2015
Shadows and smoke
Hiring Charlotte was an experiment for Clearleft—could we hire someone in a “junior” position, and then devote enough time and resources to bring them up to a “senior” level? (those quotes are air quotes—I find the practice of labelling people or positions “junior” or “senior” to be laughably reductionist; you might as well try to divide the entire web into “apps” and “sites”).
It breaks my heart to see so many of my colleagues prefix their job titles “senior” (not least because it becomes completely meaningless when every single Visual Designer is also a “Senior Visual Designer”).
I remember being at a conference after-party a few years ago chatting to a very talented front-end developer. She wasn’t happy with where she was working. I advised to get a job somewhere else After all, she lived and worked in San Francisco, where her talents are in high demand. But she was hesitant.
“They’ve promised me that in a few more months, my job title would become ‘Senior Developer’”, she said. “Ah, right,” I said, “and what happens then?” “Well”, she said, “I get to have the word ‘senior’ on my resumé.” That was it. No pay rise. No change in responsibilities. Just a word on a piece of paper.
I had always been suspicious of job titles, but that exchange put me over the edge. Job titles can be downright harmful.
Dan recently wrote about the importance of job titles. I love Dan, but I couldn’t disagree with him more in this instance.
He cite two situations where he believes job titles have value:
Your title tells your colleagues how to interact with you.
No. Talking to your colleagues tells your colleagues how to interact you. Job titles attempt to short-cut that. They do a terrible job of it.
What you need to know are the verbs that your colleagues are adept in: designing, developing, thinking, communicating, facilitating …all of that gets squashed down into one reductionist noun like “Copywriter” or “Designer”.
At Clearleft, we’ve recently started kicking off projects with an exercise called “Fuzzy Edges” that Boxman has been refining. In it, we look ahead to all the upcoming project roles (e.g. “Who will lead playbacks and demos?”, “Who will run stakeholder interviews?”, “Who will lead design direction?”). Together, everyone on the project comes to a consensus on who has which roles.
It’s really, really important to clarify these roles at the start of each project, and it’s exactly the kind of thing that can’t be summed up in a job title. In fact, the existence of job titles can lead to harmful assumptions like “Oh, I figured you were leading playbacks and demos!” or “Oh, I assumed they were running stakeholder interviews!”, or worse: “Hey, you can’t lead design direction because that’s not in your job title!”
The role assignments can vary hugely from project to project, which is great. People are varied and multi-faceted. Trying to force the same people into the same roles over and over again would be demoralising and counter-productive. I fear that’s exactly what job titles do—they reinforce barriers.
Here’s the second reason Dan gives for the value of job titles:
Your title tells your clients how to interact with you.
Again, no. Talking to your clients tells your clients how to interact with you.
Dan illustrates his point by recounting a tale of deception, demonstrating that a well-placed lie about someone’s job title can mollify the kind of people who place great stock in job titles. That’s not solving the real problem. Again, while job titles might appear to be shortcuts to a shared understanding, they’re actually more like façades covering up trapdoors.
In recounting the perceived value of job titles, there’s an assumption that the titles were arrived at fairly. If someone’s job title is “Senior Designer” and someone’s job title is “Junior Designer”, then the senior person must be the better, more experienced designer, right?
But that isn’t always the case. And that’s when job titles go from being silly pointless phrases to being downright damaging, causing real harm.
Over on Rands in Repose, there’s a great post called Titles are Toxic. His experience mirrors mine:
Never in my life have I ever stared at a fancy title and immediately understood the person’s value. It took time. I spent time with those people — we debated, we discussed, we disagreed — and only then did I decide: “This guy… he really knows his stuff. I have much to learn.” In Toxic Title Douchebag World, titles are designed to document the value of an individual sans proof. They are designed to create an unnecessary social hierarchy based on ego.
See? There’s no shortcut for talking to people. Job titles are an attempt to cut out one of the most important aspects of humans working together.
The unspoken agreement was that these titles were necessary to map to a dimwitted external reality where someone would look at a business card and apply an immediate judgement on ability based on title. It’s absurd when you think about it – the fact that I’d hand you a business card that read “VP” and you’d leap to the immediate assumption: “Since his title is VP, he must be important. I should be talking to him”. I understand this is how a lot of the world works, but it’s precisely this type of reasoning that makes titles toxic.
So it’s not even that I think that job titles are bad at what they’re trying to do …I think that what they’re trying to do is bad.
Monday, September 28th, 2015
I completely agree with Cennydd (and Peter, and Leisa). If anyone working on a project—whether they’re a designer, developer, or anything else—isn’t considering the user experience, then what’s the point of even being there? By extension, labelling your work as “UX Design” is as redundant and pointless as labelling it “Good Design.”
But my complaint is with the label, not the activities. It’s the UX Design label that has little value for me. These activities happen in all good design: if you’re not trying to create positive experience then I don’t really understand what you are doing.
Thursday, July 3rd, 2014
I can very much relate to what Dan is talking about here. I have no idea what I do any more.
No doubt we’ll always feel we’re behind the curve as there always seems like more to learn. That’s OK. No-one knows it all, but it is hard knowing what people expect of you.
Tuesday, March 19th, 2013
Yes, yes, yes!
In Toxic Title Douchebag World, titles are designed to document the value of an individual sans proof. They are designed to create an unnecessary social hierarchy based on ego.
Wednesday, February 6th, 2013
The truth …it burns!
Wednesday, January 23rd, 2013