12 ms·

Dad and the ten commandments of egoless programming (2012)

247 points by grzm 5y ago

watwut 5y ago
For me egoless programming means I just cease to care. I do it for money and I am glad when the day is over. If I have ego in it, I care more. I will do more, test more, refactor more, design better.
- metters 5y ago
  The article does not mean being ego-less about the product, the customer, or the user. It means being ego-less about yourself as a developer, at least that’s how I understand it. In other words, do not stop to care about the product, the customer, or the user. Stop caring about __your ego__, when other developers criticize you (in contrast to not caring when they criticize you)
  - watwut 5y ago
    That is how I mean it too. For me it means not caring, as I said. I have also found that accepting all criticism from other developers makes me the submissive one. They are not always correct, pushing back when they are not matters a lot. Otherwise you get more and more absurd complaints.
    - tuyiown 5y ago
      Maybe by seeing it that way: imagine you are emotionally invested, «caring», but the only thing that change is the way you interact with others, directly, or through the code you push. Examples • I don’t like this code style , I’ll post mine -> I’ll replicate the code style, maybe I’m missing something, and if not I’ll discuss it and propose my pref on next review • reviewer suggested a change that would introduce an error, or something smelly -> treat it as welcomed feedback, make sure to perfectly understand the seemingly subtle difference in approaches, and with a thorough explanation. Your general antidote against bad effects of ego is to convert the emotion into a genuine effort to demonstrate your point. It’s hard, and failure to explain properly backfire, but it’s probably visible in your work too, so it’s great reality check to measure where your ego or humility should be
      - watwut 5y ago
        > reviewer suggested a change that would introduce an error, or something smelly - treat it as welcomed feedback, make sure to perfectly understand the seemingly subtle difference in approaches, and with a thorough explanation I used to do that. The team dynamic went wrong every time. I ended up being the one people picked on the most, complaining about things they had no issue other people to do. And half the time it was not genuine code quality anything. It was asserting dominance or thinking I like it. The team dynamic is a thing. And all of this "be thankful" may be good advice for very aggressive people. I am not, for someone like me it is very bad advice. When I was younger I read and followed advice like this. It was literally opposite of what I needed. Fact is, people react to what you do. The thing that helped me was starting to push back on these systematically. Even when I feel bad about pushing bad. Or if it feels rude. And it really helped. ----- If it is subtle difference in approach, then my way is as good as yours. If you want to change team approach, open it on meeting, get freaking consensus from all. Don't sneak it in my code reviews without any prior discussion. And do it for everyone, not just for the most accommodating person on team (which I am no longer and intend to never become again).
        tuyiown 5y ago
        Ok, I didn't meant to introducing unsolicited advice, more like illustration to make sure that leaving ego didn't meant anything about caring or not, but mostly _how_ you do express your carefulness, especially converting into a constructive loop. That being said, your default mode of conversion on this whole thread is confrontational, that facilitate self-cornering a lot, especially that leaving no open end in the conversation, forcing uneasiness. It's one burden to make sure the conversation goes well when one speaks. I don't know you or your team, maybe nothing in this can help you, or maybe you are in a dysfunctional team, or even the fit is not good, but accepting things in a forever silence, without discussions, might really lead you into bad places. Leave some space in your mind for improvement, even if you're not ready right now, no reasons give up forever.
        watwut 5y ago
        Two of my comments were purely expressing how I feel. Third one was tldr of my past experiences. Only the part under lines seems confronting, which is not that much and hardly a whole thread. I am really unsure about what corner I am supposed to lock myself in with these. Also, it was repeated experience that has nothing to do with my current team. I am not in my first team and learned those lessons in the past ones. And really, not every code review comment will improve you. Acknowledging that significant amount of them are pure preferences or even someone being wrong is not refusal to improve. And yet another category of them are half baked ideas. Just that, people give comments for variety of reasons and you have to manage them all.
    - metters 5y ago
      This is a good point and a perspective I neglected. Usually, when receiving feedback on my code I solve this by discussing the _why_ after receiving a _what_ as feedback. When giving feedback, I try to do the same: Instead of just saying what is bad/wrong/smelly etc. and telling how to change the code I’ll also give the reasons why I think so. The discussion afterwards should clarify the remark and I am open to the possibility that I am wrong. But you are right, at the moment I feel like currently I am giving up my approach/code too easily. This is partially because my colleagues are quite experienced and I’m very lucky to be able to learn from them. Edit: Improved the punctuation.
