Live data from Hacker News

Dad and the ten commandments of egoless programming (2012)

blog.stephenwyattbush.com

21–30 of 110 posts

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

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

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.

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

#22

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

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?

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

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

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

#24
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 LOVE this frame of mind and I love this statement but it is usually only used in the negative alignment of expectations: don't take critique personally.

No disagreement. But let's get pedantic:

The umbrella "you are not your code" would dismiss improvement as well. And praise.

Ok, so I am not my code. But if I don't learn from my mistakes my code will not improve.

I... I... I...

Anyway, I much prefer to reframe it this way:

Programming is a very intimate experience.

The same as creating art. It is the manifestation of your thoughts and opinions, small and large, put out in to the world. So sure, don't be offended by critique. But also remember to extend some grace when doing a review.

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

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

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!

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

#26
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 think I'd have nodded and read on a couple years ago when I'd only had thoughtful/well-informed/diversely-experienced developers review my code. I've learned since that it's also possible to have your code reviewed by someone without particularly deep understanding (nor awareness of what they lack), who would insist that responding to a critique of (what they think is) a problem is essentially being argumentative because they are certain they've already got the 'correct' answers (in a similar way that a first year philosophy student might think they've already got the answers).

> ... they are stuck in an endless loop of making mistakes and refusing to learn from them

I am probably overfitting to my own recent experience, but to me, while this could be a legitimate problem with the reviewee, sounds equally plausibly like a red flag on the part of the reviewer: someone who has settled into a set of "correct" answers and now sees other people not adopting their personal outlook on code as a failure to learn.

It is not a simple matter to (definitively, non-subjectively) find a 'problem' once the criteria become anything more nebulous than "does it produce the correct result".

There's an analogous situation I've noticed in more casual conversations: someone is describing a problem they have or a situation they're in, and the person they're speaking to keeps smugly offering "solutions" that only sound good because they haven't listened closely to the other person, took a superficial glance and assumed the issue was some common one and so offered a facile/common solution—and then don't understand why the other person isn't appreciative.

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

#27
post #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…

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

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

#28
post #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 work…

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.

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

#29
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 think I'd have nodded and read on a couple years ago when I'd only had thoughtful/well-informed/diversely-experienced developers review my code. I've learned since that it's also possible to have your code reviewed by someone without particularly deep understanding (nor awareness of what they lack), who would insist that responding to a critique of (what they think is) a problem is essentially being argumentative b…

Yeah, the person who thinks a mistake is "you aren't writing the code my way" in itself is an ego trap. A lot of programmers get trapped in their viewpoint and think everyone should write code like them because it would make more sense to them if everyone did, when it isn't objectively better.

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

#30
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?"

Post reply on HN