Handbook

Huo Yuanjia meets the Japanese master Tanaka Anno over a tea ceremony. They talk about grades of tea, and Huo refuses to split them into higher and lower: tea does not judge itself, people invented that. Tanaka asks which style of wushu is stronger, and Huo answers that the style does not matter - the mastery does.

Don't cling to labels and to your own judgements. Listen to what the other person says, even when you disagree.

Sometimes another point of view shows you what you cannot see yourself.

Be strong enough to hold your own opinion, and free enough to change it.

"Look at the root." K. Prutkov.

House said it about patients. The same goes for requirements, documentation, status reports, metrics, and your own assumptions.

People aren't always deliberately lying. Often they just don't know. The product manager may not know what users actually do. The docs may describe a system that no longer exists. The dashboard may hide the outlier behind the average. Being sure where the bottleneck is doesn't make it a fact.

The problem begins when explanation replaces observation. You can build a beautiful theory, find a dozen confirmations for it, and still be solving the wrong problem.

If the dog barks, it doesn't necessarily mean someone is at the door.

First look at what is actually happening. Then form a hypothesis. Only then look for a solution.

The simplest explanation is not necessarily the right one. But if you can explain a phenomenon without new entities, hidden dependencies, and improbable coincidences, there is no reason to add them.

Complexity often appears exactly this way: one hypothesis requires a second, the second a third, and then you have to build a system to explain the system you invented to explain the first problem.

If explaining how the mouse got under the cupboard takes Kafka, Kubernetes, and a distributed observability platform, it may be time to take another look at the cupboard.

Don't add entities until reality asks for them.

During World War II, engineers studied the returning planes and wanted to reinforce the places with the most bullet holes. The statistician Abraham Wald noticed the obvious problem: they were only seeing the planes that had made it back. The planes with critical damage simply never made it into the sample.

In development it is easy to do the same. We see the successful requests, the users who stayed, and the systems that survived incidents. We don't see what never made it to us.

That is why after an outage it matters to look not only at what happened, but also at what we never got to see. What could have gone down earlier? Who never reached the system? Which error never became an incident just because we got lucky?

You cannot build a system where nobody ever makes a mistake. Pilots make mistakes. Engineers make mistakes. Operators make mistakes. Services go down.

Safety does not start with the hope that no error will happen. It starts with the question: what happens when one does?

The error must be visible. The consequences - contained. Critical data - protected. The system must have a margin of safety, and the person must be able to stop the process when something looks wrong.

A good safety culture does not look for perfect people. It builds an environment where an ordinary human mistake does not turn into a catastrophe.

A good system is not one where it is impossible to take a bullet hole.

A good system simply lets you return to base.

Cat Mode is not about laziness. A cat runs perfectly well when there is a mouse to catch. It just doesn't run the rest of the time.

Not everything requires a reaction. Not everything requires worrying. And far from everything is under our control.

You can disagree with a decision made above you. You can hate the deadline. You can see the company heading the wrong way. But if you cannot change it, constant fighting changes nothing.

The cat picks the spot where it lies down.

Don't worry about what you cannot change. Control what you can. Let the rest go.

A path doesn't have to have a final destination.

The project will end. The job will end. One goal will replace another. If you only ever look at the next point, life turns into waiting for the moment it finally starts.

But that 'later' may never come.

Life doesn't have to lead anywhere. It is the way.

So sometimes it is enough to walk your path and do well what is right in front of you.

We don't live because we have found the final answer. We live because we are here.

We spend time with people. We work. We build things. We love. We get tired. We move from one room to another.

Work is one room. Not the whole house.

A project can matter without becoming your identity. A job can matter without becoming the meaning of your life. While you are in the room, be in it fully. Just don't forget there are others.

The room matters. But it is only a room.

Don't turn temporary things into eternal ones.

A language can become part of your identity. A framework can become a religion. A company can become the place that seems irreplaceable. A title can become something without which you no longer know who you are.

Then a few years pass.

The language changes. The framework dies. The company disappears. The project shuts down. People leave. One day we will too.

So don't worship a tool just because it is the best one today. Don't build your identity around a technology. Don't mistake the temporary for the eternal.

Tools change. The ability to think stays.

It doesn't matter what you play. What matters is that you play.