“Effective Organizations Value Autonomy - Jacob Kaplan-Moss”

“TBM 8/52: Avoid Mono-Process (But Embrace Shared Language) - The Beautiful Mess”

“How to Approach a New Codebase - Amber Wilson”

“Against Performative Positivity”

‘Wisdom From the Forums: “The Gap Between Expectations and Reality” - Jim Nielsen’s Blog’

“The Beauty Of Tiny Enhancements In CSS”

“The Online Photographer: The Catastrophic Crash of the Camera Market”

“Material Design Text Fields Are Badly Designed — Smashing Magazine”

I have to use a lot of Google products because of work and over the past few years they’ve gone from having incoherent and unpleasant designs to having coherent and unpleasant designs.

“The mortality of software – Six Colors”

“Opinion - Britney Spears and I Learned the Same Lesson About Fame - The New York Times”

“Introducing State Partitioning - Mozilla Hacks - the Web developer blog”

I would love to see somebody do an in-depth comparison between Mozilla’s and Safari’s approaches to partitioning state.

“technology is not neutral - daniel g. siegel”

Collaborating with robots

“Nothing is real vs everything is real (Interconnected)”

“Machine learning is your collaborator” has been the default for photography for a while now. Even if you don’t use an iPhone most photo processing apps use machine learning somewhere to offer useful features.

It’s only a matter of time until we figure out how to offer useful features based on machine learning in our writing tools.

“The Benefits Of Code Review For The Reviewer - otsukare”

Building a better understanding of the project as a whole and an internal “project theory” is a big reason why I love code reviews. Otherwise it’s too easy to lose track of what’s going on.

‘Hiding Content Responsibly - Hugo “Kitty” Giraudel’

“inkle blog - ink version 1.0 release!”

Ink by Inkle Studios has been on my list of things to try out for ages. Looks like a great tool for interactive storytelling.

“Functional vs. OO: The Debate that Imprecise Language Destroyed – Chelsea Troy”

I love posts like this where the author puts the work in to clarify the language behind a long running debate.

One thing that does unfortunately have to be said: a lot of the people doing the pushback against excessive formalism/minimalism are total dicks. It seems to be a go-to opinion for a lot of angry designer assholes, for example.

“Please don’t make me choose a username”

“After Minimalism - David Perell”

“The problem with minimalism is that it’s boring.”

More pushback against the excesses of modern formalism

I’m not the only one who finds app design formalism to be boring

“No More Boring Apps - ANDY.WORKS”

“Despite being perhaps the largest professional creative field today, Product Design seems to be missing something fundamental that exists in every other design field.”

There are three explanations for the design wasteland that is modern app design. All three are probably true at the same time.

  1. Apple, Google, et al. had a solid go at commodifying apps and UX design.
  2. The education, training, and recruitment processes in UX design collapsed under excessive demand the same way that front end dev training collapsed.
  3. This particular swing of the formalist-romanticist pendulum swung particularly hard in the formalist direction this time around.

For those of you who didn’t study art or literary history: design and the creative arts in the west have tended to cycle between formalist movements, where perfection can be found in pure structure, and romanticist movements that maintain that meaning and utility largely resides in society outside of the work. Most other cultures tend not to have these cycles and instead have multiple concurrent cultural traditions going on at the same time. Which is where we’re heading, in general, because of globalisation, but it’ll take a while for the West’s nonsense to peter out, as usual.

We’ve gone through these cycles a dozen times in drama, design, art, and literature. We’ve been going through a formalist reaction to the romanticist postmodern movements that defined the 80s and 90s. If you were wondering why movies in the twenty teens all had a similar structure, whereas those in the 90s and 2000-2010 had more formulas going around and most of them hinged around an obsession with cinematic intertextuality, it isn’t just because everybody first loved Quentin Tarantino and then hated him. It wasn’t just a question of money although money tends to favour formalism/modernism as it tends to commodify the field.

UI design has just gone through a similar cycle and we’re now starting to see a push for it to cycle back into letting designers be more playful.


What I’ve found interesting about the current formalist iteration is that they’ve formalised the media property cultural reference. It isn’t a coincidence that Disney’s Marvel movies didn’t reference the Fox X-Men movies, even obliquely, until they owned fox.

To put it more plainly: Deadpool is a postmodernist movie and in many ways a stylistic throwback to earlier trends. If you wanted to be unkind you’d call it a (cultural) living fossil. Almost every other big studio movie these days are ultra-modernistic exercises in formula and structure.

End Aside

The Layers of Development: Design Engineer, UI Engineer, Full Stack Developer, Server-Side Developer

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.

“Adactio: Journal—Design engineer”

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.

“Unfortunate things about performance reviews”

“If you take nothing else away from this post, take this: a sufficiently skilled manager can take the same body of work and make it work for you OR against you.”

“Ursula K. Le Guin’s translation of the Tao Te Ching - Austin Kleon”

This book is one of the most personally important books in my collection. I read it regularly.

“On Design Engineering: I think I might be a design engineer… - Trys Mudford”