14 ms·

Dad and The Ten Commandments of Egoless Programming (2012)

272 points by dodders 12y ago

pjmorris 12y ago
Always good to see Jerry Weinberg's work mentioned. I tried reading 'The Psychology of Computer Programming' when I was in college, it didn't grab then. Finally read it 15 years later, and realized that the material there would've especially helped in my first couple of jobs. Also... my dad was 45 when I came along. I didn't get to spend much time with him before he was gone, but every moment was valuable and is cherished. I still try to make him proud, and suspect your dad would be proud.
sporkenfang 12y ago
When I read things like this, it strikes me particularly that my dad is one of those rocket people the author is talking about. I'm glad he's done what he has to put things in space so that maybe someday people can go places other than the Earth on a slightly more than part-time basis. All dad-boosting aside, this is a brilliant list, and I'm glad to have it, OP!
digi_owl 12y ago
Something for everyone in that.
deleted 12y ago
[deleted]
greenyoda 12y ago
Jerry Weinberg wrote those "commandments" in 1971. (It's sad that the article gives a link to his book but never mentions his name.) It's interesting how well they've kept their relevance over the years, despite the huge changes in the practice of programming. However, we who do the programming still keep on forgetting these things and need to be periodically reminded of them.
kbwt 12y ago
This has been posted before. A moderator might want to add (2012) to the title.
- dang 12y ago
  Thanks, we added that. Reposts are fine on HN when a story hasn't had significant attention in the last year or so. https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html
mfisher87 12y ago
I have these on display at my desk. I've always wanted to know how to encourage cultural adoption? What are the arguments against these rules? There must be some. My reasoning about these rules is that they derive from the idea that as teams of programmers, we're professionally motivated (and being paid) to produce the highest possible quality results. To that end, these rules compensate for human biases and faults to maximize quality. Many of the practices you've read about some companies enforcing, such as "there are no bad ideas" or "no stupid questions" can be related back to these rules under the same reasoning. None of us do a perfect job of compensating for our human faults and biases, so some rules help to improve our performance. My dad also passed away very early, soon after I finished college, and I credit him for making these rules so easy to follow.
- dasmoth 12y ago
  > What are the arguments against these rules? There must be some. I don't actually find this set terribly objectionable, at least when they're treated as guidelines rather than rules, but I'll have a go anyway. Excessive focus on issues like this is seen as a symptom of a managerialist culture. While few developers I know would object to the ideas that everyone has something to learn, and that apprentice and journeyman coders should be supported and encouraged, there is -- sometimes justified -- suspicion that the real agenda is to commoditise developers and turn programming from a craft into a factory-floor activity. Or, to refer to another article that's on the front page this morning, to turn antiwork into work. The kind of things that get put in place to "compensate" for ego are rules which value maintenance over re-writes, and third party components (even if they're only a tenuous fit for the problem) over in-house development. While I agree that there are biases to be aware of here, dismissing every proposal for a re-write or new internal development as egotism ends up shutting down discussions about the actual trade-offs.
  - mfisher87 12y ago
    >While I agree that there are biases to be aware of here, dismissing every proposal for a re-write or new internal development as egotism ends up shutting down discussions about the actual trade-offs. I'm not sure how this behavior could be attributed to any of these rules. Could you elaborate further?
danso 12y ago
The best part of this list is that with some tweaks, the commandments can pretty much apply to any field of personal and professional pursuit. One rule I might add (and one that is also easy to apply elsewhere): Remember that far more time will be spent reading your code than writing it. Grokking this not only has practical implications for how you write code (suddenly, the importance of style guides becomes clearer), but it makes you realize that this is how projects get built: programmers re-using libraries that contain encapsulated, clear functionality. Realizing that someone has to read your code -- even if that someone is mostly just you -- requires a modicum of empathy...and more often than not, this aids in the design process. A common complaint about learning via something like Codecademy is that you might learn the syntax and how to solve problems...but you don't get much guidance on how to apply that knowledge to real projects. I think part of this is because with Codecademy, you're only writing code for the auto-checker to compile and test. Once you start writing code for humans to comprehend and re-use, it becomes easier to see how code becomes a real-world project.
raverbashing 12y ago
It seems to me this list, while having positive ideas, reeks of condescendence. it's mostly about how you are "much better than everybody, that's why you have to play cool with everybody" What is missing is a healthy dose of "why do you think your ideas are better than everybody else's?" Readability is mostly subjective. Code quality, maintainability, etc, are mostly subjective as well. So don't give me that BS "I'm just trying to get the best code possible" when it's your opinion Sure, I'm not saying that something like xx = strinvcatpfr(yy * zky_eng) can't be improved, but beyond a certain point it's mostly about taste and endless nitpicking
- mhomde 12y ago
  I wouldn't say that those things are "mostly" subjective, that sounds like a defensive argument. I'm pretty sure there are good objective metrics both for readability and maintainability, they might not be the only aspects but calling it subjective is going too far. For instance maintainable code could be said to minimize side effects, be somewhat modularized and be as compact as possible while being readable. I find it hard that anyone could claim the opposite and be right "as a matter of taste"
  - raverbashing 12y ago
    "I'm pretty sure there are good objective metrics both for readability and maintainability, they might not be the only aspects but calling it subjective is going too far." I think you explained better what I mean. I'm not denying the good objective metrics (for example, one of the aspects would be following Pep8 in Python) But beyond that it's mostly about subjectivity. So, evaluate on the objective metrics as much as possible, but don't waste my time saying that "A is better than B" when it's mostly a subjective aspect
    - i_s 12y ago
      This is very true. My brother just told me about a class he took on C# in which the teacher gave him a C on an assignment because of 2 things: 1) he had a using statement that reached far into a library, and 2) he used the "var" keyword. The program was correct otherwise.
greggman 12y ago
> Critique code instead of people – be kind to the coder, not to the code A fellow co-worker taught me by example to try to always phrase each code review comment as a question. Instead of > This loop never terminates Write > Does this loop terminate? Instead of > There's no test for this condition write > Is there supposed to be a test for this condition? I'm probably not thinking of good examples but for some reason, more often than not, the direct comments came across as "you screwed up!" where as the questions instead made it feel like I was discovering my own mistakes rather than have someone tell me I made one. It's probably subtle and maybe some people will think it's dumb but I really appreciated it. It felt like it went a long way toward me feeling like saw my own mistake and fixed it before I checked it in instead of the direct approach which made me feel stupid and embarrassed. I've tried to adopt that approach (though it's a struggle to remember to apply it).
- mhomde 12y ago
  "Are you out of your mind???" ;) But in all seriousness, projecting issues as character flaws is a really destructive thing to do, not just in programming but in any relationship. It's a really good habit to avoid it whenever possible. I read somewhere (I think it was Blink) that marriage counselors could tell which marriages would fail by observing those that generalized around their spouses character rather arguing about the issues, ie "You always..."
  - mwfunk 12y ago
    Siracusa said something similar on Accidental Tech Podcast a while back, and it really struck me because it made me look back on every argument I've ever had in a different light. He said he always phrased disagreements in such a way as to leave the person he was disagreeing with out of it. In general, always voice disagreement as "the thing you said is wrong" rather than "you're wrong". The former is about the point of disagreement, the latter is about the person. It's not even about being diplomatic or being less likely to hurt someone's feelings (although you get that for free), it's really just about clarity as to what's being discussed. The most confident, secure person in the world might still get defensive when confronted with "you're wrong", because there's still a whiff of it being about questioning that person's credibility, as opposed to the thing that you think they're wrong about.
