
Dad and The Ten Commandments of Egoless Programming (2012) - dodders
http://blog.stephenwyattbush.com/2012/04/07/dad-and-the-ten-commandments-of-egoless-programming
======
greggman
> 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).

~~~
saraid216
I feel obligated to mention that this strategy, while it often works to some
degree, sometimes doesn't work. For people like me, phrasings like that sound
passive-aggressive.

I prefer the strategy of wrapping my sentences in things like, "I think" or "I
prefer".

So, I'd write, "This loop doesn't seem to terminate." or "I think that this
condition needs a test." It's an implicit admission that I could be wrong and
an invitation to push back. Just as often, I'll walk over and say, "Could you
explain why you did that to me?" This is especially acceptable when it's
agreed that a good review requires the reviewer understand what's going on.

~~~
AlyssaRowan
I feel the way I communicate has been influenced strongly by voice training -
I've noticed in particular I say "I feel" a lot in similar circumstances.
(Apparently, valuing emotions above thought is some paragon of femininity? I'm
not sure I agree with that.)

I am reluctant to go for the direct "wtf?!" response, because as above, it
bruises egos and people get defensive - and that is unhelpful to actually
resolving issues. I tend to phrase it as "Perhaps I'm confused, but...". (One
advantage of this is that sometimes, I _am_ wrong, and this gives someone an
opportunity to explain why, and in the process hopefully re-examining their
thought process and testing it just in case.) I think I caught that pattern,
as well as excessive usage of "though", from a good friend. One interpretation
of this is that perhaps I've spent nigh-on 2½ decades being confused. <g>

There is, however, a place for the genuine WTF. I reserve it for "there's no
way you could be that stupid" situations, like someone cheerfully telling me
about the 256-bit encryption they used, and my discovering it's RSA-256.

The management-by-Perkele has however seemed to work to keep the Linux kernel
clean up 'til now, although they don't really want to _insult_ people.

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

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

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

------
mfisher87
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
> 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
>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?

------
sporkenfang
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!

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

~~~
Joeri
Not true in my own case. I believe that being appointed team lead was a direct
result of applying egoless programming principles.

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

------
dllthomas
_' 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.'_

------
Almaviva
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?

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

~~~
Bahamut
There are different approaches to being direct - one can be brutally blunt
while still having the recipient maintain dignity. I prefer this approach in
general - the trick is if the person does not take it well, then you stress
that it is not personal, or meant that they are necessarily a bad developer.

It is shocking to be on the receiving end, but it forces the person to think
about it more and internalize it better. I have seen it give great results for
people's subsequent code, including my own. The developers have all thanked me
for it and feel the approach has helped them grow immensely.

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

------
datashovel
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
'''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/EW...](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD683.html)

------
UserRights
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!

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

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

~~~
dang
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)

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

------
digi_owl
Something for everyone in that.

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

