“The absence of problems” is the best definition I can come up with for quality.
“They had no concept of a duty of care to their users.” – Unsung
A blog about software craft and quality
The Era of Software Quality, or the Era of Ostriches?
Humans are bad at writing secure code, and GNOME developers are no exception. GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating...
What Functional Programmers Get Wrong About Systems - Ian Duncan
Type systems verify properties of programs. Production correctness is a property of systems. The gap between these is where the interesting failures live.
You have to beat the models at something
In 2025, I wrote that software engineers ought to be assessed by “value over replacement”: not how much money they made for their company, but how much they…
The Paradox of Perfection: When ‘Good Enough’ is Actually Better
Exploring the tension between engineering perfectionism and pragmatic delivery. Discover why striving for the perfect solution often prevents us from shipping valuable improvements and how to find the balance.
bliki: Two Hard Things
There are only two hard things in Computer Science: cache invalidation and naming things -- Phil Karlton (bonus variations on the page)
Laws of Software Engineering
A collection of principles and patterns that shape software systems, teams, and decisions.
Conway's Law | Laws of Software Engineering
Organizations design systems that mirror their own communication structure.
Anatomy of a Lean Proof for Software Engineers
Intro I recently worked through a problem from a theory of computation textbook that asked me to prove a property of a language using finite automata. The informal proof is a simple constructive proof where you build an automaton and show that it recognizes the language. This is kind of similar to program verification, so I thought it’d be interesting to see what it takes to formalize the proof. Lean is a good choice for this, because its Mathlib has all the theorems for the problem.
The Missing Middle of Open Source
Why serious, maintainer-driven projects struggle to sustain themselves—and what it will take to fix it.
psf (@psf@oldbytes.space)
In their article ["Malleable Software"](https://www.inkandswitch.com/essay/malleable-software), Ink & Switch list various ways that modern software applications fail to serve the user: - Software is too rigid: users can’t tailor it to suit their workflow, except by entering the role of programmers. - Software applications are overspecialized "avocado slicers", not general tools like "knives", so their lack of tailorability is keenly felt. - Software doesn’t provide a reasonable learning curve from beginner to expert; in other words, time spent learning an application doesn’t unlock tailorability, instead the end user must learn an unrelated skill like a markup/scripting language or even the tool’s implementation language. - Software applications are increasingly siloed, so sharing data between apps, let alone orchestrating cross-app workflows, is overly difficult. These are real problems. From what I can tell, Ink & Switch are software researchers, and view the problems from a highly technical perspective, focusing on novel infrastructure that enables end-user programmability. They pose questions such as "how do we ease users into programming?" and "instead of shipping a dead, static binary, can we ship a living image containing programming tools allowing it to be modified in arbitrary ways while still running?" These ideas are technologically exquisite, but they fail to provide a gentle learning curve. (cont'd) 🧵
Dependency Cultures - Richard Feldman | SSW 2026
Software engineering under the spotlight
Think of a tech company as a giant, dimly-lit factory. Work goes on throughout the factory as components shuffle back and forth, and finished products get steadily carted away, but the coordination and efficiency of each section is fairly low. Some parts of the factory get jammed up and don’t do anything for days. Other parts are manically producing broken components which are thrown away unused. However, the factory manager - i.e. the tech company CEO - has one tool to combat this problem. That tool is the spotlight.
The peril of laziness lost | The Observation Deck
In his classic Programming Perl — affectionately known to a generation of technologists as "the Camel Book" — Larry Wall famously wrote of the three virtues of a programmer as laziness, impatience, and hubris: If we’re going to talk about good software design, we have to talk about Laziness, Impatience, and Hubris, the basis of good software design. We’ve all fallen into the trap of using cut-and-paste when we should have defined a higher-level abstraction, if only just a loop or subroutine. To be sure, some folks have gone to the opposite extreme of defining ever-growing mounds of higher level abstractions when they should have used cut-and-paste. Generally, though, most of us need to think about using more abstraction rather than less.
Excuse me, is there a problem?
Many startups fail despite identifying a real problem and building a product that solves that problem. This explains why, so you can avoid their fate.