Mageek 5y ago
This is a great list - thank you. I learned a long time ago to not use “you” or similar in code reviews, as it is too easy to associate a critique of code with a critique of the coder. Changing “You should change this” to “This should be changed” or even “We should change this” can make a world of difference.
- wnolens 5y ago
  Yes, the "we" in place of "you" is a meaningful difference I've noticed in code reviews. Having to participate in a development team has made me a bit of a nicer person, as my default reaction is to blame. But that's completely inappropriate.
  - merlincorey 5y ago
    The power of "we" in not just Code Reviews but in Architecture, Design, and even Mentoring is quite strong in my experience. It sounds like "this one trick" but it truly is that effective.
  - Swizec 5y ago
    One problem with "we" is when you work with people who aren't yet used to american corporatisms. You say "We should change this" and it doesn't get changed because you assumed they'll understand that you meant they should change it. But they think you just offered to change it for them and sit back waiting for you to do what you said you would.
    - wnolens 5y ago
      Lol that's pretty funny to view as a cultural difference.. in my experiences it's mostly unwillingness to take responsibility.
      - Swizec 5y ago
        Not so much a cultural difference as a language barrier. “We” is unclear. It diffuses responsibility. Makes it easy for everyone to think someone else is owning $thing.
mwattsun 5y ago
I've been familiar with the concept of egoless programming [1] since early in my career (mid 80's). I was drawn to it because I was also attracted to Eastern philosophies about minimizing your ego and identity to be more aware and in the moment (mediation, mindfulness). There was another idea that I was drawn to at the same time "Flow: The Psychology of Optimal Experience" by Mihaly Csikszentmihalyi [2]. Egoless programming and flow became linked for me. I think for this reason I've always had trouble with 9 > 9 Don’t be “the coder in the corner.” I understand the spirit of it, but I'm sure you can think of great programs written by one person. We had an example of that on the front page of HN yesterday, "Essence: Desktop operating system built from scratch" [3]. I'm currently learning Elm and that project has also had issues because the lone creator maintains tight control and doesn't handle feedback the way people would like him to, "Why I'm leaving Elm" [4]. So while I think Gerald Weinberg's book "The Psychology of Computer Programming" [5] is really great for interacting with your team (don't personalize, don't get defensive, or worse, offensive) you still need some ego to interact with people. To me "Egoless programming" is more about getting yourself out of the way when coding, much like a basketball player loses him or herself in the game. If while I'm writing code, in the back of my mind I'm thinking "Oh, this is dumb, people are going to criticize this", like I have a backseat driver, then that's ego getting in the way. The flow idea is to get your ego out of the way. That's the best egoless programming. [1] https://en.wikipedia.org/wiki/Egoless_programming https://en.wikipedia.org/wiki/Egoless_programming [2] https://www.goodreads.com/book/show/66354.Flow https://www.goodreads.com/book/show/66354.Flow [3] https://news.ycombinator.com/item?id=29950740 https://news.ycombinator.com/item?id=29950740 [4] https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=22821447 [5] https://www.google.com/books/edition/The_Psychology_of_Computer_Programming/76dIAAAAMAAJ?hl=en https://www.google.com/books/edition/The_Psychology_of_Compu...
- hnfong 5y ago
  Meditation is a process that works to block all "external" stimuli so that one can focus on the "self"... not sure how that works with minimizing the ego? Presumably the realization that "my code is not me" could be a connection to more spiritual realizations like "my ____ is not me", but still it's not exactly minimizing the ego in the usual sense.
mkl95 5y ago
I agree with all of it. I find commandment 2 to be the most enlightening one. > You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered. In my career, I have had to deal with other senior developers who would throw tantrums whenever I pointed out something problematic about their code. Over the years, there's something all those people seem to have in common - they are stuck in an endless loop of making mistakes and refusing to learn from them.
- hutzlibu 5y ago
  "Over the years, there's something all those people seem to have in common - they are stuck in an endless loop of making mistakes and refusing to learn from them." I feel this sadly describes many partnerships, as well as great parts of society and humanity as its whole. But I am optimistic, that this can change, without a big catastrophic event needed for people to wake up.
- lkschubert8 5y ago
  I really don't understand the attitude of getting frustrated when people correct mistakes in your code review. I would so much rather have a coworker catch my bug in a cr than have it make it to prod. One is mildly embarrassing (if you tie your ego to your code) the other has an actual impact.
  - epolanski 5y ago
    The overwhelming majority of comments I read, and I wish that was true just for my company, it applies to majority of OSS as well rarely if ever catch a bug. I see most of the discussion involve preferences, practices and names, rarely api and architecture, even less bugs.
    - ScottBurson 5y ago
      It's very hard to catch bugs in a code review. I manage it occasionally, but it's much more common that I'll be working on something else that touches on some piece of code that already passed review, and then I'll notice a bug, because I'm already thinking about how that module should work -- I have already loaded the relevant context into my head. Loading that context just to do a code review takes too long.
