The Ten Commandments of Egoless Programming (2006)

http://www.codinghorror.com/blog/2006/05/the-ten-commandments-of-egoless-programming.html

by bhaumik • 13 years ago

118 27 13 years ago

dylandrop2• 13 years ago

As for #10 -- "Critique code instead of people – be kind to the coder, not to the code" -- I find that in almost every place I've worked though, what happens is "that guy" who used to work there (or even the guy who didn't happen to show up to the office the day we found the bug) becomes the scape goat for the poorly written line. Interesting that we need to blame the problem on someone! Maybe that's just specific to where I've worked, but I think it might point to deeper problems.

falsedan• 13 years ago

Blame culture is easy, cathartic, and broken; deeply broken if you're in a situation where you can say, "this is solely their fault", then you've got an organization which assigns responsibility in excess of ability. Beware!

joelhooks• 13 years ago

I love the word "blamestorm" when any meeting starts to go that direction. As in "sweet, we're gonna blamestorm?"

bhaumik2• 13 years ago

Piggybacking off of this, have you observed unnecessary blame put on the intern(s)?

dylandrop2• 13 years ago

Well actually, for all of the places in question I was an intern myself. Most of the places I worked were small startups, so there weren't any intern predecessors (I was usually their first). Rather it was mostly the guy who hacked up version 1 of the code base who usually got the blame. Although who knows what happened when I left!

Bahamut• 13 years ago

Sometimes you want to know who was responsible for introducing a breaking issue into an app - the person would be in the best position to fix it.

dionidium• 13 years ago

This isn't unique to programming. Every home improvement project, for example, comes with a slew of complaints about the corners the last homeowner cut. It's just a lack of context. That previous person isn't around to explain why they made the choices they did. Meanwhile, the current guy always has a good reason for taking a shortcut and someday, someone else will complain about those choices in their absence.

dbough• 13 years ago

I agree to an extent. You can add comments to your code. Harder to do in a home.

softbuilder• 13 years ago

At my first programming job one of the senior programmers left and we started calling his code "Billyware". His code was hard to maintain (written in several different languages, none of which he'd mastered) but I suspect the real reason the name stuck was because he was kind of a jerk.

One (of many) good things about collective code ownership is that this sort of blame game can't last very long.

midas007• 13 years ago

0. Cowboy coders that change horses midstream should expect to get soaked.

1. I make it a rule to fire the overrated jerks that (ca|wo|do)n't shape up, with poetic prejudice. <Evil hand rubbing ensues> For the "indispensable" ones that cause too many problems, it's harder but possible. There's might be no such thing as an irreplaceable employee, the worse situation is losing good people that are pushed away. (Fan of Github / Rackspace cultural practices.)

fit2rule• 13 years ago

For me this is really the only value of this list, since it actually address the object of programming, rather than the individual themselves.

Any environment that thinks code is too valuable to change, alter, throw away, simply hasn't got a fully oiled production line going from Design -> Code -> Build -> Use. If there is code too valuable to change because 'nobody understands it' the problem isn't the code, its the people reading it.

But the problem is, people are people, and these days people talk a lot of shit about each other. Its 'normal'. Blame culture infects all human activity, it has been scripted so.

rf1331• 13 years ago

Number 7 is why I like programming so much

oldshit• 13 years ago

Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.

That's nice and all but don't let your boss hire multiple cheaper "developers" and expect you to train them. I've quit a job recently stating if I wanted to be a professor I would have accepted a job as one (and I have turned down one in the past).

eropple• 13 years ago

Part of a healthy developer culture is teaching. If you're not comfortable in that role, I hope you aren't applying for senior positions.

MaulingMonkey• 13 years ago

That's nice and all but don't let your boss hire multiple cheaper "developers" and expect you to train them.

I would avoid filling a company with too many learners and not enough teachers, but some teaching will generally be a necessity. The more they know:

- The fewer mistakes they'll make for me to run into, have to help clean up, or otherwise suffer

- The fewer mistakes of mine will go uncaught by their reviews, for me to run into, have to clean up, or otherwise suffer

- The fewer tasks will fall on my plate by necessity, giving me more flexibility in what I work on or when I take time off

And hey, cheaper hires means bigger potential raises, right? :)

jnazario• 13 years ago

i find that a phrase i started using some years ago has helped to drop my ego significantly. when asking for help, i phrase my question literally as "what am i doing wrong?" not "this is broken", no. "i'm trying to use X to do Y, here's how i'm trying to do that, and it's not working like i expected it to. what am i doing wrong?" in doing so, i assume the problem lies with me and my mistakes. it drops barriers immediately - both in myself and in others i'm asking of help - and forces me to be open minded about the solution.

a simple phrase but remarkably effective.

JoshTriplett• 13 years ago

Personally, I like to use "what am I missing?" for the same purpose.

maxk42• 13 years ago

Good advice, but terrible name. It takes a special kind of asshole to write "ten commandments" and imagine himself egoless.

bonobo• 13 years ago

Or perhaps you're misinterpreting him. I don't think there's a need to call the author a special kind of asshole, there's nothing there implying that he's referring to himself when saying egoless. At least the way I see it, being egoless is a goal to the reader, not the author's self description.

bhaumik2• 13 years ago

As founder of StackOverflow, I'd like to think he's been pretty helpful to the programming community.

NAFV_P• 13 years ago

"Treat people who know less than you with respect, deference, and patience." This should be applied across all aspects of life. It is a very obvious point, if you need to be told this there is something not right.

nammi• 13 years ago

Working with a team for the first time, I learned about #4. > Don't rewrite code without consultation. I would get anxious that others weren't pulling their weight and make significant changes, thinking that I was doing the team a favor. It really came off as controlling, disrespectful, and arrogant. They were doing their part, so I was actually creating more work for them. We later agreed to ask each other about their respective code before making changes, and never act before doing so.

The Ten Commandments of Egoless Programming (2006)

Related Stories