Dad and the ten commandments of egoless programming (2012)
blog.stephenwyattbush.com
Dad and the ten commandments of egoless programming (2012)
1–10 of 110 posts
Re: Dad and the ten commandments of egoless programming (2012)
#2This 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.
Re: Dad and the ten commandments of egoless programming (2012)
#3This 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.
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.
Re: Dad and the ten commandments of egoless programming (2012)
#4I'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
[2] https://www.goodreads.com/book/show/66354.Flow
[3] https://news.ycombinator.com/item?id=29950740
[4] https://news.ycombinator.com/item?id=22821447
[5] https://www.google.com/books/edition/The_Psychology_of_Compu...
Re: Dad and the ten commandments of egoless programming (2012)
#5I 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.
Re: Dad and the ten commandments of egoless programming (2012)
#6Many timeless truths in this piece. Thanks for posting.
Re: Dad and the ten commandments of egoless programming (2012)
#7For 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.
Re: Dad and the ten commandments of egoless programming (2012)
#8For 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.
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)
Re: Dad and the ten commandments of egoless programming (2012)
#9"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.
Re: Dad and the ten commandments of egoless programming (2012)
#10For 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.
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)
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.