vanusa 5y ago
Many timeless truths in this piece. Thanks for posting.
mcguire 5y ago
"Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer." There's a corollary to that: when you are working on someone else's code, don't restyle or re-architect to fit your vision. Don't even use your style or preferred architecture or design on your own additions; try to blend in with the rest of the code.
abotsis 5y ago
#9 took me years to realize. Even more when you have an idea, share it, someone who’s not in the corner takes it and runs with it. That experience is even more isolating because the immediate reaction is to just not share any more ideas. It took me even more years to master- because sure, not being in the corner is one thing, but getting out of it is another. It took a manager who listened to me and thrust me out to fix it.
- monkeybutton 5y ago
  >Even more when you have an idea, share it, someone who’s not in the corner takes it and runs with it. That experience is even more isolating because the immediate reaction is to just not share any more ideas. This! But I learned the lesson as the person who took the idea and ran with it. The "coworker in the corner" got pissed off and snapped at me one day in front of a few people. I wasn't the only one to have the experience and got to have an awkward conversation with our manager about having to walk on eggshells around certain coworkers. The end result was I didn't care what he worked on. Code reviews? Approved, no questions. Your ideas? Awesome, but you're on your own for getting them into production, bye. Don't be like that. You will suffer. You will know you are suffering too, when you compare yourself to your "lesser" peers who are getting more traction with their ideas while you become resentful.
541 5y ago
> You are not your code… As simple and important as this is for productive code reviews, I observed in my experience that it’s not as common a trait as one expects it to be. I can maybe attribute it to the stigma that is more deep rooted. In setups where rigorous code reviews are not norm, I notice, many if not most people, take the comments on their code as comments on self. Given how rampant this is at several workplaces, what ways/processes can be recommended to be adopted in such setups to have more productive, open and meaningful reviews and ease breaking the stigmas associated?
- sverhagen 5y ago
  It needs to be reinforced by the team, and not left up to the individual. A team or manager can encourage the behavior (even by just setting expectations at the time of hiring) and based on that, hopefully, some technical leaders are encouraged to lead by example. I also think it has to be part of a bigger strategy of egoless collaboration, and not hiring assholes.
ChrisMarshallNY 5y ago
I absolutely love that! Thanks so much for sharing it, and it was a great story.
amelius 5y ago
Sounds like a bunch of personality traits which are good to have in theory, but hasn't psychology taught us that you can't change personality even if you try very hard?
- brianmcc 5y ago
  None of these are personality traits IMO, they're more rules/guidelines. I don't think psychology has ever ruled on personality being immutable either. I mean, if you're reluctant to change, you probably won't do. But wanting to change is surely at least half the battle!
  - throwaway984393 5y ago
    I don't know anything about psychology, but I know for sure I've changed my personality. The battle's not over yet, though...
- mwattsun 5y ago
  It's simpler than that. When a cop pulls you over you have a mental script for how to talk to the police. When some dude in a bar bothers you then you have a different script. When you are at work discussing your code with people, Dad and the ten commandments are suggesting you rewrite your script so you can be more effective and behave in an acceptable manner. They literally have Codes of Conduct now because some people don't know how to behave. They might be from a different culture, be differently mentally abled, etc... and need some guidance.
dang 5y ago
One past thread: Dad and The Ten Commandments of Egoless Programming (2012) - https://news.ycombinator.com/item?id=9203634 https://news.ycombinator.com/item?id=9203634 - March 2015 (75 comments)
skmurphy 5y ago
This article is a direct lift from https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/ https://blog.codinghorror.com/the-ten-commandments-of-egoles... the bulk of it is a verbatim copy of Atwood's summary without credit. These rules do not appear in this form or as a list of "10 commandments" in "Psychology of Computer Programming."
- deleted 5y ago
  [deleted]
- pvg 5y ago
  I assume you've read the book, what form, if any, do they appear in? I just skimmed through the text very superficially and didn't find anything that looked like these 'commandments'. Is the original Atwood post as iffy as this makes it seem or did I just miss relevant parts?
  - skmurphy 5y ago
    I have read the book several times, Atwood offers more of a artistic interpretation of Weinberg's insights. It's no accident that no quote marks appear in his version.
    - pvg 5y ago
      Thanks, I suppose I'll read it myself to get a better idea of the degree of interpretation involved. There's a comment on the Atwood article which makes a point similar to yours above and Atwood's reply is very odd: https://discourse.codinghorror.com/t/the-ten-commandments-of-egoless-programming/825/27 https://discourse.codinghorror.com/t/the-ten-commandments-of... He seems to think these are, in part at least, quotes. And it's not just the "guy in the room" bit - when the commenter points out the book contains no 'commandments', Atwood doesn't say 'Oh, I just summarized it in list form'. He says he doesn't know where the text came from (?!). It's like the Atwood piece is itself derivative of something and it's not just the book and Atwood's own writing? Weird.
      - 5y ago
