Egoless Programming (2011) | Hacker News Reader

Egoless Programming (2011)

wiki.c2.com

103 pointsmerikh45 comments

The concept of course was Jerry Weinberg's in The Psychology of Computer Programming (1971). I always felt like that book should have had a different title. Maybe "Computer Programming as a Human Activity", which is what he said it was about in the preface: http://wiki.c2.com/?ThePsychologyOfComputerProgramming. The concepts of the book are more social than psychological, as I recall. Even "egoless programming", which is psychology in the sense of looking at how we identify with our ideas, is also about interactions on teams.

I have grown into this, and strive to keep it.

Early on on my career, the products I made were an extension of me. Bugs were an insult, design critiques a personal attack. The code was precious and deleting large swathes of it unthinkable.

The consequences? I was probably not that easy to work with, and my software wasn't as good as it could be.

Nowadays I'm proud of what I create, and I enjoy the act of creation. But nothing delights me more than someone (can be me, can be others in the team) taking a hatchet to large chunks of what we've produced, I value criticism of approach and I need people to find faults and bugs to help me deliver a better product. My focus has entirely shifted from "I produce intricate works of art" to "let's find the simplest, most robust way to deliver what my client needs"

Code is a means, not an end.

How ironic that reading this, I jumped to the Errors of TeX link, something I've read parts of in the past, and then found myself wondering was I in that file?

I am.

This is a really excellent comment.

Well done!

  888 Make it easier to change the format extension (Don Hosek). §520, 1328 P

This doesn’t resonate with me, because so much of programming is craftsmanship. Often the only purpose of some aspect of programming that matters is that I made it. I crafted it. The design that exists matters because I made it. I didn’t pay someone else to do it. I didn’t copy it. I made it. The act of making it is very fundamental.

I think it would be similar to artwork. There’s no such thing as egoless art making. It’s literally the product of the artist.

Programming is a creative act and requires substantial creative mental force. Anytime we are creative, we are putting ourselves out there and making ourselves vulnerable. This naturally causes us to be defensive. The ego connotation misses the root of the problem. We are defensive only because of our insecurities in our identities, not the identity itself. The code we write is an expression of our identity. I find it similar to an artist that paints a portrait and immediately gets critiqued.

Being able to take this criticism without feeling that it is an attack on your expression of yourself is a skill that is learned. I think it only comes from one or both of two things: 1) realizing that you are expressing yourself and that some may find it useful and others won't and be okay with that or 2) be in an environment that doesn't immediately judge your production. I find the latter scenario to be the building block for the former.

In any creative venture, there needs to be an environment of acceptance of failure. If people are comfortable with failing, then they will succeed.

> The act of making it is very fundamental.

Yep, and you can stop after that. Process is the only important thing. After that you'd better to distinguish you and your program/design. It's mere artifact without value.

The built artifact is the evidence of the act of making.

"Treat your software like livestock, not like pets" - random HN comment that stuck with me as a beautifully visceral metaphor.

To get an index of all C2 wiki pages

      curl https://proxy.c2.com/wiki/remodel/pages/ > 1.html

To get a wiki page in JSON and convert it to textfile without using gratuitous Javascript

Optional: feed through fmt(1)

      curl https://proxy.c2.com/wiki/remodel/pages/EgolessProgramming|tr -d '\n'|sed 's/ *//;s/{ \"date\": \"//;s/ \"text\": \"//;s/\",/\
   /
      s/\. :)//;s|\\r\\n\*|\
   \
   \*|g
      s|\\r\\n|\
   |g
      s/'''//g; s/''//g;s/\\\\"/"/g;s/\\"/"/g;s/\\t//g;s/ ://g;s/  */ /g;s/\" }$//' > 1.txt

To search the wiki

      curl https://proxy.c2.com/cgi/fullSearch/?search=$1|sed 's|href=wiki.|href=https://proxy.c2.com/wiki/remodel/pages/|g' > 1.html

why not just click on the link? - seems more work to run this

Also appears quote missing in second code block

Why not just serve plain HTML pages like C2 wiki used to do. Why use Javascript and Google Analytics. Why ask why.

Fact: It took more work for someone to convert the HTML to JSON, write the Javascript and set up the proxy than it did for me to write a shell script.

Not sure what were the benefit(s) to that person versus the one-time cost of switching away from plain HTML to requiring Javascript. No doubt he deemed it worth the time to set up.

What I do know is the benefit to me versus the one-time cost of writing a shell script. It means I do not need to use Javascript or submit to Google Analytics. I do not even need internet access once I have downloaded the C2 wiki, converted it to text and stored it on local media. If it one day disappears from the web and the IA, I still have a copy. This wiki is a piece of history and it is not changing.

Apologies for the error with the quotes. Here is a fix

cat > 1.sed

      s/ *//;s/{ //;s/ \"date": \"//;s/. \"text\": \"//;s/)//;s/\",/\
   /;s/ )//;s|\\r\\n\*|\
   \
   \*|g;s|\\r\\n|\
   |g;s/'''//g;s/''//g;s/\\\\"/"/g;s/\\"/"/g;s/\\t//g;s/ ://g;s/  */ /g;s/\"}$//

   curl https://proxy.c2.com/wiki/remodel/pages/EgolessProgramming|tr -d '\n'|sed -f 1.sed > 1.txt

