Writing on software, systems, and hard-won lessons.
Writing on developer experience, systems thinking, and the mistakes behind both - covering AI workflows, continuous improvement, and the mental models that drive better decisions.
Writing on developer experience, systems thinking, and the mistakes behind both - covering AI workflows, continuous improvement, and the mental models that drive better decisions.
The first person to teach me egoless programming was the biggest egotist I've ever worked with. Custom app, no framework, no tests, no sense. After tearing my code apart one afternoon, he clip clopped back into the office with a printout. I thought it was a termination letter. It was worse, a philosophy lecture D:
"We are not our code," he said. "Be critical of code, kind to coder."
Felt like an excuse for jerks. It took working with better teams to see it wasn't.
Origin: Weinberg (1971), Atwood (2006)
The prerequisite for everything else. When developers fuse identity with output, criticism activates the same neural pathways as physical threats. Code review becomes combat. Learning stops. Until this is solved internally, no process, tool, or management strategy fixes team friction.
Origin: McKinley ("Egoless Engineering"), HN practitioner discussions
You can't have egoless code in a fear-based org. Without personal security in one's role, everything drifts back to gatekeeping, control, and conflict. Low trust kills projects faster than bad architecture.
Origin: McKinley ("Egoless Engineering"), Kranjec (Torvalds case study)
From a systems perspective, driving out other workers reduces total throughput. A "10x engineer" who makes everyone else 0.5x is mathematically a loss. The Linus Torvalds case study: dismissed a security proposal as "brain damaged," developer left, two years later that concern became a real exploit.
Origin: McKinley ("Egoless Engineering")
Owners create queues and bottlenecks. Experts level others up. The security team example: everyone owns security, the security team makes everyone better at it. When teams shift from "owning" to "making others better," bottlenecks collapse.
Origin: Kranjec, StackExchange discussions, Atwood (2006)
Instead of "Why did you do that?" try "I'm curious about your approach, what tradeoffs did you consider?" Assume good intent, ask questions before making statements, praise the good before noting improvements.
Origin: Kranjec (2:37 PM incident), Vlatko retrospective
"Accept that you will make mistakes" becomes actionable through testing. Tests convert personal blame into process improvement, reframing failure from "who screwed up?" to "what didn't catch this?"
Origin: Kranjec, Reddit r/learnprogramming, Atwood comment threads
Naming behaviours makes them discussable and correctable:
Origin: Reddit r/programming (9-year dev), bradmcc (1978 IBM story)
People modify code without understanding it, skip tests, ignore documentation, don't request review from the person who knows the system. Labelling this resistance as "ego" lets sloppy contributors off the hook.
The weaponisation warning: 1978 IBM story, "egoless programming" was used by management to humiliate junior programmers in walkthroughs. The term can be a cudgel. Reframe: "Criticise the code, educate the coder, respect everyone."
Origin: McKinley ("Egoless Engineering"), HN queueing theory discussion
You can't grassroots cooperation without leadership explicitly valuing it. And you can't sustain it without slack time, we don't run machines at 100% utilisation, but we do it to people constantly.
Origin: Kranjec, synthesised from HN/Reddit practitioner threads
Red flags your team has an ego problem:
Sources: Jerry Weinberg's "The Psychology of Computer Programming" (1971), Jeff Atwood, Dan McKinley, Ivan Kranjec, and practitioner discussions from Hacker News, StackExchange, and Reddit.