deleted 5y ago
[deleted]
ianbicking 5y ago
For a contrast on Egoless Programming: https://dawnproject.com/ https://dawnproject.com/ "THE DAWN PROJECT: Making Computers Safe for Humanity. We Demand Software that Never Fails and Can’t Be Hacked"
- Twisol 5y ago
  (EDIT: Oh, I whooshed myself pretty hard on this. "contrast on egoless", yes, absolutely >_<) > Dan leads The Dawn Project. He knows more about developing software that never fails and can’t be hacked than anyone else. He has designed, managed, or directly implemented all The Dawn Project technology and he makes all the decisions regarding technology development. The managers below Dan have been steeped in this technology for over 20 years. They know far more about software development than the people below them in the organization chart. And so on down to the lowest level. But even at that level, we have nothing but Special Forces class programmers. I... I can't find anything that's not simply boosting Mr. O'Dowd. This is clearly a B2B marketing website, not a technical resource. More power to them, but there's nothing here for outsiders. It's also kind of concerning that software like CompCert and seL4 isn't mentioned anywhere. Academic work in software verification is making steady progress; it feels really dirty to pose as the lone group that cares about this stuff. I don't really disagree with the ethical or factual material; there's just nothing actionable.
- astrange 5y ago
  Surely fighter jet software makes things less safe if it "never fails". Same for cars, an unsafe product by definition.
xupybd 5y ago
As a childless 37 year old it's a little worrying to hear 62 is old for a 22 year old son. I'd better hurry up.
- mromanuk 5y ago
  I had my first daughter at 35, my second daughter at 41. I'm 43 (male). A friend of mine had his first child at 47. Just two datapoint. Was common in the XX century to start having children at 20s, though.
thakoppno 5y ago
This reminds me a lot of the advice of John Perry Barlow. 1. Be patient. No matter what. 2. Don’t badmouth: Assign responsibility, not blame. Say nothing of another you wouldn’t say to him. 3. Never assume the motives of others are, to them, less noble than yours are to you. 4. Expand your sense of the possible. 5. Don’t trouble yourself with matters you truly cannot change. 6. Expect no more of anyone than you can deliver yourself. 7. Tolerate ambiguity. 8. Laugh at yourself frequently. 9. Concern yourself with what is right rather than who is right. 10. Never forget that, no matter how certain, you might be wrong. 11. Give up blood sports. 12. Remember that your life belongs to others as well. Don’t risk it frivolously. 13. Never lie to anyone for any reason. (Lies of omission are sometimes exempt.) 14. Learn the needs of those around you and respect them. 15. Avoid the pursuit of happiness. Seek to define your mission and pursue that. 16. Reduce your use of the first personal pronoun. 17. Praise at least as often as you disparage. 18. Admit your errors freely and soon. 19. Become less suspicious of joy. 20. Understand humility. 21. Remember that love forgives everything. 22. Foster dignity. 23. Live memorably. 24. Love yourself. 25. Endure.
- Shared404 5y ago
  I love this list. One clarification I would make: > 21. Remember that love forgives everything. We all need to remember that forgiveness does not mean acceptance, or trust, or that it means you need to interact with someone. It means that you let go of a grudge. This is an important note that took me a while to learn - forgiving is a gift to yourself, not the person you forgive.
- yuuu 5y ago
- the_cramer 5y ago
  Is there any detailed explanation on these points? I only find this exact quoted list in my searches. Seems that the original was also only a list of these points. "Give up blood sport" - Why? Did martial arts for 10 years, helped a lot with some other points in these list, especially the self-awareness and decency (humble-ness?). Or do i misunderstand this point? "Live memorably" - That's straight up a wall tattoo quote, isn't it? /s
hk012022 5y ago
These are excellent skills and it would benefit both the developer and their team. In practice, it is very hard to follow them and emotions always overpower humans. The ability to keep them in control is everything.
astrange 5y ago
He came home and his dad printed out a list of random programming tips to discuss with his not-a-programmer son who then remembered them enough to write a blog post about it? Reads like a recipe intro.
deleted 5y ago
[deleted]
throwaway984393 5y ago
I like that most tips you find about being a better programmer have nothing really to do with programming, they're about being a better person.

