Good advice, but terrible name. It takes a special kind of asshole to write "ten commandments" and imagine himself egoless.
The Ten Commandments of Egoless Programming (2006)
21–29 of 29 posts
Re: The Ten Commandments of Egoless Programming (2006)
#22As 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…
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.
I agree to an extent. You can add comments to your code. Harder to do in a home.
Re: The Ten Commandments of Egoless Programming (2006)
#23Good advice, but terrible name. It takes a special kind of asshole to write "ten commandments" and imagine himself egoless.
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.
Re: The Ten Commandments of Egoless Programming (2006)
#24Good advice, but terrible name. It takes a special kind of asshole to write "ten commandments" and imagine himself egoless.
As founder of StackOverflow, I'd like to think he's been pretty helpful to the programming community.
Re: The Ten Commandments of Egoless Programming (2006)
#25Earlier quoted context omitted.
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.
I agree to an extent. You can add comments to your code. Harder to do in a home.
Rational Documentation for home improvement projects, perhaps? Should come along with the manual for the microwave...
Re: The Ten Commandments of Egoless Programming (2006)
#26As 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…
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.
Re: The Ten Commandments of Egoless Programming (2006)
#27"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.
Re: The Ten Commandments of Egoless Programming (2006)
#28Earlier quoted context omitted.
Totally. Blamestorming taps focus and ultimately progress towards "how it should be"
Wouldn't it be more efficient to focus on what's wrong with the code then, rather than whose fault it was?
Very few things are as black and white as pregnancy.
When solving a problem starts by blaming someone, it can distract the conversation and attention to become about personalities, positions, politics, arguing over perceptions, & interpretations, instead of the problem itself.
If, after something like the 5 why exercise, all roads keep leading to someone, one can probably look at having a positive supportive intervention.
If that person doesn't want it or feel they need it? That's more of a culture thing than just about one person.
Re: The Ten Commandments of Egoless Programming (2006)
#29Working 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.