The ideas and images that come to mind when you think of technology as an instrument are more useful than if you think of it as a tool. Instruments — I’m specifically talking about musical instruments — are a way to create culture.
You approach instruments with a set of expectations and associations that are more humane. It’s built into their very purpose. Instruments are meant to make something for other people, not making things. When you use an instrument, you have an expectation that it is going to take effort to use it well. Using an instrument takes practice. You form a relationship with that object. It becomes part of your identity that you make something with it. You tune it. You understand that there’s no such thing as a “best” guitar in the same way that there’s not necessarily a “best” phone.
Testing the theory that putting the word “total”, “complete”, or “absolute” in front of any noun automatically makes for an excellent insult.
Hui Jing describes her motivation for creating the lovely Penang Hokkien site:
People who grew up their whole lives in a community that spoke the same mother tongue as themselves would probably find this hard to relate to, but it really was something else to hear my mother tongue streaming out of the speakers of my computer.
She ends with an impassioned call for more local language websites:
If the Internet is meant to enhance the free flow of information and ideas across the world, then creation of content on the web should not largely be limited to English-speaking communities.
This is really good breakdown of what’s different about CSS (compared to other languages).
These differences may feel foreign, but it’s these differences that make CSS so powerful. And it’s my suspicion that developers who embrace these things, and have fully internalized them, tend to be far more proficient in CSS.
In my experience, there’s no casual mode within React. You need to be all-in, keeping up with the ecosystem, or else your knowledge evaporates.
I think Dave is right. At this point, it’s possible to be a React developer exclusively.
React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.
And, as Jake points out, you either need to go all in or not at all—you can’t really incrementally add Reactness to an existing project.
Ethan emphasises the importance of making a shared language the heart of any design system. I heartily agree!
This isn’t new thinking, mind: folks like Alla Kholmatova and Charlotte Jackson have been talking about this for ages. (And in doing so, they’ve massively influenced how I think about modular, pattern-driven design.)
What these brands are taking from web-brutalism — and truly, we should all be learning something here — is that User-centered design doesn’t need to be monopolized by the same colors, same buttons, same photography and even same copy you see in pretty much every single website or product.
Monzo’s guidelines for tone of voice, including a reference to “the curse of knowledge.”
A really deep dive into the
lang attribute, and the
:lang() pseudo-class (hitherto unknown to me). This is all proving really useful for a little side project I’m working on.
Conceding that a typeface is a tool sounds dangerously close to an excuse: toolmakers cannot be held responsible for things made with their tools, or the tasks leading up to those things. They are only responsible for the making of the tool itself. If a person decides to use a hammer to drive home a screw, then so be it. The hammer was only designed for nails. It’s not our fault the typography doesn’t look good. The typeface is just a tool — you’re using it wrong.
It’s really heartwarming to see this idea resonating.
The field of front-end has yet to be defined, because our industry moves too quickly and the range of skills required seems to grow with every passing day. We need to realise that it is impossible to be an expert in every one of those skills, and that’s perfectly fine.
I like this distinction between coders and developers.
The Coder is characterized by his proficiency in a narrow range of chosen skills.
By contrast the Developer’s single greatest skill is in being an applied learner.
I’m definitely not a coder. Alas, by this criterion, I’m also not a developer (because I do not pick things up fast):
Quite simply the Developer has a knack for grokking new [languages|frameworks|platforms] and becoming proficient very quickly.
I prefer Charlie’s framing. It’s not about speed, it’s about priorities:
I’m not a “developer” in that I’m obsessed with code and frameworks. I’m a “developer” as in I develop the users experience for the better.
The fascinating history of interactive fiction from adventure game to hypertext.
The split between parsers and hyperlinks reminds me of different approaches to chatbots: free text entry vs. constrained input.
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!
Practical advice from Ire on localising web pages.
Language conjures the world into being.
Just type stuff.
A lot of “CSS is not real programming” arguments are a basic misunderstanding what CSS is there to achieve. If you want full control over and interface and strive for pixel perfection – don’t use it. If you want to build an interface for an inclusive and diverse web, CSS is a great tool.
Christian does a good job of describing the much-misunderstood declarative nature of CSS.
In any case, belittling people who write CSS and considering them not real developers is arrogant nonsense.
Some great ideas here about using metaphors when explaining technical topics.
I really like these four guidelines for good metaphors: