EGO-LESS

In 1971, Gerald Weinberg published The Psychology of Computer Programming. He coined a term: egoless programming. The idea was simple. Code should be reviewed by others. I've learned to welcome that review. Your code is not your identity.

Weinberg wasn't saying don't care. He was saying separate the caring from the defending. Care about the outcome. Don't defend the path you took to get there.

The design world got there through a different door. "Kill your darlings" .. Arthur Quiller-Couch (1914), popularized by Faulkner, practiced by every designer who ever shipped something. IDEO built an entire methodology around it: prototype fast, test with real people, throw away what doesn't work. The prototype is disposable. The insight it generates isn't.

Both moments require the same skill: receiving the feedback without letting it puncture your willingness to try again. Having enough pride to put something forward you're willing to stand by. Having enough absence of ego to let someone else improve it.

Carol Dweck's work on mindset puts it in sharp relief. A fixed mindset treats ability as identity .. criticism of output becomes criticism of self. A growth mindset treats ability as something that develops .. criticism of output becomes data for iteration.

Amy Edmondson at Harvard built on this with psychological safety .. the idea that teams perform better when members feel safe to take interpersonal risks. In her study of hospital teams, the best-performing units reported more errors, not fewer. They weren't making more mistakes. They felt safe enough to surface them.

It's consistent: when my identity isn't at stake, I can see what's actually happening. When it is, every signal gets filtered through "what does this say about me?"

Ed Catmull, co-founder of Pixar, describes the creative process as inherently painful. The early versions of every Pixar film were, in his words, "ugly babies." The team had to care enough to keep working through the discomfort, not detach from it. Pure detachment produces commodity work. The films that move people come from people who were willing to be moved themselves.

Paul Saffo's framework: "strong opinions, weakly held." Argue your position with conviction, then drop it the moment better evidence arrives. Jeff Bezos had his own version: "disagree and commit." Different phrases, same move. The conviction isn't the problem. The inability to release it is.

Dieter Rams spent decades refining ten principles of good design. Principle ten: "Good design is as little design as possible." That requires ego .. the confidence to subtract. And then the absence of ego .. the willingness to subtract your own favorite parts.

AI is forcing this conversation in a new way.

You write a function. An LLM rewrites it in 3 seconds. Different approach, same outcome, fewer lines. Your instinct: that should have been my solution. But the function works. Does it matter whose pattern it followed?

Egoless programming asked whether I could accept a colleague's review without defending the code as part of myself. Agent-written code adds a similar test: can I judge the patch without treating who wrote it as a judgment about my value?

In Dell'Acqua et al.'s consulting experiment, participants using AI completed more tasks faster and with higher measured quality on tasks inside the model's capability frontier. Performance dropped outside that frontier, which made evaluation more important than raw tool use.

The design critique, the code review, and the AI rewrite all expose the same question: can you let something you made be changed without feeling like you've been changed?

These traditions are not software methods. They are references I use when a rewrite feels more personal than it is. The practical step is simpler: separate the quality of the change from the feeling of being changed.

So. How do you care enough to make good work but not so much that criticism breaks you?