The Fool on the Hill: Don't know, don't care

The Fool on the Hill: Don't know, don't care

By: Simon Brooke :: 5 July 2025

The Mechanical Turk. Illustration by Joseph Racknitz - Humboldt University Library, Public Domain

I first wrote about the principle 'don't know, don't care' in my essay Post-scarcity software in February 2006 — which is to say, twenty years ago. There's a lot wrong with that essay, seen from this perspective; my thoughts have moved on a fair bit. But there's far more right than there is wrong.

Firstly, everyone who uses software already uses the principle 'don't know, don't care'. We have to. The code we write (almost always) is built on top of libraries. We use libraries rather than reinventing everything ourselves for reasons of cognitive overload: we cannot keep all the details of all the layers of software under us in our heads and still have room for our own work. We don't know, and don't care, exactly what goes on inside the library code, provided the contract expressed by the API is delivered and the performance is acceptable. If the API contract isn't delivered, we file a bug report. If the performance isn't acceptable, we typically look for an alternative library.

The people who write libraries build them on top of other libraries, and of the operating system, and exactly the same principle applies. The people who write the operating system? They depend on the bootloader. Those who write the bootloader, the BIOS.

And the overwhelming majority of these people depend on compilers. Do you know, without looking, exactly what opcodes your compiler will emit for any arbitrary expression in your preferred high level language?

And those who go below highlevel languages and write assembler? Well, first, how many really check that the opcodes the assembler emits conform exactly to the mnemonics they typed? But also, and more significantly, the opcodes typically run on another layer of software — the microcode — which determines which actual operations the underlying hardware will perform. And the hardware? It, in turn, these days, was designed using software, so in trusting that hardware we're trusting that software to. Do you know exactly how it works? Do you care?

I'm going to bet you don't. You don't know, and you don't care. You trust. We build our software on the shoulders, not of giants, but of trusted colleagues. Armies of trusted colleagues, most of whom we don't know and will never meet. We do this because, by trusting, we allow ourselves to focus on that small part of the whole stack which it is our job to build. And by ruthlessly cutting out care about the exact details of what is going on under us, we have more cognitive resource to apply to doing that job which is specifically our own.

And what this means, in particular, is that if the way a layer in the software below you handles its internal representations of something, it does not matter to you provided the contract provided by the API remains consistent.

What format is this number stored in? That is not your business. You don't need to know, you don't need to care; and it's better for everyone if you don't.

Can I add this number to another number and get a consistent result? That is your business; and the answer, to a domain-appropriate degree of precision, ought to be 'yes'.

For any other number, will the system break if I add it to this number? That, also, is your business; and you ought to be able to be confident that the answer is 'no', unless the physical limits of the machine really have been exhausted.

Be expert at what you do. Carve your gargoyle; lay out the tesserae of your mosaic; carefully lead the panes of your stained glass window. The masons who laid the foundations of this edifice were people like you: careful, responsible skilled craftsmen who knew there work and did it well. Trust them. You don't need to know the details, you don't need to care about the details, and you won't build anything useful if you try to.


(This is just another reason why my whole Post-Scarcity project is mad: I really am trying to design a whole new system, from the (very unconventional) hardware all the way up to the (pretty unconventional) user space, by myself; a project which I know to be far too big for any one person to encompass. Because I want to know, and I want to care. But this is because I am clinically insane, and if you are sane, you should not emulate me.)


Tags: Software Lisp Post Scarcity


| Flying out the hayloft »

This site does not track you; it puts no cookies on your browser. Consequently you don't have to click through any annoying click-throughs, and your privacy rights are not affected.

Wouldn't it be nice if more sites were like this?

About Cookies