This is one of the best pieces of advice I've read in a while!

I've talked with my teammates about this topic before, but I've struggled to put it so well. This article (or a book chapter?) is a very nice nexus between psychology, philosophy and programming best practices for collaboration.

Coding Horror republished the ten commandments from the Gerald Weinberg book (any book he's written is worth reading by the way) mentioned in this article:

https://blog.codinghorror.com/the-ten-commandments-of-egoles...

One of the things I love most about my current job is that at some point the whole team has been through the codebase, and no one owns anything. In fact, any one in the team would be hard pressed to tell who wrote what in the first place, even if they themselves did it.

The result is that anything that needs fixing or improving is simply fixed, no questions asked, no feelings hurt. Once code review approves it it goes back into the communal codebase that we all maintain equally, with all credit shared.

At some point, I've gotten to a place where I see it as a bad smell if you can tell a team member's code apart from the rest.

Weird article:

> The idea is that programmers must fight the natural tendency to treat their programs as part of themselves, and therefore to reject all criticism.

This seems to suggest that the author believes people have a natural tendency to reject all criticism of themselves, and that the programs they help build are just an extension of that. In that case, why single out programs? OTOH I could be interpreting that completely wrong; most of that page seems to be about various definitions and interpretations.

I have experienced this in myself, and other people many, many times.

I still get a little pinch inside when someone sits down to examine my work.

Especially since I work with a very wide range of technology, so I never really feel I'm dealing with something I've 'mastered'.

edit - spelling

A perfect example of why humans are so strange. Our default human response could have been wired to be "i can't possibly feel bad when criticized, because i know i'm not a master" and "i love having people examine my work, because it's a shortcut to getting better even faster", but instead we take all the wrong lessons.

This is true when I perceive the examiner as more knowledgable but more often than not I perceive them as less knowledgable and ignorant. This can both be true, that they are less knowledgable and ignorant, and that it's wrong of me to assume so. Often it comes from the belief, based on my perceived tone of the examination, that the other person believes they are the expert and are correcting me, the noob. So, feeling perceived as a noob feels disrespectful, especially given a topic for which I'm an expert. That in no way means I shouldn't grow and welcome all examination. But I'm not the Dalai Lama. I'm a normal flawed human being who gets upset when they feel insulted. It will probably take me a lifetime to get better at not feeling insulted. In the meantime, when I remember, I try to couch my examinations of other's code in ways that will hopefully not make them feel insulted.

Based on dunning-kurger, you would expect everyone who is less knowledgable than you to actually think that they are more knowledgeable, so you could say that they are acting with somewhat honest intentions in their attempt to correct you. But then this also acts in the opposite direction as well, in that you might think you are more knowledgeable because you are, but you might also think it because you aren't. So, how do you know if you are "right" to be insulted? You probably would need multiple orders of magnitude difference to be sure, but that's very rarely the case. That is to say, it's probably best to be charitable with my interpretations of others.

I feel often the issue ends up that I am more knowledgeable than the other, but only slightly more, so my instinct says that they are off. However, I can't express it well enough, because I can't absolutely describe all the circumstances in which their advice is correct, and all the circumstances in which their advice is not, and then prove why it's not applicable in this specific case. If I could do so, I'd explain it fully, there would be no complaint from the other, and it'd be a great teaching moment. So then maybe such situations where someone is trying to correct me, but I can't give an absolute response back indicates a gap in my self-held expertise.

And either way, experts can learn insights from those who are noobs (though often not in the way that the noob intended).

You don't normally see expressed introspection like this on hacker news. It was kind of cool, and a weird feeling to read this.

> Our default human response could have been wired to be "i can't possibly feel bad when criticized, because i know i'm not a master" and "i love having people examine my work, because it's a shortcut to getting better even faster", but instead we take all the wrong lessons.

This would not be practical nor evolutionary advantage in practice. Saying that as someone who used to believe the above is something to strive for.

It makes you super vulnerable the moment politics appear or when you work and are judged among peers. Among other things, if you welcome and accept criticism while others dont, you will appear less capable to third parties because your mistakes are constantly pointed out and theirs are not. Impression matters. You will be more likely to be convinced you are wrong when you are right or when difference is matter of opinion. You wont be perceived as potential leader.

You will also be getting a lot of bad advice from overly confident people. They will be perceived as more capable then you, even if you realize the advice was wrong. People with hardwired do end up nitpicked and favorite target of those who like dominate others. Which is why such trait is not evolutionary advantage, even if it would be collectively helpful.

Hmm, I kind of see that as a completely separate category -- how I manage my perception within the organization, how I manage relationships and influence, how I present myself, what I say in what situations.

Accepting criticism to me seems like a more internal thing. There's of course the external response to criticism. People will always say whatever they want, so then, do you dismiss it? do you get angry and lash out? do you try to turn it into a teaching moment? do you try to spin it into something else to make people feel like they contributed?

I don't know if accepting criticism means I would be convinced that I am "wrong" when I am "right". Let's say, in some meeting where we're trying to come to some solution, I generally try to frame it as "let's work together to solve this problem". Certainly you have your own thoughts on what the solution would be, or at the very least some instinct on the direction, based on your experience. So then everyone is laying out their thoughts and opinions, and you try to build upon the facts, try to get consensus on points, until you reach the end goal. Of course, it's up to your own skill to metagame the conversation to get people to come to your own solution by their own, usually by enumerating all the approaches, enumerating their strengths and weaknesses, and letting others tally up the points in your favor. Or maybe through the process the group ends up with a better solution than you had originally come in with, which will almost always be the case on some level. It's not a matter of "the expert is correct and we do whatever they say".

Of course, with things like opinions, if it doesn't matter, it's often not worth arguing about, and if it does, there should be concrete evidence in its favor. You might also choose to allow for suboptimal solutions. Let's say we all agree on the overall approach in the meeting, but the person who's going to be implementing the project has a particular opinion on a detail of the approach. Your experience says it's not quite the perfect approach, but not that bad and still meets the bar, you might let them go with that, because it gives them more motivation, lets them feel more ownership, it's something they're more familiar with, etc. The people and team aspect is often more important to optimize than the "technically optimal" solution.

I would also treat the confidence aspect as something else entirely. You present your confidence by having strong well-thought-out and evidence-backed ideas. You make sure that you've always thought more deeply about the issue and are more prepared than anyone else in every meeting. And that you are always sharp to understand, incorporate, and build upon everyone else's ideas. Actually, I might say that this confidence is what allows you to learn and improve from other's criticism, without feeling attacked and beat down by it.

Robert Kegan's Constructive-Developmental Theory could be useful in understanding this.

It basically defines an evolving relationship between Subject (what one is) and Object (what one has).

Criticism targeted at objects (what one perceives) is tolerated. Criticism targeted at the subject (what one is) is frequently a source of stress.

For example, criticism towards one's religion elicits different reactions if the religion is part of Subject (what one is) versus if the religion is Object (what one has).

The same with programming, if the piece of software gets entangled with one's identity, criticism of the software becomes criticisms targeted at one's identity and losing a piece of identity is akin to dying. For someone who only views software as objects, the reaction of a person that has their identity entangled with the software would appear blown out of proportion.

There's definitely a good number of people that are extremely reluctant to cede ground of any kind, including accepting criticisms of themselves.

Why single out programs? Cause it’s a website about programming.

If Egoless Programming is powerful, imagine what we could do with Egoless Living!

Anyone try 'becoming one with the computer' when programming?

Seems to compress/clarify modelling & managing complexity sometimes.

Can you elaborate on what do you mean by 'becoming one with the computer'? My understanding is that you mean that we should put some assumptions aside and try to look from the CPU point of view, which can be helpful for debugging, testing, design, etc. Am I right? edit: spelling mistake

If nobody gets the credit, who gets the raise?

If everyone is getting their due nobody needs a raise.

Of course, if everyone is getting their due, companies cannot grow.

Everyone always needs a raise

Nobody

Reply on news.ycombinator.com