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.
A proposal for naming every layer in the web development roles cake
Like Jeremy Keith and many others who work in front end development, I’ve taken a liking to Brad Frost’s framing of web dev as being divided into front-of-the-front-end and back-of-the-front-end, which seems like a neat way of acknowledging that with SPAs and component frameworks, big chunks of back end development (state management, authentication, business logic) has moved into the front end.
(You can debate whether that’s a good idea or not for most web services but that point is generally moot. As an industry we no longer know how to do it any other way. Isolated pockets of developer communities have broader skill sets that let them pick and choose an architecture that’s the best for their task. It’s like having a team that’s capable and comfortable with reaching for the Scheme programming language when it’s appropriate for the task. It’s a great capability to have in a team but let’s not pretend that it’s normal or usual. Flexibility and diverse capabilities is not what web development in general is any more.)
What most stumble over is the name: front-of-the-front-end doesn’t exactly roll off the tongue. So, again like Jeremy Keith, I jumped on the term design engineer as a name for my preferred speciality.
(Preferred being the key word here. I’ve had to work on pretty much every layer of web development for extended periods at one time or another.)
It’s about translating design into implementation, usually in close collaboration with the design team.
That still leaves us with awkward names for the other roles in the layer cake that is web development.
Thankfully, in the same way that ‘design engineer’ has been percolating in the background for a few years, we also have ready-made terms for the other layers that are already in use.
A key term comes from Dan Abramov, one of the engineers who works on React, describes his job as being an UI engineer. He sees himself as being responsible for the consistency, reliability, performance, and state in the front end.
You know… back of the front end stuff.
Which leads me to propose the following names for each of these roles in web development.
- Design Engineer: front-of-the-front-end. Translator between design and implementation. Collaborates closely with the design team.
- UI Engineer: back of the front end. Builds the foundation that the design engineer builds on and hooks into. Works on state management, UI performance, tricky foundational implementation details for the front end, and tough abstraction problems.
- Server-side developer: business logic on the server. Nowadays that usually means they’re making an API server but can also be a CRUD server working mainly with HTML.
- Full-stack developer: a developer that does both server-side work and UI engineering work. They work on business logic and abstractions wherever those need to be implemented. Sometimes it’s server-side in, say, a Lambda function. Sometimes it’s client-side in a component delivered via Netlify or similar service.
The paradox of web development over the past decade is that we’ve steadily been losing specialisation, which is usually a sign of collapse. We’ve gone from having CSS specialists to demanding that twenty-year-olds understand every single layer in a complex, thirty year old, tech stack. No wonder they are burning out.
(I’d argue that we have experienced a collapse, just one that looks different from most other collapses. What we’ve seen is the structure of web dev education and recruitment collapse because it can’t come close to meeting the true underlying demand for web developers. IMHO.)
I’m hoping that these conversations people have been having about the various roles in web development is the first step in bringing back specialisation in web dev.
I don’t think the field will be able to thrive without it.