4 ms·

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

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 13y 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 13y ago
  I love the word "blamestorm" when any meeting starts to go that direction. As in "sweet, we're gonna blamestorm?"
  - j45 13y ago
    Totally. Blamestorming taps focus and ultimately progress towards "how it should be"
    - barbs 13y ago
      Wouldn't it be more efficient to focus on what's wrong with the code then, rather than whose fault it was?
      - StavrosK 13y ago
        It depends. Mistakes happen, sure, and you just say "it was a mistake, let's make sure we have the processes to catch it or avoid it next time and move on". However, when there's one guy who always keeps making mistakes and creating work for the rest of the team, even making the same mistake multiple times, then, in my opinion, some blame is warranted.
      - j45 13y ago
        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.
bhaumik 13y ago
Piggybacking off of this, have you observed unnecessary blame put on the intern(s)?
- dylandrop 13y 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 13y 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 13y 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 13y ago
  I agree to an extent. You can add comments to your code. Harder to do in a home.
  - cpfohl 13y ago
    Rational Documentation for home improvement projects, perhaps? Should come along with the manual for the microwave...
softbuilder 13y 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 13y 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 13y 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.

falsedan 13y 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 13y ago
I love the word "blamestorm" when any meeting starts to go that direction. As in "sweet, we're gonna blamestorm?"
- j45 13y ago
  Totally. Blamestorming taps focus and ultimately progress towards "how it should be"
  - barbs 13y ago
    Wouldn't it be more efficient to focus on what's wrong with the code then, rather than whose fault it was?
    - StavrosK 13y ago
      It depends. Mistakes happen, sure, and you just say "it was a mistake, let's make sure we have the processes to catch it or avoid it next time and move on". However, when there's one guy who always keeps making mistakes and creating work for the rest of the team, even making the same mistake multiple times, then, in my opinion, some blame is warranted.
    - j45 13y ago
      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.

bhaumik 13y ago

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

dylandrop 13y 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 13y 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 13y 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 13y ago
I agree to an extent. You can add comments to your code. Harder to do in a home.
- cpfohl 13y ago
  Rational Documentation for home improvement projects, perhaps? Should come along with the manual for the microwave...

softbuilder 13y 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 13y 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 13y 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.