247 points by grzm 5y ago

For me egoless programming means I just cease to care. I do it for money and I am glad when the day is over. If I have ego in it, I care more. I will do more, test more, refactor more, design better.

metters 5y ago
The article does not mean being ego-less about the product, the customer, or the user. It means being ego-less about yourself as a developer, at least that’s how I understand it. In other words, do not stop to care about the product, the customer, or the user. Stop caring about __your ego__, when other developers criticize you (in contrast to not caring when they criticize you)
- watwut 5y ago
  That is how I mean it too. For me it means not caring, as I said. I have also found that accepting all criticism from other developers makes me the submissive one. They are not always correct, pushing back when they are not matters a lot. Otherwise you get more and more absurd complaints.
  - tuyiown 5y ago
    Maybe by seeing it that way: imagine you are emotionally invested, «caring», but the only thing that change is the way you interact with others, directly, or through the code you push. Examples • I don’t like this code style , I’ll post mine -> I’ll replicate the code style, maybe I’m missing something, and if not I’ll discuss it and propose my pref on next review • reviewer suggested a change that would introduce an error, or something smelly -> treat it as welcomed feedback, make sure to perfectly understand the seemingly subtle difference in approaches, and with a thorough explanation. Your general antidote against bad effects of ego is to convert the emotion into a genuine effort to demonstrate your point. It’s hard, and failure to explain properly backfire, but it’s probably visible in your work too, so it’s great reality check to measure where your ego or humility should be
    - watwut 5y ago
      > reviewer suggested a change that would introduce an error, or something smelly - treat it as welcomed feedback, make sure to perfectly understand the seemingly subtle difference in approaches, and with a thorough explanation I used to do that. The team dynamic went wrong every time. I ended up being the one people picked on the most, complaining about things they had no issue other people to do. And half the time it was not genuine code quality anything. It was asserting dominance or thinking I like it. The team dynamic is a thing. And all of this "be thankful" may be good advice for very aggressive people. I am not, for someone like me it is very bad advice. When I was younger I read and followed advice like this. It was literally opposite of what I needed. Fact is, people react to what you do. The thing that helped me was starting to push back on these systematically. Even when I feel bad about pushing bad. Or if it feels rude. And it really helped. ----- If it is subtle difference in approach, then my way is as good as yours. If you want to change team approach, open it on meeting, get freaking consensus from all. Don't sneak it in my code reviews without any prior discussion. And do it for everyone, not just for the most accommodating person on team (which I am no longer and intend to never become again).
      - tuyiown 5y ago
        Ok, I didn't meant to introducing unsolicited advice, more like illustration to make sure that leaving ego didn't meant anything about caring or not, but mostly _how_ you do express your carefulness, especially converting into a constructive loop. That being said, your default mode of conversion on this whole thread is confrontational, that facilitate self-cornering a lot, especially that leaving no open end in the conversation, forcing uneasiness. It's one burden to make sure the conversation goes well when one speaks. I don't know you or your team, maybe nothing in this can help you, or maybe you are in a dysfunctional team, or even the fit is not good, but accepting things in a forever silence, without discussions, might really lead you into bad places. Leave some space in your mind for improvement, even if you're not ready right now, no reasons give up forever.
        watwut 5y ago
        Two of my comments were purely expressing how I feel. Third one was tldr of my past experiences. Only the part under lines seems confronting, which is not that much and hardly a whole thread. I am really unsure about what corner I am supposed to lock myself in with these. Also, it was repeated experience that has nothing to do with my current team. I am not in my first team and learned those lessons in the past ones. And really, not every code review comment will improve you. Acknowledging that significant amount of them are pure preferences or even someone being wrong is not refusal to improve. And yet another category of them are half baked ideas. Just that, people give comments for variety of reasons and you have to manage them all.
  - metters 5y ago
    This is a good point and a perspective I neglected. Usually, when receiving feedback on my code I solve this by discussing the _why_ after receiving a _what_ as feedback. When giving feedback, I try to do the same: Instead of just saying what is bad/wrong/smelly etc. and telling how to change the code I’ll also give the reasons why I think so. The discussion afterwards should clarify the remark and I am open to the possibility that I am wrong. But you are right, at the moment I feel like currently I am giving up my approach/code too easily. This is partially because my colleagues are quite experienced and I’m very lucky to be able to learn from them. Edit: Improved the punctuation.

Mageek 5y ago

This is a great list - thank you. I learned a long time ago to not use “you” or similar in code reviews, as it is too easy to associate a critique of code with a critique of the coder. Changing “You should change this” to “This should be changed” or even “We should change this” can make a world of difference.

