Code & Development
Open Transclude
The Website Obesity Crisis
A Talk by Maciej CegłowskiWeb Design - The First 100 Years
A Talk by Maciej CegłowskiVisualizing Algorithms
An Article by Mike BostockAias
A Profile by Nick TrombleyThe Future of Programming
A Talk by Bret VictorWhat Makes Software Good?
An Article by Mike BostockAn incoherent rant about design systems
An Article by Robin RendleNo matter how fancy your Figma file is or how beautiful and lovingly well organized that Storybook documentation is; the front-end is always your source of truth. You can hate it as much as you like—all those weird buttons, variables, inaccessible form inputs—but that right there is your design system.
...being honest about this is the first step to fixing it.
Right-Angle Doodling Machine
A Game by Clive Thompson- You draw one single line. It can be as long as you like.
- To start the line, you put your pen down.
- You can make right-angle turns only, either 90 degrees or -90 degrees.
- You cannot back up. You must always move forward.
- You don’t lift your pen until you’re ready to stop. When you lift the pen, the doodle is done.
What do I need to read to be great at CSS?
An Article by Baldur BjarnasonA rule of thumb is that the importance of a blog in your feed reader is inversely proportional to their posting cadence. Prioritise the blogs that post only once a month or every couple of weeks over those that post every day or multiple times a day...Building up a large library of sporadically updated blogs is much more useful and much easier to keep up with than trying to keep up with a handful of aggregation sites every day.
Designing with code
An Article by Matthew StrömRecently I’ve had a few opportunities to use code to create design. In two of my bigger projects at The Wall Street Journal, writing code has led to new ideas. Problems that typically plague early designs — e.g. “how does this look with real content?” — are easy to solve. By exploring visual ideas directly in code, I’ve started to see the amazing potential of code as a design tool.
Picking better names for variables, functions, and projects
An Article by Tom MacWright- Avoid weasel words
- Follow patterns religiously
- Don’t cheap out on characters
- Call things the same thing
- Don’t name internal projects
- When things change, change their names
this vs. that
A Website by Phuoc Nguyentixy.land
A Websitesin(t * x) * cos(t * y)
Creative code golfing.
Front-of-the-front-end and back-of-the-front-end web development
An Article by Brad FrostA succinct way I’ve framed the split is that a front-of-the-front-end developer determines the look and feel of a
button
, while a back-of-the-front-end developer determines what happens when thatbutton
is clicked.The Great Divide
An Article by Chris CoyierOn one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript.
On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.
Painting With the Web
An Article by Matthias OttSo much about [Gerhard Richter's painting process] reminds me of designing and building for the Web: The unpredictability, the peculiarities of the material, the improvisation, the bugs, the happy accidents. There is one crucial difference, though. By using static wireframes and static layouts, by separating design and development, we are often limiting our ability to have that creative dialogue with the Web and its materials. We are limiting our potential for playful exploration and for creating surprising and novel solutions. And, most importantly, we are limiting our ability to make conscious, well-informed decisions going forward. By adding more and more layers of abstraction, we are breaking the feedback loop of the creative process.
Technical debt as a lack of understanding
An Article by Dave Rupert"If you develop a program for a long period of time by only adding features but never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer.” — Ward Cunningham
bees & bombs
A Blog
The Sense of Style
Classic style
The guiding metaphor of classic style is seeing the world. The writer can see something that the reader has not yet noticed, and he orients the reader’s gaze so that she can see it for herself. The purpose of writing is presentation, and its motive is disinterested truth. It succeeds when it aligns language with the truth, the proof of success being clarity and simplicity.
The truth can be known, and is not the same as the language that reveals it; prose is a window onto the world.
The assumption of equality
Classic writing, with its assumption of equality between writer and reader, makes the reader feel like a genius. Bad writing makes the reader feel like a dunce.
Nominalization
The English language provides bad writers with a dangerous weapon called nominalization: making something into a noun.
Instead of affirming an idea, you effect its affirmation; rather than postponing something, you implement a postponement.
"Comprehension checks were used as exclusion criteria” would be better said as “we excluded people who failed to understand the instructions.”
“There is not any anticipation there will be a cancellation” would be better as “I don’t anticipate that I will have to cancel.”
Zombie sounds, unlike the verbs whose bodies they snatched, can shamble around without subjects. That is what they have in common with the passive constructions that also bog down these examples.
The curse of knowledge
The better you know something, the less you remember about how hard it was to learn.
The curse of knowledge is the single best explanation I know of why good people write bad prose. It simply doesn’t occur to the writer that her readers don’t know what she knows - that they haven’t mastered the patois of her guild, can’t divine the missing steps that seem too obvious to mention, have no way to visualize a scene that to her is as clear as day. And so she doesn’t bother to explain the jargon, or spell out the logic, or supply the necessary detail.
Structural parallelism
If the new phrase has the same structure as the preceding one, its words can be slotted into the waiting tree, and the reader will absorb it effortlessly. The pattern is called structural parallelism, and it is one of the oldest tricks in the book for elegant (and often stirring) prose.
“He maketh me to lie down in green pastures; he leadeth me beside the still waters.”
You live only once
The logician would argue, You only live once should be rewritten as You live only once, with only next to the thing it qualifies, once.
The logician would be unbearably pedantic, but there is a grain of good taste in the pedantry. Writing is often clearer and more elegant when a writer pushes an only or a not next to the thing that it quantifies. In 1962 John F. Kennedy declared, “We choose to go to the moon not because it is easy but because it is hard.” That sounds a lot classier than “We don’t choose to go to the moon because it is easy but because it is hard."
Such tortuous syntax
How does a writer manage to turn out such tortuous syntax? It happens when he shovels phrase after phrase onto the page in the order which each one occurs to him.
The problem is that the order in which thoughts occur to the writer is different from the order in which they are easily discovered by a reader. It’s a syntactic version of the curse of knowledge. The writer can see the links among the concepts in his internal web of knowledge, and has forgotten that a reader needs to build an orderly tree to decipher them from his string of words.