Handbook

"Everybody lies."

House said it about patients. For me it is a principle of working with information: what we are told about a system and how it really behaves may not match.

It is not always about lying. People often just don't know. A product manager may not know what users actually do. The docs may describe a system that no longer exists. A dashboard may hide an outlier behind the average. Being sure where the bottleneck is does not turn a guess into a fact.

The trouble starts when an explanation replaces observation. You can build a beautiful theory, find ten confirmations for it and still solve the wrong problem.

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

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

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 judgments. Listen to what the other person says, even when you disagree. Sometimes their point of view shows you what you don't notice yourself.

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

"Look at the root." K. Prutkov.

"Everything passes. Music is eternal."

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.

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.

We don't live because we have found the final answer. We live simply because we live. We spend time with people. We work. We build things. We love. We get tired. We move from one room to another.

A project can matter without becoming your whole identity. A job can be meaningful without becoming the only meaning of your life. And the other way around: you don't need to devalue work to remember that there is something else.

While you are in the room, be in it fully. But don't mistake it for everything you have.

The room matters. But it is only a room.

The project will end. The job will end. One goal will replace another.

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

So sometimes it is enough to walk your path and do well what you can.

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.

I have always tried to understand other people and to be understood. Without trust in words, that is impossible.

I don't lie. Not to people, not to myself. Lying eats effort and time, but that is not the only reason. Even if a lie cost nothing and never came out, I would not lie. I value being able to consider myself an honest person.

This does not mean you should say everything you think to everyone. I can stay silent. I can soften things, I don't cut people with every truth. What I say does not change, how I say it does, depending on how close the person is to me. I won't deceive either of them.

Vague words used for gain are the same deception. "Restructuring" without a reason explains nothing. Name the real reason, and the person won't spend years guessing.

Sometimes an agreement has to be broken. Then explain why, and deal with the people it affected. Staying silent and disappearing is not allowed. One explanation is not enough: you have to agree on how long to wait, when a solution will come and what the options are. And ask the person which risks they see, instead of assuming there are none.

"Fake it until you make it" is not mine. I want to grow starting from reality, not from a fake image of myself. It is fine for me to be who I am right now. "Do your best when needed" is mine.

The more precisely a task is set, the more precise the result can be.

A vague wording is the price paid by whoever sets the task: the result will depend on how the performer understood it.

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 gradually: 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 finding a parking spot takes computer vision, geospatial analytics and a predictive model, it may be worth first checking whether there is a free spot in the next row.

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 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.

After an outage it matters to look not only at what happened, but also at what we did not see. What could have gone down earlier? Who never reached the system? Which error never became an incident only 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.

A postmortem is not for finding someone to blame. If the plane made it back, the bullet holes proved the system could survive them. It is more important to find the damage after which the plane would not have returned.

Don't blame the pilot for the bullet holes when he made it back to base.

When something breaks, first you put out the fire. Then you go through it with the team and move on. No blame is needed. There is no public flogging, this is not a kindergarten.

If a person broke the rules, you decide whether you are ready to keep working with them and whether to give a second chance. If not, you calmly tell them so.

If the person is not at fault, or I could have made the same mistake, the problem is in the conditions. Those are what to change.

The second pilot can land the plane, but the captain answers for the landing.

The model you launched, and the skills you wrote or installed, do not take responsibility.

A human always answers for the result.

Does not affect the user: I let the agent go. The user sees the result: a test is needed. A mistake can break a client process: a human checks the result, and there should be several check scenarios.

I move the line between trust and checking by experience, trial and error, not by faith: models change every month or two.

I still read the code myself. If the AI is switched off, I need to understand what is going on in the system.

You need to do what others can't, even with agents. That is what will be valued in the future.

If you only carry out tasks, you become a go-between for the person who sets the task and the agent. That layer is easy to replace. If you decide what is worth doing and how best to do it, your value is not limited to carrying out tasks.

An LLM picks the most probable continuation, so its result tends toward the average. I don't hand over the original idea and the thinking.

I am afraid of losing the ability to think. Craft shapes the person who practices it, and it is scary to lose it.

Do craft. The ability to create something new has to be developed as a personal skill.