Animats 12y ago
The trouble with egoless programming is that you don't get promoted.
- saraid216 12y ago
  Which is perfect. We can Peter Principle away the egotistical programmers.
- Joeri 12y ago
  Not true in my own case. I believe that being appointed team lead was a direct result of applying egoless programming principles.
  - Consultant32452 12y ago
    Is "team lead" a real position defined by HR that comes with a pay raise higher than whatever the most senior dev title is? If it is, that's awesome. I've never actually seen that in any place I've worked. It's always more responsibility without pay, which I consider a net negative.
- thothamon 12y ago
  I don't think egolessness means not participating or taking the lead. See the point about not being the programmer who only comes out of the office for soda. If you take the lead and deliver good results, you can definitely be promoted, especially if you have good social skills. Also, people definitely notice when developers work on their own time to improve their skills. They may not say anything, but they notice, and that translates to promotions.
- bcg1 12y ago
  I think that this assertion is not quite unlike correct.
- EdwardDiego 12y ago
  Depends on your employer. At mine, people who can work well with other developers and help the team get better overall are very much noted, appreciated and rewarded. But our culture has always been about the team, not individual developers.
Almaviva 12y ago
Am I really that rare that I treasure people above all others who will speak to me directly if they don't like something? With the themes in this article and others like it, are they how you should behave if you want to meet your own goals, or about how people you're subordinate to prefer you behave, in order to not rock the boat too much?
- Joeri 12y ago
  Egoless programming is about accepting that you are flawed, your knowledge is flawed and your work is flawed, and then drawing appropriate conclusions from that. That's how you get to "critique code, not people", because everyone is flawed, and almost all work is flawed, so there's no point blaming people for their flaws. The focus should be on the flaw and how to get rid of it, not the person whose flaw it is. You are indeed rare for being able to take direct criticism of your work and respond in a constructive way.
