I know how to do full-stack development, not because I wanted to but because I had to.
Grim, but true. I know quite a few extremely talented front-end developers who have been forced out of the field because of what’s described here.
There is no choice anymore, I can’t escape it. React is so pervasive that almost every job is using it. On the rare occasion that they’re not using it, they’re using something like it.
It’s like CSS exists in some bizarre quantum state; somehow both too complex to use, yet too simple to take seriously, all at once.
In many ways, CSS has greater impact than any other language on a user’s experience, which often directly influences success. Why, then, is its role so belittled?
Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room.
Vasilis gives the gist of his excellent talk at the border:none event that just wrapped up in Nuremberg. The rant at the end chimed very much with my feelings on this topic:
I showed a little interaction experiment that one of my students made, with incredible attention to detail. Absolutely brilliant in so many ways. You would expect that all design agencies would be fighting to get someone like that into their design team. But to my amazement she now works as a react native developer.
I have more of these very talented, very creative designers who know how to code, who really understand how the web works, who can actually design things for the web, with the web as a medium, who understand the invisible details, who know about the UX of HTML, who know what’s possible with modern HTML and CSS. Yet when they start working they have to choose: you either join our design team and are forced to use a tool that doesn’t get it, or you join the development team and are forced to use a ridiculous framework and make crap.
This resonates a lot:
At some point, we told design they couldn’t sit with us anymore, and surprise! It backfired! Now, not only has the field and profession of web design suffered, but also, we build shitty websites.
I’ve seen talented people—mostly women—pushed out of making websites because their skills—mostly CSS—weren’t valued as much being a React plumber.
It fucking sucks.
This anthology of Steve Jobs interviews, announcements and emails is available to read for free as a nicely typeset web book.
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.
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.
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