11–20 of 29 posts
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 immedi…
Earlier quoted context omitted.
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!
I love the word "blamestorm" when any meeting starts to go that direction. As in "sweet, we're gonna blamestorm?"
Earlier quoted context omitted.
I love the word "blamestorm" when any meeting starts to go that direction. As in "sweet, we're gonna blamestorm?"
Totally. Blamestorming taps focus and ultimately progress towards "how it should be"
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 rece…
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…
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…
One (of many) good things about collective code ownership is that this sort of blame game can't last very long.
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 rece…
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? :)
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…
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.
1. I make it a rule to fire the overrated jerks that (ca|wo|do)n't shape up, with poetic prejudice. 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.)
Earlier 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?
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.