Live data from Hacker News

Dad and the ten commandments of egoless programming (2012)

blog.stephenwyattbush.com

91–100 of 110 posts

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

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

Good point about also extending some grace when doing a review. In my experience insensitive and unnecessary, pedantic and overall shitty critique is a much bigger issue and I'd rather see people push back more on it actually.

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

#92

Earlier quoted context omitted.

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…

> The umbrella "you are not your code" would dismiss improvement as well. And praise. I don't see why you think this is the same thing. Improvement in someone's coding skill is good from a business/colleague/project perspective. And from a "practice paid off" perspective. And positive feedback is always good to give, you certainly shouldn't only give negative feedback. But you shouldn't get too attached to your code…

I agree. People are not robots, this is just silly. You'd never get a good effective team by taking this extreme stance that nobody ever has any feelings about their work.

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

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

It all depends on the delivery. Criticising someone's work is sensitive and you need to consider this. My number one problem is always that not enough positive feedback is given, you work really hard and make a great solution to a really important problem, give it to the team, and all you get back is someone aggressively and stubbornly picking on it for minor details.

It's just a really negative attitude, you go to see the Sistine Chapel with someone, and the only thing they have to say about it is that there was a crack in the ceiling, and just repeat that the crack should be fixed. Would that not affect your experience?

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

#94

Earlier quoted context omitted.

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.

Human nature. Some people will use code review as a stick to beat you with or an opportunity to show how clever they are.

Yep, and this is unfortunately the rule more than the exception, and somehow part of STEM culture

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

#95

Earlier quoted context omitted.

An earlier article from techrepublic written in 2001: https://www.techrepublic.com/article/egoless-programming-the... This is the earliest google hit for "Ten Commandments for egoless programming". Curiously, the author, Lamont Adams, does not explicitly state that the commandments are from the book. Maybe "I present The (Almost) Ten Commandments for egoless programming" means that it's a summary by Adams?

Oh thanks! Yeah, seems Adams may well be the originator. p.s. I just wrote to him now asking about this! Maybe the truth will surface...

I think a plausible explanation that fits all the bits and pieces is that Adams wrote this as a kind of riff of his own, inspired by the concept of 'Egoless Programming'. At some later point Atwood ran across some version of the 'commandments' list, thought they were quotes from the book and wrote his blog post. Thinking they were quotes, he probably didn't feel the need to cite where he found them. It's just a somewhat silly mistake, it happens - although it inadvertently spawned a mighty stream of Internet Wrongness.

He should have probably updated and corrected the blog post when someone pointed out his mistake to him in 2016. He probably still should.

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

#96

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

Uh okay. Pls tell me how to deal with, negligence, incompetence, lack of work ethic, complete disregard for other people's time and work.

I have been Jesus like up until now, but that's only led me to end up with the shit end of the sick, managing people who do less than me , while making more money than me. I've been grinding so hard( for my own selfish gain) that when deadlines creep these people feel okay to slack, and turn in shit code, cuz they know me or of the other guys will pick is up. Meanwhile they get time to schmooze and work ok side degree or something and when promotions come around they get em cuz they are "more experienced" and now have better credential s.

I really think it's time to change my ways.

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

#97
post #87

Earlier quoted context omitted.

In HN formatting you need newline for paragraph lists: 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 deli…

> Avoid the pursuit of happiness. Seek to define your mission and pursue that. Someone is going to need to explain to me why focussing on being happy is a bad idea. My historic view was "I'd rather chase being content and comfortable" as it's less of a sugary high and more of a stable base. However - I do not think that is what is being said here?

What he means is to avoid making hedonism your only goal in life, but to have some goal beyond that...

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

#98
post #72
post #18

Earlier quoted context omitted.

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…

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

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.

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

#99
post #42

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.

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.

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

#100

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

Uh okay. Pls tell me how to deal with, negligence, incompetence, lack of work ethic, complete disregard for other people's time and work. I have been Jesus like up until now, but that's only led me to end up with the shit end of the sick, managing people who do less than me , while making more money than me. I've been grinding so hard( for my own selfish gain) that when deadlines creep these people feel okay to slack…

Honestly, some work environments are just shit. If you don't have a sizeable stake (co-founder), start looking around.

If however you find the same situation repeatedly at different jobs, then you're either 1) too critical, 2) your ego falsely wants to believe no one else is working as hard, or 3) would rather run your own show. Worst case scenario it's #3 because running your own show is hard, exhausting, fun, etc. and you'll never be happy working for someone else.

Post reply on HN