Simone Weil on Attention and Code Review Practice

What did Simone Weil mean by attention?

Weil meant something radical: attention is the suspension of your own thoughts in order to receive another person’s thinking. It is not critique. It is not evaluation. It is the discipline of making yourself available to understand what another mind has produced.

I used to review code the way most engineers do: scanning for bugs, checking patterns, approving or requesting changes. It was efficient. It was not attention. Attention, in Weil’s sense, would mean reading the code not to judge it but to understand the mind that wrote it. What problem was this person solving? What constraints did they perceive? What tradeoffs did they make, and why?

When I shifted my approach, something changed. My review comments went from “this should use a different pattern” to “I see what you were trying to do here, and I think there’s a path that preserves your intent while handling the edge case at line 47.” The first comment evaluates. The second attends. The difference is not merely stylistic. It is the difference between treating code as an object to be judged and treating it as a window into another engineer’s thinking.

Why does attention matter more than expertise in code review?

Expertise catches bugs. Attention catches the reasoning behind the bugs. An expert reviewer finds what is wrong. An attentive reviewer understands why it went wrong, which is the only knowledge that prevents it from going wrong again.

I tracked my code review feedback over 3 months. In the first month (before reading Weil), 78% of my comments were corrections: “change this,” “fix that,” “this violates our convention.” In the third month, 52% of my comments were questions: “what led you to this approach?”, “have you considered what happens when X?”, “I am curious about this tradeoff.” The correction-heavy reviews resulted in code that passed review. The attention-heavy reviews resulted in engineers who grew. The difference is the difference between fixing a symptom and understanding a cause.

Weil argued that attention is the prerequisite for learning, not the other way around. You do not learn and then attend. You attend and then learn. In code review, this means the reviewer’s primary task is not to apply their knowledge but to understand the author’s knowledge. The application of expertise follows from attention. It cannot substitute for it. This principle connects to what I have observed in writing as thinking: the act of attending to someone else’s work teaches the attendant as much as the author.

How do you practice Weil’s attention in a code review?

You practice it by reading the code twice: once to understand, once to evaluate. Most reviewers do only the second. The first reading, the attentive reading, is where the real value is created.

• First pass: understand: Read the code without forming judgments. Ask only: “What is this person trying to accomplish, and how are they thinking about the problem?” Do not look for bugs. Look for intent.
• Second pass: evaluate: Now apply your expertise. But ground your evaluation in the understanding from the first pass. “Given what you are trying to do (which I now understand), here is a concern about how this handles concurrent requests.”
• Frame comments as questions: Weil’s attention is receptive, not assertive. “Have you considered…” respects the author’s agency. “You should…” does not.
• Limit the scope: Weil wrote that attention cannot be sustained indefinitely. Review no more than 400 lines at a sitting. After that, attention degrades into scanning, and scanning is not review.

What does this mean for engineering culture?

A culture that treats code review as gatekeeping produces defensive engineers. A culture that treats it as attention produces growing engineers. The practice is the same. The quality of attention transforms the outcome.

I have worked on teams where code review was feared and teams where it was welcomed. The difference was never the strictness of the standards. It was the quality of attention reviewers brought. On the best teams, a code review was a conversation: two minds engaging with a problem. On the worst teams, it was an audit: one mind judging another. Weil would have recognized the difference immediately. Attention creates encounter. Judgment creates hierarchy.

The documentation-as-product mindset applies here too. Code review comments are documentation of thinking. When written with attention, they become a record of how two engineers collaborated on a problem. When written as quick corrections, they become noise.

“Attention is the rarest and purest form of generosity.” — Simone Weil

Code review consumes 6.4 hours per week of the average engineer’s time. That time can be spent scanning and correcting, which is useful. Or it can be spent attending to another person’s thinking, which is transformative. Weil spent her short life arguing that attention is the foundation of all intellectual and moral life. In the small, daily practice of code review, her insight finds its most practical application. Read the code to understand the person who wrote it. Everything else follows from that.