Dave laments the increasing number of complex jobs involved in front-end (or “full-stack”) development.
But whereas I would just leave at that, Dave does something constructive and points to a potential solution—a corresponding increase of more thinsliced full-time roles like design engineering, front-end ops, and CSS engineering.
Are you a web dev that’s into progressive enhancement, accessibility, design systems, and all that good stuff?
You should come and work with me at Clearleft.
Yes, I’m a sucker for pace layers, but I think Rich is onto something here, mapping a profession onto a pace layer diagram.
We’re halfway through the third season of the Clearleft podcast already!
Episode three is all about design research. I like the narrative structure of this. It’s a bit like a whodunnit, but it’s more like a whydunnit. The “why” question is “why aren’t companies hiring more researchers?”
The scene of the crime is this year’s UX Fest, where talks by both Teresa Torres and Gregg Bernstein uncovered the shocking lack of researchers. From there, I take up the investigation with Maite Otondo and Stephanie Troeth.
I won’t spoil it but by the end there’s an answer to the mystery.
I learned a lot along the way too. I realised how many axes of research there are. There’s qualitative research (stories, emotion, and context) and then there’s quantitative research (volume and data). But there’s also evualative research (testing a hyphothesis) and generative research (exploring a problem space before creating a solution). By my count that gives four possible combos: qualitative evaluative research, quantitative evaluative research, qualitative generative research, and quantitative generative research. Phew!
Steph was a terrific guest. Only a fraction of our conversation made it into the episode, but we chatted for ages.
And Maite kind of blew my mind too, especially when she was talking about the relationship between research and design and she said:
Research is about the present and design is about the future.
🤯
I’m going to use that quote again in a future episode. In fact, this episode on design research leads directly into the next two episodes. You won’t want to miss them. So if you’re not already subscribed to the Clearleft podcast, you should get on that, whether it’s via the RSS feed, Apple, Google, Spotify, Overcast, or wherever you get your podcasts from.
Have a listen to this episode on design research and if you’re a researcher yourself, remember that unlike most companies we value research at Clearleft and that’s why we’re hiring another researcher right now. Come and work with us!
If you’re subscribed to the Clearleft podcast, then the latest episode is winging its way through the ether to your podcast software. The topic is one close to my heart: design engineering.
I wrote about this role back in February. I think my fervour comes across in that post and you can probably hear it in the podcast episode too.
As ever, I end up asking the question, “So what exactly is insert topic of the podcast episode here?”
I’ve got some smart folks answering that question. There’s an excerpt from Tobias Ahlin’s talk at this year’s UX Fest. And when I interviewed Adekunle Oduye for a previous episode on prototyping, we also discussed design engineering so I pulled out the relevant bits. But the bulk of the episode features the voice of Trys Mudford.
As you can gather from the many posts on Trys’s blog, he has a lot to say on the topic of design engineering. Luckily for me, he says it all with a clear, articulate delivery—the perfect podcast guest!
This episode finishes with a call to action (oh, the synergy!). If, after listening to 23 minutes of discussion on design engineering, you find yourself thinking “Hey, I think I might be a design engineer!”, then you should definitely head along to this job opening at Clearleft:
We’re currently looking for a design-friendly front-end developer with demonstrable skills in pattern-based prototyping and production.
Have a listen to episode two of season three of the Clearleft podcast and if you like what you hear, come and join us!
Keep refreshing until you find your next job title.
A little while back, I wrote about how much I like the job description of a design engineer. I still have issues with the “engineer” part, but overall it’s a great way to describe a front-end developer who works on the front of the front end: the outputs that end users interact with: HTML, CSS, and JavaScript. If it’s delivered in a web browser, then it’s design engineering.
Perhaps you also prefer the front of the front end to the back of the front end. Perhaps you also like to spend your time thinking about resilience, performance, and accessibility rather than build pipelines and frameworks. Perhaps you’d like to work with like-minded people.
Clearleft is hiring a midweight design engineer. Perhaps it’s you.
If you’d like to use your development talents in the service of good design, you should apply. And remember, you’d be working for yourself: Clearleft is an employee-owned agency.
You don’t have to be based in Brighton. You can work remotely, although we’re expecting that a monthly face-to-face gathering will become the norm after The Situation ends. So if you’re based somewhere like London, that would work out nicely. That said, if you’re based somewhere like London, this might also be the ideal opportunity to make a move to the seaside.
You do have to be eligible to work in the UK. Alas, that pool has shrunk somewhat. Thanks, Brexit.
Perhaps you think you’re not qualified. Apply anyway. You’ve got nothing to lose.
Perhaps this role isn’t for you, but you know someone who might fit the bill. Please tell them. Spread the word.
We’d especially love to hear from people under-represented in design and technology.
Want to work with me? If so, come and be a design engineer at Clearleft!
What’s a design engineer? A front-end developer at the front of the front end who values accessibility, performance, and progressive enhancement.
We’re looking for a design-friendly front-end developer with demonstrable skills in pattern-based prototyping and production to join our friendly and supportive team in the heart of Brighton.
Even if this isn’t for you, please spread the word …especially to potential candidates who aren’t mediocre middle-aged white dudes (I’ve already got that demographic covered).
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.
Here’s a seven-year old post by Snook—this design engineer thing is not new.
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:
A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.
A back-of-the-front-end developer is a web developer who specializes in writing JavaScript code necessary to make a web application function properly.
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.
The world of front-end development didn’t have that kind of fragmentation. The only real split at the time was between Flash agencies and web standards (HTML, CSS, and JavaScript).
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.
But as the waters muddied and complex business logic migrated from the server to the client, our offering became harder to clarify. We’d tell clients that we did front-end development (meaning we’d supply them with components formed of HTML, CSS, and JavaScript) and they might expect us to write application logic in React.
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:
These definitions work for me:
A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.
A back-of-the-front-end developer is a web developer who specializes in writing JavaScript code necessary to make a web application function properly.
Chris shares his thoughts on the ever-widening skillset required of a so-called front-end developer.
Interestingly, the skillset he mentions half way through (which is what front-end devs used to need to know) really appeals to me: accessibility, performance, responsiveness, progressive enhancement. But the list that covers modern front-end dev sounds more like a different mindset entirely: APIs, Content Management Systems, business logic …the back of the front end.
And Chris doesn’t even touch on the build processes that front-end devs are expected to be familiar with: version control, build pipelines, package management, and all that crap.
I wish we could return to this:
The bigger picture is that as long as the job is building websites, front-enders are focused on the browser.
This is a really good description of the role of a front-end developer.
That’s front end, not full stack.
Playing Tie The Bonnet (reel) on mandolin:
May 1st was my last day as a VP and Distinguished Engineer at Amazon Web Services, after five years and five months of rewarding fun. I quit in dismay at Amazon firing whistleblowers who were making noise about warehouse employees frightened of Covid-19.
Fair play, Tim Bray!
The victims weren’t abstract entities but real people; here are some of their names: Courtney Bowden, Gerald Bryson, Maren Costa, Emily Cunningham, Bashir Mohammed, and Chris Smalls.
I’m sure it’s a coincidence that every one of them is a person of color, a woman, or both. Right?
Here, then, is my speculation. Work is something we struggle to get and strive to keep. We love-hate it (usually not in equal measure). Sometimes it seems meaningless. I’m told this is the case even for surgeons, teachers and disaster-relief workers: those with jobs whose worth seems indisputable. For the mere facilitators, the obscure cogs in the machinery of the modern economy whose precise function and value it takes some effort to ascertain, the meaning in what we do often seems particularly elusive (I should know). I contend, however, that while our lives need to be meaningful, our work does not; it only has to be honest and useful. And if someone is voluntarily paying you to do something, it’s probably useful at least to them.
Chris broke both his arms just to avoid speaking at the JAMstack conference in London. Seems a bit extreme to me.
Anyway, to make up for not being there, he made a website of his talk. It’s good stuff, tackling the split.
It’s cool to see the tech around our job evolve to the point that we can reach our arms around the whole thing. It’s worthy of some concern when we feel like complication of web technology feels like it’s raising the barrier to entry
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.
I have a bittersweet feeling today. Danielle is moving on from Clearleft.
I used to get really down when people left. Over time I’ve learned not to take it as such a bad thing. I mean, of course it’s sad when someone moves on, but for them, it’s exciting. And I should be sharing in that excitement, not putting a damper on it.
Besides, people tend to stay at Clearleft for years and years—in the tech world, that’s unheard of. So it’s not really so terrible when they decide to head out to pastures new. They’ll always be Clearlefties. Just look at the lovely parting words from Harry, Paul, Ellen, and Ben:
Working at Clearleft was one of the best decisions I ever made. 6 years of some work that I’m most proud of, amongst some of the finest thinkers I’ve ever met.
(Side note: I’ve been thinking about starting a podcast where I chat to ex-Clearlefties. We could reflect on the past, look to the future, and generally just have a catch-up. Would that be self indulgent or interesting? Let me know what you think.)
So of course I’m going to miss working with Danielle, but as with other former ‘lefties, I’m genuinely excited to see what happens next for her. Clearleft has had an excellent three years of her time and now it’s another company’s turn.
In the spirit of “one door closes, another opens,” Danielle’s departure creates an opportunity for someone else. Fancy working at Clearleft? Well, we’re looking for a head of front-end development.
Do you remember back at the start of the year when we were hiring a front-end developer, and I wrote about writing job postings?
My first instinct was to look at other job ads and take my cue from them. But, let’s face it, most job ads are badly written, and prone to turning into laundry lists. So I decided to just write like I normally would. You know, like a human.
That worked out really well. We ended up hiring the ridiculously talented Trys Mudford. Success!
So I’ve taken the same approach with this job ad. I’ve tried to paint as clear and honest a picture as I can of what this role would entail. Like it says, there are three main parts to the job:
Now, I could easily imagine someone reading the job description and thinking, “Nope! Not for me.” Let’s face it: There Will Be Meetings. And a whole lotta context switching:
Within the course of one day, you might go from thinking about thorny code problems to helping someone on your team with their career plans to figuring out how to land new business in a previously uncharted area of technology.
I can equally imagine someone reading that and thinking “Yes! This is what I’ve been waiting for.”
Oh, and in case you’re wondering why I’m not taking this role …well, in the short term, I will for a while, but I’d consider myself qualified for maybe one third to one half of the required tasks. Yes, I can handle the professional development side of things (in fact, I really, really enjoy that). I can handle some of the technical leadership stuff—if we’re talking about HTML, CSS, JavaScript, accessibility, and performance. But all of the back-of-the-front-end stuff—build tools, libraries, toolchains—is beyond me. And I think I’d be rubbish at the business support stuff, mostly because that doesn’t excite me much. But maybe it excites you! If so, you should apply.
I can picture a few scenarios where this role could be the ideal career move…
Suppose you’re a lead developer at a product company. You enjoy leading a team of devs, and you like setting the technical direction when it comes to the tools and techniques being used. But maybe you’re frustrated by always working on the same product with the same tech stack. The agency world, where every project is different, might be exactly what you’re looking for.
Or maybe you’re an accomplished and experienced front-end developer, freelancing and contracting for years. Perhaps you’re less enamoured with being so hands-on with the code all the time. Maybe you’ve realised that what you really enjoy is solving problems and evaluating techologies, and you’d be absolutely fine with having someone else take care of the implementation. Moving into a lead role like this might be the perfect way to make the best use of your time and have more impact with your decisions.
You get the idea. If any of this is sounding intriguing to you, you should definitely apply for the role. What do you have to lose?
Also, as it says in the job ad:
If you’re from a group that is under-represented in tech, please don’t hesitate to get in touch.