Operating principles

These are the rules I actually work by. Most of them I learned the slow way, and almost none of them are mine. Where someone said it better first, I have said who.

How I think

1. Why before what. I want to know why something works before I learn what to do about it. A procedure you do not understand breaks the first time the situation changes, and you will not know why.

What I cannot create, I do not understand.

Richard Feynman

2. Problem before name. Describe the problem in plain words before reaching for the term, the framework or the pattern. Once something has a name, people stop looking at it. In my classes we derive the idea first and name it last.

3. Look for the explanation that is hard to vary. A good explanation is one where every part does work, so you cannot change a detail without breaking it. A bad one can be adjusted to fit anything, which means it explains nothing. This is David Deutsch’s test, from The Beginning of Infinity, and I use it on every claim, including mine.

4. Ask what would prove it wrong. If nothing could, it is not knowledge yet. Karl Popper made this the line between science and everything else. In practice I ask for evidence, not confidence, and real numbers over theory.

The first principle is that you must not fool yourself, and you are the easiest person to fool.

Richard Feynman

5. Follow the incentives and the bottleneck. When a system behaves strangely, it is usually doing exactly what it is rewarded for, and it is usually stuck in one place. Charlie Munger: “Show me the incentive and I will show you the outcome.” Eliyahu Goldratt: an hour lost at the bottleneck is an hour lost for the whole system. Fix the constraint you have now. Do not ask about step ten before step one works.

How I build

6. Done means a stranger can confirm it. Nothing is finished until someone who was not in the room can check that it works, without you there to explain. I call this the Verifier’s Rule. It is the only definition of done I trust, for software, for students’ projects and for my own work.

7. Say what done means before you start. Agree on the finish line and on what would make us stop, up front. Open-ended work does not end. It just runs out of energy.

8. Manual first, automation later. Do the work by hand until you understand it, then standardise it, then automate it. Most failed automation is a process nobody understood, running faster.

A complex system that works is invariably found to have evolved from a simple system that worked.

John Gall

9. Ship over perfect. Build the smallest thing that is actually useful, put it in front of real people, measure it, then improve it. Paul Graham’s advice to founders, do things that don’t scale, is the same idea: learn by hand what is worth building.

10. Build systems, not memory. Anything that has to be remembered will eventually be forgotten. Write it down, give it an owner and a deadline, and make the right thing the default.

Civilization advances by extending the number of important operations which we can perform without thinking about them.

Alfred North Whitehead

How I teach

11. People learn by making things. Lectures are consumed and forgotten. A working project is evidence of learning that someone else can check. This is Seymour Papert’s constructionism, and it is the whole reason 100xEngineers exists: education that works for people the lecture hall did not work for.

12. Let them find it before you tell them. Ask the question, let the room work towards the idea, and name it only once they have it. Socrates taught this way, and it still beats any slide.

How I decide

13. Decide small things fast and big things slowly. Most decisions are reversible: make them, learn, correct. A few cannot be undone: treat those with care, evidence and time. Jeff Bezos calls these two-way and one-way doors. The common mistake is treating every door as one-way.

14. Study what people do, not what they say. Never ask someone whether your idea is good. They will be kind and you will learn nothing. Ask what they did last time the problem came up, and what it cost them. Rob Fitzpatrick wrote the book on this, The Mom Test.

What I value

• Honesty about failure. I learned more from the company that failed than from the one that was acquired. Say what broke. Spin teaches nobody anything.
• Specific over impressive. Real examples, real numbers, real names. No credentials in place of an argument.
• Few words. Lead with the answer. If you need three paragraphs to say it, you have not finished thinking. Pascal apologised for a long letter because he had not had time to write a short one.
• Human agency. The point of AI is to expand what a person can do, not to replace their judgment. The part of a system that has to make a promise should still have a human name on it.
• Building in the open. Show the work, the method and the result, so others can check it and build on it.