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.
My first experience with "critique the code, not the coder" was from a tech lead who had a printout of the ten commandments of egoless programming pinned on our office wall. They would say we are not our code, but still savagely roasted both coder and code.
I didn't really get it until years later when I did a spit-take at some horrendous code. After wiping my monitor, I checked to see who wrote that monstrosity. It was my code from 6 months ago! I remembered it being a good idea at the time, but now with more information a cleaner approach was obvious. After the mandatory self-hatred subsided, it was time to focus on the code instead of the coder.
That's when, with my beady little fingers, I started collecting all the egoless programming related concepts I could find. And here's that list, ready to be printed out and pinned on some jerk's wall.
Origin: Weinberg (1971), Atwood (2006)
Be kind to the coder, not to the code. Make comments positive and focused on improving the code. Relate comments to team standards, feature requirements, security, increased performance.
Origin: Weinberg (1971), Atwood (2006)
The entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered. When developers fuse identity with output, code reviews become combat, and the learning stops.
Origin: McKinley ("Egoless Engineering"), Linux Kernel Mailing List (Torvalds case study)
A 10x engineer who stresses people out, stifles communication, and drives away other developers is making everyone else 0.5x. That reduces total throughput.
Case Study: In October 2015, Linus Torvalds harshly rejected a patch introducing overflow-check helpers into IPv6 networking code, calling it "braindamage" and "idiotic". In 2018, Torvalds issued a public apology acknowledging his behavior had "hurt and possibly drove away" contributors from kernel development.
Origin: Reddit r/programming (9-year dev), bradmcc (1978 IBM story)
Sometimes when you push back on someone's changes they might accuse you of having an ego problem.
"Why are you being so defensive about your code? We're supposed to be egoless here."
But your resistance isn't ego. It's legitimate concern. Calling it "ego" lets the sloppy contributor off the hook and shifts blame to you.
Weaponisation warning: 1978 IBM story, where a junior programmer would present their code in a walkthrough. Management used "egoless programming" as justification to tear the code apart publicly. The framing was: "Don't be defensive, we're being egoless here" - but the actual effect was humiliation in front of peers.
Origin: Weinberg (1971), Atwood (2006)
No matter how much "karate" you know, someone else will always know more. They can teach you new moves if you ask. Seek and accept input from others, especially when you think it's not required.
Origin: McKinley ("Egoless Engineering")
Owners create queues and bottlenecks. Experts level others up. Everyone owns security; the security team makes everyone better at it. When teams shift from "owning" to "making others better," bottlenecks collapse.
Ownership paradox: Product managers want approval credit, senior engineers want design credit, leads want implementation credit, managers own timeline. Everyone's optimising for their performance review, not the product.
Origin: Reddit r/programming
Objective problems? Point them out. Style preferences? Express them but don't enforce. Snap judgments because "that's not how I'd write it"? Keep them to yourself.
Origin: McKinley ("Egoless Engineering")
Suffering doesn't produce better code. No pain no gain should be left in the 80s. Egoless programming means sustainable collaboration, not martyrdom.
Origin: Weinberg (1971), Atwood (2006), Spolsky
Fixing code isn't the same as rewriting it. Joel Spolsky called rewriting from scratch "the single worst strategic mistake any software company can make." Programmers want to throw away code because they think it's a mess, but it's harder to read code than write it.
And stop saying "refactoring." It's a weasel word. Say "simplifying", that forces you to prove the code will actually be easier to understand. If you can't, you're not simplifying.
Origin: Longnecker, Amy Edmondson, HN discussions
From Longnecker quoting a senior technical leader:
"Our biggest outage last year wasn’t caused by complexity. It happened because an engineer was too afraid to admit they didn’t understand a critical process.”
Amy Edmondson coined the term "team psychological safety" in 1999 with the definition, "A shared belief that the team is safe for interpersonal risk-taking." In other words: being able to speak up, admit mistakes, and ask questions without the fear of humiliation or punishment. Then Google's Project Aristotle (2015) made it famous by finding it was the strongest predictor of team performance across 180+ teams.
Counterintuitive finding: Edmondson studied hospital teams expecting the best teams to report fewer errors. The opposite was true, high-performing teams reported more errors because staff felt safe to speak up.
Origin: StackExchange discussions, Atwood (2006)
Compare "why did you do that?" with "what tradeoffs did you consider?" Same question. One makes people defensive, the other doesn't. Default to questions over statements in code review.
Origin: Weinberg (1971), Atwood (2006)
Everyone ships bugs. "Don't beat yourself up" is nice advice that nobody follows — you're going to feel bad anyway. That's fine. The difference is whether your team treats mistakes as normal or as someone's fault. Forward focus: what broke, what catches it next time. That's it.
Origin: Natali Vlatko reviewing Weinberg's principles
"Accept that you will make mistakes" is easy to say. Tests make it true. When a bug hits production, a good test suite moves the conversation from "who screwed up?" to "why didn't CI catch this?" One question assigns blame. The other prevents the next bug.
Origin: StackExchange discussions
The code belongs to your employer. You just wrote it. Once that sinks in, the territorial instinct gets quieter. A good benchmark from StackExchange: will the next person reading this want to thank you or stab you in the face?
Origin: HN discussion
Someone on HN described fixing a top-reported bug in 20 lines during sprint downtime. Their Project Manager questioned why they were working on "irrelevant" tickets. PR closed and bug card still open 18 months later. Their process existed to pad performance reviews, not serve users.
Origin: Coding Horror commenter Raindeer
Who needs to work with it? Whose work does it need to make easier? Be wary of the system that works but makes your life harder. The coders might insist it technically works as requested, that user education will fix the rest. But if it's clumsy and difficult to work with, it's like giving somebody a cast iron pan for a hammer. Yes it works, but no carpenter uses it as his tool of choice.
Origin: Reddit discussions
How do you know the programmer is an extrovert? They look at your shoes when they speak to you. The stereotype is poor EQ, blunt and unfiltered. "When I started programming with other people there were situations where I didn't even realise I was being a jerk." You can't fix what you can't see. "Don't be a jerk" is too simple. Separating self-worth from code problems happens inside you. You can't achieve that with surface-level niceness. The real work is figuring out why criticism feels like attack - and that's an inside job.
Origin: Weinberg (1971), Atwood (2006)
Fight for the best idea, not your idea. Be strong in your convictions, but let new information change your mind. And when you lose the argument, even if you turn out to be right, skip the "I told you so." You get maybe two of those before people stop listening to anything you say.
Origin: Reddit r/learnprogramming
"We all simultaneously have imposter syndrome and a God complex." Both feelings coexist, often in the same person, sometimes in the same hour. Recognising this helps.
Origin: synthesised from HN/Reddit threads
Here are some red flags to watch out for:
Origin: Sidney Dekker (2007), John Allspaw (2012)
The idea comes from Sidney Dekker's 2007 book Just Culture (rooted in healthcare and aviation safety). Then John Allspaw popularized it in tech via Etsy's engineering blog in 2012, and Google's SRE Book made it standard practice.
When new users couldn't sign up due to a production bug, we didn't focus on who caused it. Instead, we calmly clicked the button that rolled back to the previous stable code version. After the bug was fixed and next deployment confirmed stable, instead of pointing fingers, we discussed how to prevent the same sign-up problem from happening again. Being perfect is not realistic, but creating a sign-up automated test that runs before every deployment is.
Origin: Reddit discussions, StackExchange
Ego (pride in accomplishment, motivation) is not the enemy. Defensive attachment is. Having confidence gives you the ability to take risks, accept challenging projects, push yourself. It doesn't mean looking down on others. Confident people don't need to prove it. The proof is in their products.
Origin: Atwood, StackExchange discussions
Have conviction, but update readily when presented with better information. The balance between confidence and arrogance. Focus on "getting it done and getting it right" and it no longer matters whether the solution was your idea.
Origin: Weinberg (1971), Atwood (2006)
I've been the senior who got overruled by a junior, and they were right. They'd been living in that module for weeks. I'd written it 2 years ago and forgotten half the constraints. Title means nothing if you haven't touched the code recently.
Origin: Reddit r/learnprogramming
"My ego is the biggest & I try to justify how great I am only when I feel unsafe/scared." If someone truly felt confident in themselves, they wouldn't need to put others down. The projection is about their pain, not your inadequacy.
Origin: Weinberg (1971), Atwood (2006)
Non-technical people who deal with developers regularly almost universally think we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience. George Costanza was on to something with "delicate genius". Chances are the other person knows more than you. They just don't shove it in your face.
Origin: Reddit discussions
The cynical take: "Authority stems from position, only position and nothing but position." The commandment about knowledge-based authority is "adorable" and "innocent." Compare your technical knowledge to your manager's and note who makes final decisions (hint: not you). Egoless programming is at odds with traditional corporate hierarchies, meaning the process may not exist in a "pure" way.
Origin: Weinberg (1971), Atwood (2006)
Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch and out of sight, with no place in a collaborative environment.
Caveat: If you're the only developer surrounded by people who have no concept of development, socialising may be "an exercise in frustration." The commandment assumes you have a team to collaborate with. When you don't, isolation might be rational self-preservation.
Counterpoint: "In the collaborative environment of lousy coders, the 'guy in the room' is King." Sometimes isolation is protection from dysfunction, not ego. Self-segregation from bad programmers is real.
Origin: Reddit r/learnprogramming, r/cs50
Don't compare yourself to others. Compare yourself to where you were at the start. The only meaningful benchmark is your own progress.
Origin: Weinberg (1971), Atwood (2006), Kent Beck
Good software engineering isn't about preventing change, it's about reducing the cost of change. Create a prototype or proof of concept first, that is easier to estimate and use that gained information to make better planning decisions for the rest of the project. It's much easier when we're told early that the name in the UI has completely changed. Change is not poor planning or scope creep, that's reality.
Further reading: Jerry Weinberg - "The Psychology of Computer Programming" (1971), Jeff Atwood - "The Ten Commandments of Egoless Programming" (2006), Dan McKinley - "Egoless Engineering"
Covers how to stay honest without torching relationships when everyone's heated and the stakes are real. I picked this up because communication is my main growth edge right now. I'm good at staying ca...
The original egoless programming principles are about mindset. Be kind. Don't take it personally. Critique the code, not the coder. Good advice, but mindset strains under pressure, fatigue, and deadli...
A new starter, second week on the job, pushed a change with an undefined variable. It passed testing and passed code review. Then the service team's phones started ringing because users couldn't log i...