- mwfunk 12y ago
  The thing is, EVERYBODY thinks this about themselves by default, not just you. Nobody is sitting there thinking that they wish people would just sugarcoat everything for them and be as passive-aggressive and indirect as possible. Likewise, everybody probably feels like they have to be this way when interacting with other people, and that that can be burdensome sometimes. It can be very, very different when you're actually in that situation though, and your boss is giving you the Torvaldsing that you always thought you wanted. If there is even a teensy part of you that thinks your boss is a jerk, or that they don't respect you, or that you know more about whatever it is that they're Torvaldsing you about, that part of you is being given a golden opportunity to assert itself really hard. Maybe it will, maybe it won't, but it's human nature and why spark the flint if you don't have to. I thought I was completely immune to this kind of defensiveness for most of my life, and it wasn't until I got into my 40s that I realized that it was always there. Another way of looking at is, what is gained by being as blunt as possible, as opposed to the rules in this article? I'd say nothing. Nothing recommended here makes communication any more ambiguous or time-consuming. In fact it's about being more clear about what exactly you are discussing.
  - 12y ago
dllthomas 12y ago
'No matter how much “karate” you know, someone else will always know more.' As stated, there is always at least one person for whom this is not true. However, even for such a person it is likely the case that there are still people who know things they don't, and the rest of 3 continues to hold: 'Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.'
a3n 12y ago
I agree with everything on this list, but in case someone takes things too literally, I would change this: Fight for what you believe, but gracefully accept defeat. to this: Advocate for what you believe, but gracefully accept defeat. Sometimes "fighting" for what you believe can turn in to just fighting.
pvaldes 12y ago
I came here only for the promise of elves typing a keyboard at superfast pace...
pvaldes 12y ago
I came here only for the promise of elves typing a keyboard at full speed pace... (no elves and now I feel sorry for his dad, great)
phprocks 12y ago
Highly recommend picking up the book (The Psychology of Computer Programming) I have a low attention level, and one of my favorite things about this is you can really jump around and pick up the chapters from anywhere. Also despite the title of the book, its actually a very light and entertaining read.
datashovel 12y ago
Great list. When I first became involved in programming as a career, I got this unexpected and uneasy impression that people in the industry (extrapolated from my real-world experiences early in my career) were generally passive aggressive about how they handled conversations about code and how they agreed or disagreed with others about how the code should "be". I think those groups of people would have benefited greatly from this list. Simultaneously it would have prevented alot of the angst I experienced as a young developer.
toolslive 12y ago
'''Don't feel a "winner" when having corrected, don't feel a "loser" when having been corrected, and banish all feelings of mutual competition.''' http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD683.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EW...
UserRights 12y ago
A little late to the party, but I would like to ask: is there still some research going on in the areas of psychology and programming? Not AI, but how the state of the programmers mind affects collaboration, the quality of the code and the general outcome of projects? Any hints and links would be very appreciated, thanks! Have a nice sunday!

