Category: Web Dev

Ethan Marcotte: “Through a design system, darkly.”

I appreciated this post by Ethan Marcotte, with his observations on the emergence and usage of design systems:

Users of a design system frequently uncover new needs that weren’t originally anticipated. The result is that there’s now a gap: between the standard and the use. The design system falls out of sync with real-world application. And we’re back dealing with a fancier version of the old problem we used to have: our interfaces are no longer consistent.

This is an incomplete thought, but: the work that goes into making artifacts, deliverables — and, yes, patterns — is where the value lies, more than in the artifact itself. In other words, the process-led approach that Ethan advocates for here could be a way to recognize that the design system is less of a fixed entity, and more of an evolving organism:

Rather than starting with design patterns, we need to looking at the ways our teams currently work, and then identifying how a design system would function within that broader organizational context.

The process-led approach strikes me as descriptivist, the pattern-led approach as prescriptivist. That’s too simplistic, perhaps — you need a bit of both — but identifying those two overlapping approaches would serve all of us well.

Terseness tension

I found myself agreeing with a lot of what Christian Heilmann writes here, especially this part:

Terse code is harder to read. Oh boy, this is holy war material. I’d rather have maintainers get clean code that follows a style than clever, dense hacks. And it shouldn’t be a rite of passage to know all the syntactic magic a language allows. U wl b abl 2 rd ths, as our brain craves harmony and tends to fill in gaps. But it will tire you out much faster than a proper sentence.

One of my former colleagues warned me off this kind of terseness by recounting how he once tried to shorten his function names into acronyms, turning pickFirstItemFromCollection() into something like pfifc(). It was a short-lived experiment.

I’m also reminded of this Twitter thread by Marco Rogers, looking back at the genesis of the arrow syntax in JavaScript, and how that trades readability for terseness:

The javascript community fought hard for the fat arrow syntax, () => {}.

It’s shorter for sure. But way more annoying to type on a regular basis than function() {}.

And that is the folly of programmer culture IMO. Constantly optimizing the wrong things for the wrong reasons.