Egoless programming

Egoless programming is a style of software development in which the programmer’s personal investment in their own code is deliberately set aside, so that quality, not authorship, becomes what the team optimizes for. The code belongs to the team rather than to whoever happened to write it, and criticism of the code is not criticism of the author.

Origins

The concept was introduced by Gerald M. Weinberg in his 1971 book The Psychology of Computer Programming. Weinberg argued that the programmer’s ego is one of the largest obstacles to good software. When people identify with their code, every review becomes a referendum on their competence, and defensive behavior blocks the feedback that would otherwise improve the work. Egoless programming proposes the opposite stance. Treat the code as an artifact the whole team owns and judges on its merits.

The ten commandments

Weinberg’s idea is often distilled into a list of maxims known as the Ten Commandments of Egoless Programming. The wording varies across sources, but the thrust is consistent.

  1. Understand and accept that you will make mistakes.
  2. You are not your code.
  3. No matter how much you know, someone else knows more.
  4. Don’t rewrite code without consultation.
  5. Treat people who know less than you with respect, and don’t condescend.
  6. The only constant is change. Be open to it.
  7. The only true authority stems from knowledge, not from position.
  8. Fight for what you believe, but gracefully accept defeat.
  9. Don’t be "the guy in the room." Keep others in the loop.
  10. Critique code instead of people.

Strengths and weaknesses

Egoless programming is generally credited with making pair programming and structured code walkthroughs productive. When no one feels personally attacked, review becomes a search for defects rather than a defense of reputation. Open communication and shared ownership tend to improve documentation consistency and job satisfaction, and the practice suits complex tasks where no single person holds the whole picture.

The trade-offs are real. Decentralized, high-bandwidth communication can slow a project down, and on simple tasks the coordination cost outweighs the benefit. There is also a risky shift effect, in which a team collectively endorses bolder solutions than any individual would, on the assumption that the group shares the responsibility. Much of the supporting research is old and was conducted in laboratory settings with short tasks, so the evidence is suggestive rather than conclusive.

Rival: the chief programmer team

Egoless programming deliberately minimizes hierarchy and status so that ideas flow freely. Its classical counterpoint is the chief programmer team, proposed by Harlan Mills at IBM in the 1970s, which concentrates authority in a lead programmer supported by specialists. Where egoless programming spreads ownership, the chief programmer team centralizes it. The two represent opposite bets on what produces better software: peer review versus disciplined specialization.

In modern terms, the 10x programmer mythos is a distant cousin of the chief-programmer idea. It rests on the belief that one exceptional individual outperforms a cooperating team. Egoless programming rejects that framing in favor of collective improvement.

See also

  • Grug-brained developer shares the concern with "Fear Of Looking Dumb" and the value of senior developers admitting ignorance.
  • Software craftsmanship is a related philosophy that emphasizes craft and quality, though focused more on individual skill than on team dynamics.
  • Pair programming and mob programming are collaborative practices that depend on the egoless stance to work well.
  • Rubber ducking is a debugging technique that works partly by separating the programmer’s ego from the code under examination.

References

  • Weinberg, Gerald M. (1971). The Psychology of Computer Programming. Van Nostrand Reinhold.
  • Wiegers, Karl Eugene (2001). Peer Reviews in Software: A Practical Guide. Addison-Wesley.