notes

Log | Files | Refs | README

egoless_programming.md (4559B)

      1 # Egoless Programming
      2 
      3 1. **Understand and accept that you will make mistakes.**
      4 
      5    No one writes perfect code. Bugs, oversights, and misjudgments happen to
      6    everyone, including experts. The key is to treat mistakes as opportunities to
      7    learn rather than sources of embarrassment. An egoless programmer fixes
      8    issues calmly, analyzes why they happened, and improves their process instead
      9    of defending errors.
     10 
     11    Example: When a bug is found during testing, thank the person who caught it
     12    instead of feeling attacked.
     13 
     14 2. **You are not your code.**
     15 
     16    Code reviews exist to improve the product, not to judge the programmer. The
     17    goal is to find bugs, catch design flaws, and ensure consistency — not to
     18    criticize someone’s abilities. When your code is reviewed, remember it’s a
     19    normal, expected part of building reliable software. Feedback is about making
     20    the code better together, not about you being wrong.
     21 
     22    Example: Think, “We’re finding issues in the code so it’s stronger,” not
     23    “They’re finding faults in me.”
     24 
     25 3. **No matter how much “karate” you know, someone else will always know more.**
     26 
     27    There’s always a more experienced or specialized developer out there.
     28    Recognizing this keeps you humble and open to learning. Instead of competing
     29    for superiority, treat discussions as chances to improve together. Curiosity
     30    will make you a better programmer than pride ever could.
     31 
     32 4. **Don’t rewrite code without consultation.**
     33 
     34    Even if existing code looks inefficient or messy, consult the team before
     35    reworking it. There’s a fine line between fixing code and rewriting it — know
     36    the difference. Pursue changes as part of a code review, not as a lone
     37    enforcer. Unilateral rewrites can waste time, break dependencies, or erase
     38    important context.
     39 
     40    Example: Before refactoring a module, talk to the original author to
     41    understand the decisions and constraints behind it.
     42 
     43 5. **Treat people who know less than you with respect, deference, and
     44    patience.**
     45 
     46    Mentorship builds stronger teams. Talking down to less experienced developers
     47    discourages them and weakens collaboration. Share knowledge with patience and
     48    humility — remember, you were once a beginner too. Nontechnical colleagues
     49    often see developers as prima donnas or overly sensitive; don’t reinforce
     50    that stereotype with anger or impatience. The way you treat newcomers and
     51    teammates sets the tone for your team’s culture and reputation.
     52 
     53 6. **The only constant in the world is change.**
     54 
     55    Technology evolves quickly—languages, frameworks, and best practices
     56    constantly shift. Adaptability is more important than mastery of a single
     57    tool. Be ready to learn new approaches and let go of old habits.
     58 
     59    Example: Moving from monoliths to microservices, or from manual deployments
     60    to CI/CD pipelines, requires flexibility.
     61 
     62 7. **The only true authority stems from knowledge, not from position.**
     63 
     64    Titles and hierarchy shouldn’t override logic or facts. In a healthy
     65    engineering culture, ideas win on merit, not on who said them. Leaders should
     66    earn respect through understanding and clear reasoning, not through formal
     67    rank.
     68 
     69 8. **Fight for what you believe, but gracefully accept defeat.**
     70 
     71    If you think something is important, advocate for it with evidence and
     72    conviction. But once the team decides, support the outcome even if it wasn’t
     73    your proposal. This balance between assertiveness and teamwork builds trust
     74    and keeps projects moving forward.
     75 
     76 9. **Don’t be “the guy in the room.”**
     77 
     78    This means don’t act like you’re smarter than everyone else. The “guy in the
     79    room” (or “hero programmer”) dominates conversations, dismisses others, and
     80    resists compromise. Avoid that behavior; it alienates teammates and stifles
     81    creativity. Good programmers make the entire team better, not just
     82    themselves.
     83 
     84 10. **Critique code instead of people – be kind to the coder, not to the code.**
     85 
     86     When reviewing code, focus on improving it, not judging the person behind
     87     it. Tone matters: say “This function could be clearer if…” rather than “You
     88     didn’t write this well.” Constructive feedback builds confidence and shared
     89     understanding.
     90 
     91 ([The Psychology of Computer Programming](https://archive.org/details/psychologyofcomp00unse)
     92 by Gerald M. Weinberg, describes principles for healthy, collaborative software
     93 development that values humility, learning, and teamwork over ego or rivalry.)