wnolens 5y ago
Yes, the "we" in place of "you" is a meaningful difference I've noticed in code reviews. Having to participate in a development team has made me a bit of a nicer person, as my default reaction is to blame. But that's completely inappropriate.
- merlincorey 5y ago
  The power of "we" in not just Code Reviews but in Architecture, Design, and even Mentoring is quite strong in my experience. It sounds like "this one trick" but it truly is that effective.
- Swizec 5y ago
  One problem with "we" is when you work with people who aren't yet used to american corporatisms. You say "We should change this" and it doesn't get changed because you assumed they'll understand that you meant they should change it. But they think you just offered to change it for them and sit back waiting for you to do what you said you would.
  - wnolens 5y ago
    Lol that's pretty funny to view as a cultural difference.. in my experiences it's mostly unwillingness to take responsibility.
    - Swizec 5y ago
      Not so much a cultural difference as a language barrier. “We” is unclear. It diffuses responsibility. Makes it easy for everyone to think someone else is owning $thing.

mwattsun 5y ago

I've been familiar with the concept of egoless programming [1] since early in my career (mid 80's). I was drawn to it because I was also attracted to Eastern philosophies about minimizing your ego and identity to be more aware and in the moment (mediation, mindfulness). There was another idea that I was drawn to at the same time "Flow: The Psychology of Optimal Experience" by Mihaly Csikszentmihalyi [2]. Egoless programming and flow became linked for me. I think for this reason I've always had trouble with 9 > 9 Don’t be “the coder in the corner.” I understand the spirit of it, but I'm sure you can think of great programs written by one person. We had an example of that on the front page of HN yesterday, "Essence: Desktop operating system built from scratch" [3]. I'm currently learning Elm and that project has also had issues because the lone creator maintains tight control and doesn't handle feedback the way people would like him to, "Why I'm leaving Elm" [4]. So while I think Gerald Weinberg's book "The Psychology of Computer Programming" [5] is really great for interacting with your team (don't personalize, don't get defensive, or worse, offensive) you still need some ego to interact with people. To me "Egoless programming" is more about getting yourself out of the way when coding, much like a basketball player loses him or herself in the game. If while I'm writing code, in the back of my mind I'm thinking "Oh, this is dumb, people are going to criticize this", like I have a backseat driver, then that's ego getting in the way. The flow idea is to get your ego out of the way. That's the best egoless programming. [1] https://en.wikipedia.org/wiki/Egoless_programming https://en.wikipedia.org/wiki/Egoless_programming [2] https://www.goodreads.com/book/show/66354.Flow https://www.goodreads.com/book/show/66354.Flow [3] https://news.ycombinator.com/item?id=29950740 https://news.ycombinator.com/item?id=29950740 [4] https://news.ycombinator.com/item?id=22821447 https://news.ycombinator.com/item?id=22821447 [5] https://www.google.com/books/edition/The_Psychology_of_Computer_Programming/76dIAAAAMAAJ?hl=en https://www.google.com/books/edition/The_Psychology_of_Compu...

hnfong 5y ago
Meditation is a process that works to block all "external" stimuli so that one can focus on the "self"... not sure how that works with minimizing the ego? Presumably the realization that "my code is not me" could be a connection to more spiritual realizations like "my ____ is not me", but still it's not exactly minimizing the ego in the usual sense.

mkl95 5y ago

I agree with all of it. I find commandment 2 to be the most enlightening one. > You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered. In my career, I have had to deal with other senior developers who would throw tantrums whenever I pointed out something problematic about their code. Over the years, there's something all those people seem to have in common - they are stuck in an endless loop of making mistakes and refusing to learn from them.

hutzlibu 5y ago
"Over the years, there's something all those people seem to have in common - they are stuck in an endless loop of making mistakes and refusing to learn from them." I feel this sadly describes many partnerships, as well as great parts of society and humanity as its whole. But I am optimistic, that this can change, without a big catastrophic event needed for people to wake up.
lkschubert8 5y ago
I really don't understand the attitude of getting frustrated when people correct mistakes in your code review. I would so much rather have a coworker catch my bug in a cr than have it make it to prod. One is mildly embarrassing (if you tie your ego to your code) the other has an actual impact.
- epolanski 5y ago
  The overwhelming majority of comments I read, and I wish that was true just for my company, it applies to majority of OSS as well rarely if ever catch a bug. I see most of the discussion involve preferences, practices and names, rarely api and architecture, even less bugs.
  - ScottBurson 5y ago
    It's very hard to catch bugs in a code review. I manage it occasionally, but it's much more common that I'll be working on something else that touches on some piece of code that already passed review, and then I'll notice a bug, because I'm already thinking about how that module should work -- I have already loaded the relevant context into my head. Loading that context just to do a code review takes too long.