272 points by dodders 12y ago

Always good to see Jerry Weinberg's work mentioned. I tried reading 'The Psychology of Computer Programming' when I was in college, it didn't grab then. Finally read it 15 years later, and realized that the material there would've especially helped in my first couple of jobs. Also... my dad was 45 when I came along. I didn't get to spend much time with him before he was gone, but every moment was valuable and is cherished. I still try to make him proud, and suspect your dad would be proud.

sporkenfang 12y ago

When I read things like this, it strikes me particularly that my dad is one of those rocket people the author is talking about. I'm glad he's done what he has to put things in space so that maybe someday people can go places other than the Earth on a slightly more than part-time basis. All dad-boosting aside, this is a brilliant list, and I'm glad to have it, OP!

digi_owl 12y ago

Something for everyone in that.

deleted 12y ago

[deleted]

greenyoda 12y ago

Jerry Weinberg wrote those "commandments" in 1971. (It's sad that the article gives a link to his book but never mentions his name.) It's interesting how well they've kept their relevance over the years, despite the huge changes in the practice of programming. However, we who do the programming still keep on forgetting these things and need to be periodically reminded of them.

kbwt 12y ago

This has been posted before. A moderator might want to add (2012) to the title.

dang 12y ago
Thanks, we added that. Reposts are fine on HN when a story hasn't had significant attention in the last year or so. https://news.ycombinator.com/newsfaq.html https://news.ycombinator.com/newsfaq.html

mfisher87 12y ago

I have these on display at my desk. I've always wanted to know how to encourage cultural adoption? What are the arguments against these rules? There must be some. My reasoning about these rules is that they derive from the idea that as teams of programmers, we're professionally motivated (and being paid) to produce the highest possible quality results. To that end, these rules compensate for human biases and faults to maximize quality. Many of the practices you've read about some companies enforcing, such as "there are no bad ideas" or "no stupid questions" can be related back to these rules under the same reasoning. None of us do a perfect job of compensating for our human faults and biases, so some rules help to improve our performance. My dad also passed away very early, soon after I finished college, and I credit him for making these rules so easy to follow.

dasmoth 12y ago
> What are the arguments against these rules? There must be some. I don't actually find this set terribly objectionable, at least when they're treated as guidelines rather than rules, but I'll have a go anyway. Excessive focus on issues like this is seen as a symptom of a managerialist culture. While few developers I know would object to the ideas that everyone has something to learn, and that apprentice and journeyman coders should be supported and encouraged, there is -- sometimes justified -- suspicion that the real agenda is to commoditise developers and turn programming from a craft into a factory-floor activity. Or, to refer to another article that's on the front page this morning, to turn antiwork into work. The kind of things that get put in place to "compensate" for ego are rules which value maintenance over re-writes, and third party components (even if they're only a tenuous fit for the problem) over in-house development. While I agree that there are biases to be aware of here, dismissing every proposal for a re-write or new internal development as egotism ends up shutting down discussions about the actual trade-offs.
- mfisher87 12y ago
  >While I agree that there are biases to be aware of here, dismissing every proposal for a re-write or new internal development as egotism ends up shutting down discussions about the actual trade-offs. I'm not sure how this behavior could be attributed to any of these rules. Could you elaborate further?

danso 12y ago

The best part of this list is that with some tweaks, the commandments can pretty much apply to any field of personal and professional pursuit. One rule I might add (and one that is also easy to apply elsewhere): Remember that far more time will be spent reading your code than writing it. Grokking this not only has practical implications for how you write code (suddenly, the importance of style guides becomes clearer), but it makes you realize that this is how projects get built: programmers re-using libraries that contain encapsulated, clear functionality. Realizing that someone has to read your code -- even if that someone is mostly just you -- requires a modicum of empathy...and more often than not, this aids in the design process. A common complaint about learning via something like Codecademy is that you might learn the syntax and how to solve problems...but you don't get much guidance on how to apply that knowledge to real projects. I think part of this is because with Codecademy, you're only writing code for the auto-checker to compile and test. Once you start writing code for humans to comprehend and re-use, it becomes easier to see how code becomes a real-world project.

raverbashing 12y ago

It seems to me this list, while having positive ideas, reeks of condescendence. it's mostly about how you are "much better than everybody, that's why you have to play cool with everybody" What is missing is a healthy dose of "why do you think your ideas are better than everybody else's?" Readability is mostly subjective. Code quality, maintainability, etc, are mostly subjective as well. So don't give me that BS "I'm just trying to get the best code possible" when it's your opinion Sure, I'm not saying that something like xx = strinvcatpfr(yy * zky_eng) can't be improved, but beyond a certain point it's mostly about taste and endless nitpicking

mhomde 12y ago
I wouldn't say that those things are "mostly" subjective, that sounds like a defensive argument. I'm pretty sure there are good objective metrics both for readability and maintainability, they might not be the only aspects but calling it subjective is going too far. For instance maintainable code could be said to minimize side effects, be somewhat modularized and be as compact as possible while being readable. I find it hard that anyone could claim the opposite and be right "as a matter of taste"
- raverbashing 12y ago
  "I'm pretty sure there are good objective metrics both for readability and maintainability, they might not be the only aspects but calling it subjective is going too far." I think you explained better what I mean. I'm not denying the good objective metrics (for example, one of the aspects would be following Pep8 in Python) But beyond that it's mostly about subjectivity. So, evaluate on the objective metrics as much as possible, but don't waste my time saying that "A is better than B" when it's mostly a subjective aspect
  - i_s 12y ago
    This is very true. My brother just told me about a class he took on C# in which the teacher gave him a C on an assignment because of 2 things: 1) he had a using statement that reached far into a library, and 2) he used the "var" keyword. The program was correct otherwise.

greggman 12y ago

> Critique code instead of people – be kind to the coder, not to the code A fellow co-worker taught me by example to try to always phrase each code review comment as a question. Instead of > This loop never terminates Write > Does this loop terminate? Instead of > There's no test for this condition write > Is there supposed to be a test for this condition? I'm probably not thinking of good examples but for some reason, more often than not, the direct comments came across as "you screwed up!" where as the questions instead made it feel like I was discovering my own mistakes rather than have someone tell me I made one. It's probably subtle and maybe some people will think it's dumb but I really appreciated it. It felt like it went a long way toward me feeling like saw my own mistake and fixed it before I checked it in instead of the direct approach which made me feel stupid and embarrassed. I've tried to adopt that approach (though it's a struggle to remember to apply it).

mhomde 12y ago
"Are you out of your mind???" ;) But in all seriousness, projecting issues as character flaws is a really destructive thing to do, not just in programming but in any relationship. It's a really good habit to avoid it whenever possible. I read somewhere (I think it was Blink) that marriage counselors could tell which marriages would fail by observing those that generalized around their spouses character rather arguing about the issues, ie "You always..."
- mwfunk 12y ago
  Siracusa said something similar on Accidental Tech Podcast a while back, and it really struck me because it made me look back on every argument I've ever had in a different light. He said he always phrased disagreements in such a way as to leave the person he was disagreeing with out of it. In general, always voice disagreement as "the thing you said is wrong" rather than "you're wrong". The former is about the point of disagreement, the latter is about the person. It's not even about being diplomatic or being less likely to hurt someone's feelings (although you get that for free), it's really just about clarity as to what's being discussed. The most confident, secure person in the world might still get defensive when confronted with "you're wrong", because there's still a whiff of it being about questioning that person's credibility, as opposed to the thing that you think they're wrong about.

