An opinionated blog about writing. I’ve subscribed in my feed reader.
The video of a talk in which Mark discusses pace layers, dogs, and design systems. He concludes:
- Current design systems thinking limits free, playful expression.
- Design systems uncover organisational disfunction.
- Continual design improvement and delivery is a lie.
- Component-focussed design is siloed thinking.
It’s true many design systems are the blueprints for manufacturing and large scale application. But in almost every instance I can think of, once you move from design to manufacturing the horse has bolted. It’s very difficult to move back into design because the results of the system are in the wild. The more strict the system, the less able you are to change it. That’s why broad principles, just enough governance, and directional examples are far superior to locked-down cookie cutters.
I saw Daniel give a talk at Async where he compared linguistic rules with code style:
We find the prescriptive rules hard to follow, irrespective of how complex they are, because they are invented, arbitrary, and often go against our intuition. The descriptive rules, on the other hand, are easy to follow because they are instinctive. We learned to follow them as children by listening to, analysing and mimicking speech, armed with an inbuilt concept of the basic building blocks of grammar. We follow them subconsciously, often without even knowing the rules exists.
Thus began some thorough research into trying to uncover a universal grammar for readable code:
I am excited by the possibility of discovering descriptive readability rules, and last autumn I started an online experiment to try and find some. My experiment on howreadable.com compared various coding patterns against each other in an attempt to objectively measure their readability. I haven’t found any strong candidates for prescriptive rules so far, but the results are promising and suggest a potential way forward.
I highly recommend reading through this and watching the video of the Async talk (and conference organisers; get Daniel on your line-up!).
Before reading this article, I didn’t understand regular expressions. But now, having read this article, I don’t understand regular expressions and I don’t understand linguistics. Progress!
Once again, we can learn from Christoper Alexander’s A Pattern Language when it comes to create digital design systems, especially this part (which reminds me of one of the panes you can view in Fractal’s default interface):
- Each pattern’s documentation is preceded with a list of other patterns that employ the upcoming pattern
- Each pattern’s documentation is followed by a list of other patterns that are required for this pattern
I’m currently reading The Sense of Style by Steven Pinker, and it resonates nicely with this article on the numbing effect of the bureaucratic style exemplified in phrases like “officer-involved shooting.”
Watching the cell phone videos of the assault has, for most people, the immediate effect of provoking outrage and awakening a desire for justice. The purpose of bureaucratic speech is to dull these responses. It suggests your outrage is not worth it, that it’s fine to go back to what you were doing, that it’s best to move along and mind your own business.
Use strong, definite language in your writing. Make that sentence your bitch.
Coping mechanisms for grammar pedants. I can see myself using this alot.
The Economist style guide: the "dos and don'ts" section is particularly useful.
A language blog from the Milwaukee Journal Sentinel.
Yes, yes, a thousand times, yes. I'm glad it's not just me.
One of my 43 Things is to eliminate the grocer's apostrophe. Still... this is a well-reasoned argument in its defence.
I'm sure everyone else has already discovered this but I really was L'ing O L when I read the "Hai world" code.