vanusa 5y ago

Many timeless truths in this piece. Thanks for posting.

mcguire 5y ago

"Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer." There's a corollary to that: when you are working on someone else's code, don't restyle or re-architect to fit your vision. Don't even use your style or preferred architecture or design on your own additions; try to blend in with the rest of the code.

abotsis 5y ago

#9 took me years to realize. Even more when you have an idea, share it, someone who’s not in the corner takes it and runs with it. That experience is even more isolating because the immediate reaction is to just not share any more ideas. It took me even more years to master- because sure, not being in the corner is one thing, but getting out of it is another. It took a manager who listened to me and thrust me out to fix it.

monkeybutton 5y ago
>Even more when you have an idea, share it, someone who’s not in the corner takes it and runs with it. That experience is even more isolating because the immediate reaction is to just not share any more ideas. This! But I learned the lesson as the person who took the idea and ran with it. The "coworker in the corner" got pissed off and snapped at me one day in front of a few people. I wasn't the only one to have the experience and got to have an awkward conversation with our manager about having to walk on eggshells around certain coworkers. The end result was I didn't care what he worked on. Code reviews? Approved, no questions. Your ideas? Awesome, but you're on your own for getting them into production, bye. Don't be like that. You will suffer. You will know you are suffering too, when you compare yourself to your "lesser" peers who are getting more traction with their ideas while you become resentful.

541 5y ago

> You are not your code… As simple and important as this is for productive code reviews, I observed in my experience that it’s not as common a trait as one expects it to be. I can maybe attribute it to the stigma that is more deep rooted. In setups where rigorous code reviews are not norm, I notice, many if not most people, take the comments on their code as comments on self. Given how rampant this is at several workplaces, what ways/processes can be recommended to be adopted in such setups to have more productive, open and meaningful reviews and ease breaking the stigmas associated?

sverhagen 5y ago
It needs to be reinforced by the team, and not left up to the individual. A team or manager can encourage the behavior (even by just setting expectations at the time of hiring) and based on that, hopefully, some technical leaders are encouraged to lead by example. I also think it has to be part of a bigger strategy of egoless collaboration, and not hiring assholes.

ChrisMarshallNY 5y ago

I absolutely love that! Thanks so much for sharing it, and it was a great story.

amelius 5y ago

Sounds like a bunch of personality traits which are good to have in theory, but hasn't psychology taught us that you can't change personality even if you try very hard?

brianmcc 5y ago
None of these are personality traits IMO, they're more rules/guidelines. I don't think psychology has ever ruled on personality being immutable either. I mean, if you're reluctant to change, you probably won't do. But wanting to change is surely at least half the battle!
- throwaway984393 5y ago
  I don't know anything about psychology, but I know for sure I've changed my personality. The battle's not over yet, though...
mwattsun 5y ago
It's simpler than that. When a cop pulls you over you have a mental script for how to talk to the police. When some dude in a bar bothers you then you have a different script. When you are at work discussing your code with people, Dad and the ten commandments are suggesting you rewrite your script so you can be more effective and behave in an acceptable manner. They literally have Codes of Conduct now because some people don't know how to behave. They might be from a different culture, be differently mentally abled, etc... and need some guidance.

dang 5y ago

One past thread: Dad and The Ten Commandments of Egoless Programming (2012) - https://news.ycombinator.com/item?id=9203634 https://news.ycombinator.com/item?id=9203634 - March 2015 (75 comments)

skmurphy 5y ago

This article is a direct lift from https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/ https://blog.codinghorror.com/the-ten-commandments-of-egoles... the bulk of it is a verbatim copy of Atwood's summary without credit. These rules do not appear in this form or as a list of "10 commandments" in "Psychology of Computer Programming."

deleted 5y ago
[deleted]
pvg 5y ago
I assume you've read the book, what form, if any, do they appear in? I just skimmed through the text very superficially and didn't find anything that looked like these 'commandments'. Is the original Atwood post as iffy as this makes it seem or did I just miss relevant parts?
- skmurphy 5y ago
  I have read the book several times, Atwood offers more of a artistic interpretation of Weinberg's insights. It's no accident that no quote marks appear in his version.
  - pvg 5y ago
    Thanks, I suppose I'll read it myself to get a better idea of the degree of interpretation involved. There's a comment on the Atwood article which makes a point similar to yours above and Atwood's reply is very odd: https://discourse.codinghorror.com/t/the-ten-commandments-of-egoless-programming/825/27 https://discourse.codinghorror.com/t/the-ten-commandments-of... He seems to think these are, in part at least, quotes. And it's not just the "guy in the room" bit - when the commenter points out the book contains no 'commandments', Atwood doesn't say 'Oh, I just summarized it in list form'. He says he doesn't know where the text came from (?!). It's like the Atwood piece is itself derivative of something and it's not just the book and Atwood's own writing? Weird.
    - 5y ago

