Live data from Hacker News

Dad and the ten commandments of egoless programming (2012)

blog.stephenwyattbush.com

11–20 of 110 posts

Re: Dad and the ten commandments of egoless programming (2012)

#11
post #3
post #2

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.

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.

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.

Re: Dad and the ten commandments of egoless programming (2012)

#12
#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.

Re: Dad and the ten commandments of egoless programming (2012)

#13
> 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?

Re: Dad and the ten commandments of egoless programming (2012)

#14
post #5

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 som…

"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.

Re: Dad and the ten commandments of egoless programming (2012)

#18
post #10
post #8

Earlier quoted context omitted.

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.

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

Re: Dad and the ten commandments of egoless programming (2012)

#19
This article is a direct lift from 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."

Re: Dad and the ten commandments of egoless programming (2012)

#20

This article is a direct lift from 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]
Post reply on HN