Live data from Hacker News

Dad and the ten commandments of egoless programming (2012)

blog.stephenwyattbush.com

41–50 of 110 posts

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

#41
post #33

Earlier quoted context omitted.

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.

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

That's weird isn't it! In a quick search, I couldn't find any occurrence online of the phrase "Don't rewrite code without consultation", one of those commandments, earlier than Atwood's article. This[0] was the earliest other one I could find, from a few months after Atwood's, which says "What Weinberg wrote in that book was a set of guidelines for developers working in a team environment to keep their egos separate from their code. In fact, I think these 10 guidelines.." - but in the book, although Weinberg talks frequently about "egoless programming", I can't see any (isolated) principles or guidelines, much less a list of commandments. I can't find an online version of McCarthy's Dynamics of Software Development to check what's in that.

[0] https://www.techrepublic.com/article/the-ten-commandments-of...

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

#43
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…

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. Obviously how and when you point it out matters. Like in the middle of a user demo. "Why does it let me enter Feb 30th?" "Oh, Dave wrote the validation on that. What was your thought process on that one Dave?"

“Making sure our QA Department is worth their budget, Steve.”

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

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

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

#45
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…

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. Obviously how and when you point it out matters. Like in the middle of a user demo. "Why does it let me enter Feb 30th?" "Oh, Dave wrote the validation on that. What was your thought process on that one Dave?"

Why's there so many devs at a user demo?

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

#46
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…

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.

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.

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

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

I would never use "this should be changed", that would trigger 99% of devs with the same seniority.

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

#48
post #33

Earlier quoted context omitted.

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.

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

Sorry I was not clear. He is quoting generic noun phrases, these are not quotes from the "Psychology of computer programming."

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

#49
post #16

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?

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.

Post reply on HN