Animats 12y ago

The trouble with egoless programming is that you don't get promoted.

saraid216 12y ago
Which is perfect. We can Peter Principle away the egotistical programmers.
Joeri 12y ago
Not true in my own case. I believe that being appointed team lead was a direct result of applying egoless programming principles.
- Consultant32452 12y ago
  Is "team lead" a real position defined by HR that comes with a pay raise higher than whatever the most senior dev title is? If it is, that's awesome. I've never actually seen that in any place I've worked. It's always more responsibility without pay, which I consider a net negative.
thothamon 12y ago
I don't think egolessness means not participating or taking the lead. See the point about not being the programmer who only comes out of the office for soda. If you take the lead and deliver good results, you can definitely be promoted, especially if you have good social skills. Also, people definitely notice when developers work on their own time to improve their skills. They may not say anything, but they notice, and that translates to promotions.
bcg1 12y ago
I think that this assertion is not quite unlike correct.
EdwardDiego 12y ago
Depends on your employer. At mine, people who can work well with other developers and help the team get better overall are very much noted, appreciated and rewarded. But our culture has always been about the team, not individual developers.

Almaviva 12y ago

Am I really that rare that I treasure people above all others who will speak to me directly if they don't like something? With the themes in this article and others like it, are they how you should behave if you want to meet your own goals, or about how people you're subordinate to prefer you behave, in order to not rock the boat too much?

