How do we make good software, and indeed, what makes software good: both as software, and in terms of its place in the world?
“As a Windows user, it’s a very surreal way to install a program.” – Unsung
A blog about software craft and 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.
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.
Sustainable software manifesto
The systems we build are never neutral. They can magnify harm or support a just and sustainable society. How we build today shapes tomorrow’s possibilities.
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.
Programming (with AI agents) as theory building
Back in 1985, computer scientist Peter Naur wrote “Programming as Theory Building”. According to Naur — and I agree with him — the core output of software engineers is not the program itself, but the theory of how the program works. In other words, the knowledge inside the engineer’s mind is the primary artifact of engineering work, and the actual software is merely a by-product of that.
What is good software architecture?
What good architecture looks like, how to improve your skill at building it –and why Architects are not always the answer. Guest post by Matthew Hawthorne, who built large systems at Netflix & Twitter
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.
Don't Call Yourself A Programmer, And Other Career Advice | Kalzumeus Software
“I think there’s a lot of value in these.” – Unsung
A blog about software craft and quality
A small matter of programming: perspectives on end user computing
A Small Matter of Programming asks why it has been so d…
Modular: The Claude C Compiler: What It Reveals About the Future of Software
Compilers occupy a special place in computer science. They're a canonical course in computer science education. Building one is a rite of passage. It forces you to confront how software actually works, by examining languages, abstractions, hardware, and the boundary between human intent and machine execution.
If you’re a button, you have one job – Unsung
A blog about software craft and quality
The Next Two Years of Software Engineering
Exploring five critical questions shaping software engineering through 2026, with contrasting scenarios for each. These lenses help prepare for the evolving ...
A Call to Build Models Like We Build Open-Source Software
1 Introduction 2 A brief explanation of open-source software development 3 Community-developed and continually-improved models 3.1 Incremental and cheaply-communicable updates 3.2 Merging models 3.3 Vetting community contributions 3.4 Versioning and backward compatibility 3.5 Modularity and distribution 4 An example future 5 Conclusion