“The absence of problems” is the best definition I can come up with for quality.
How to create software quality.
I’ve been reading Steven Sinofsky’s Hardcore Software, and particularly enjoyed this quote from a memo discussed in the Zero Defects chapter: You can improve the quality of your code, and if you do, the rewards for yourself and for Microsoft will be immense. The hardest part is to decide that you want to write perfect code. If I wrote that in an internal memo, I imagine the engineering team would mutiny, but software quality is certainly an interesting topic where I continue to refine my thinking. There are so many software quality playbooks out there, and I increasingly believe that all these playbooks work in their intended context, but are often misapplied.
What We Know We Don't Know: Empirical Software Engineering
Empirical Software Engineering is the study of what actually works in programming. Instead of trusting our instincts we collect data, run studies, and peer-review our results. This talk is all about how we empirically find the facts in software and some of the challenges we face, with a particular focus on software defects and productivity. Talk doesn’t seem to be online yet; in the meantime, you can see a recording of an older version of the talk here.
The Case for Software Craftsmanship in the Era of Vibes
From the Zed Blog: Working toward genuine, quality software in an era where code production is not the constraint anymore.
A distributed systems reliability glossary
A list of key concepts for building and testing reliable distributed systems, with basic definitions and deep references.
Software Should Work
An independent conference on software reliability in Columbia, MO on July 16-17, 2026
Seeing Like a Programmer (LambdaConf 2024) — Sympolymathesy, by Chris Krycho
How do we make good software, and indeed, what makes software good: both as software, and in terms of its place in the world?
Geoffrey Litt
Welcome! I work on malleable software: computing environments where anyone can adapt their software to meet their needs with minimal friction. To see what that means to me, read this essay or listen to this interview.
Failures count more than Successes
User-experience is defined by the times when a computer doesn't work, not by the times when it does.
home
A delightful language with friendly error messages, great performance, small assets, and no runtime exceptions.
Perfect Software - Software for an Audience of One
We have many names to describe personal tools. Malleable software speaks to how it behaves. Home-cooked software speaks to who makes it.
Ten FOSS Development Fallacies For User Facing Software
This is a list, inspired by the Five Geek Social Fallacies, of common patterns or behaviours that developers of free/open source software (FOSS) fall into when they try to develop software for users who are not technical, or for whom non-technical users would be the most obvious userbase. Hopefully writing these down (which frankly is cathartic more than anything) is helpful to some in recognising these thought patterns and avoiding them when developing software - I’ve got some of my own thoughts on this at the bottom.
values based software talks
Talk #3 Files, algorithms, media, software as lived practice, and personal software
tools | suckless.org software that sucks less
</> htmx ~ Codin' Dirty
In this article, Carson Gross discusses an alternative approach to software development that challenges the principles outlined in 'Clean Code.' Carson advocates for allowing larger functions in certain cases, preferring integration tests over unit tests, and minimizing the number of classes and interfaces. He shares examples from successful software projects that demonstrate these practices can lead to maintainable, high-quality code.
Long-tail of user needs
An analogy to understand how the rigidity of software interfaces fails to meet what we need from it.
User Agency in Other People's Websites - Orion Reed at JOTB25
When to Design for Emergence