deleted 5y ago

[deleted]

ianbicking 5y ago

For a contrast on Egoless Programming: https://dawnproject.com/ https://dawnproject.com/ "THE DAWN PROJECT: Making Computers Safe for Humanity. We Demand Software that Never Fails and Can’t Be Hacked"

Twisol 5y ago
(EDIT: Oh, I whooshed myself pretty hard on this. "contrast on egoless", yes, absolutely >_<) > Dan leads The Dawn Project. He knows more about developing software that never fails and can’t be hacked than anyone else. He has designed, managed, or directly implemented all The Dawn Project technology and he makes all the decisions regarding technology development. The managers below Dan have been steeped in this technology for over 20 years. They know far more about software development than the people below them in the organization chart. And so on down to the lowest level. But even at that level, we have nothing but Special Forces class programmers. I... I can't find anything that's not simply boosting Mr. O'Dowd. This is clearly a B2B marketing website, not a technical resource. More power to them, but there's nothing here for outsiders. It's also kind of concerning that software like CompCert and seL4 isn't mentioned anywhere. Academic work in software verification is making steady progress; it feels really dirty to pose as the lone group that cares about this stuff. I don't really disagree with the ethical or factual material; there's just nothing actionable.
astrange 5y ago
Surely fighter jet software makes things less safe if it "never fails". Same for cars, an unsafe product by definition.

xupybd 5y ago

As a childless 37 year old it's a little worrying to hear 62 is old for a 22 year old son. I'd better hurry up.

mromanuk 5y ago
I had my first daughter at 35, my second daughter at 41. I'm 43 (male). A friend of mine had his first child at 47. Just two datapoint. Was common in the XX century to start having children at 20s, though.

thakoppno 5y ago

This reminds me a lot of the advice of John Perry Barlow. 1. Be patient. No matter what. 2. Don’t badmouth: Assign responsibility, not blame. Say nothing of another you wouldn’t say to him. 3. Never assume the motives of others are, to them, less noble than yours are to you. 4. Expand your sense of the possible. 5. Don’t trouble yourself with matters you truly cannot change. 6. Expect no more of anyone than you can deliver yourself. 7. Tolerate ambiguity. 8. Laugh at yourself frequently. 9. Concern yourself with what is right rather than who is right. 10. Never forget that, no matter how certain, you might be wrong. 11. Give up blood sports. 12. Remember that your life belongs to others as well. Don’t risk it frivolously. 13. Never lie to anyone for any reason. (Lies of omission are sometimes exempt.) 14. Learn the needs of those around you and respect them. 15. Avoid the pursuit of happiness. Seek to define your mission and pursue that. 16. Reduce your use of the first personal pronoun. 17. Praise at least as often as you disparage. 18. Admit your errors freely and soon. 19. Become less suspicious of joy. 20. Understand humility. 21. Remember that love forgives everything. 22. Foster dignity. 23. Live memorably. 24. Love yourself. 25. Endure.

Shared404 5y ago
I love this list. One clarification I would make: > 21. Remember that love forgives everything. We all need to remember that forgiveness does not mean acceptance, or trust, or that it means you need to interact with someone. It means that you let go of a grudge. This is an important note that took me a while to learn - forgiving is a gift to yourself, not the person you forgive.
yuuu 5y ago
the_cramer 5y ago
Is there any detailed explanation on these points? I only find this exact quoted list in my searches. Seems that the original was also only a list of these points. "Give up blood sport" - Why? Did martial arts for 10 years, helped a lot with some other points in these list, especially the self-awareness and decency (humble-ness?). Or do i misunderstand this point? "Live memorably" - That's straight up a wall tattoo quote, isn't it? /s

hk012022 5y ago

These are excellent skills and it would benefit both the developer and their team. In practice, it is very hard to follow them and emotions always overpower humans. The ability to keep them in control is everything.

astrange 5y ago

He came home and his dad printed out a list of random programming tips to discuss with his not-a-programmer son who then remembered them enough to write a blog post about it? Reads like a recipe intro.

deleted 5y ago

[deleted]

throwaway984393 5y ago

I like that most tips you find about being a better programmer have nothing really to do with programming, they're about being a better person.