Joeri 12y ago
Egoless programming is about accepting that you are flawed, your knowledge is flawed and your work is flawed, and then drawing appropriate conclusions from that. That's how you get to "critique code, not people", because everyone is flawed, and almost all work is flawed, so there's no point blaming people for their flaws. The focus should be on the flaw and how to get rid of it, not the person whose flaw it is. You are indeed rare for being able to take direct criticism of your work and respond in a constructive way.
mwfunk 12y ago
The thing is, EVERYBODY thinks this about themselves by default, not just you. Nobody is sitting there thinking that they wish people would just sugarcoat everything for them and be as passive-aggressive and indirect as possible. Likewise, everybody probably feels like they have to be this way when interacting with other people, and that that can be burdensome sometimes. It can be very, very different when you're actually in that situation though, and your boss is giving you the Torvaldsing that you always thought you wanted. If there is even a teensy part of you that thinks your boss is a jerk, or that they don't respect you, or that you know more about whatever it is that they're Torvaldsing you about, that part of you is being given a golden opportunity to assert itself really hard. Maybe it will, maybe it won't, but it's human nature and why spark the flint if you don't have to. I thought I was completely immune to this kind of defensiveness for most of my life, and it wasn't until I got into my 40s that I realized that it was always there. Another way of looking at is, what is gained by being as blunt as possible, as opposed to the rules in this article? I'd say nothing. Nothing recommended here makes communication any more ambiguous or time-consuming. In fact it's about being more clear about what exactly you are discussing.
- 12y ago

dllthomas 12y ago

'No matter how much “karate” you know, someone else will always know more.' As stated, there is always at least one person for whom this is not true. However, even for such a person it is likely the case that there are still people who know things they don't, and the rest of 3 continues to hold: 'Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.'

a3n 12y ago

I agree with everything on this list, but in case someone takes things too literally, I would change this: Fight for what you believe, but gracefully accept defeat. to this: Advocate for what you believe, but gracefully accept defeat. Sometimes "fighting" for what you believe can turn in to just fighting.

pvaldes 12y ago

I came here only for the promise of elves typing a keyboard at superfast pace...

pvaldes 12y ago

I came here only for the promise of elves typing a keyboard at full speed pace... (no elves and now I feel sorry for his dad, great)

phprocks 12y ago

Highly recommend picking up the book (The Psychology of Computer Programming) I have a low attention level, and one of my favorite things about this is you can really jump around and pick up the chapters from anywhere. Also despite the title of the book, its actually a very light and entertaining read.

datashovel 12y ago

Great list. When I first became involved in programming as a career, I got this unexpected and uneasy impression that people in the industry (extrapolated from my real-world experiences early in my career) were generally passive aggressive about how they handled conversations about code and how they agreed or disagreed with others about how the code should "be". I think those groups of people would have benefited greatly from this list. Simultaneously it would have prevented alot of the angst I experienced as a young developer.

toolslive 12y ago

'''Don't feel a "winner" when having corrected, don't feel a "loser" when having been corrected, and banish all feelings of mutual competition.''' http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD683.html http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EW...

UserRights 12y ago

A little late to the party, but I would like to ask: is there still some research going on in the areas of psychology and programming? Not AI, but how the state of the programmers mind affects collaboration, the quality of the code and the general outcome of projects? Any hints and links would be very appreciated, thanks! Have a nice sunday!