All through school, whenever we screw up, we're punished. Eventually we internalize this punishing. We make unhappy faces and knot up our guts. The more our ambitions are thwarted, the more we beat ourselves up.
Then we have the great misfortune to become involved with computers. Merciless little passive-aggressive bastards, whenever we screw up they sit there like lumps. And we can't help screwing up. No one can program without making bugs.
Our response is naturally to beat ourselves up - to blame ourselves, kick ourselves, and generally arrange to feel bad. This doesn't help - in fact it makes the whole process of debugging into a kind of torture. Because it's stressful it's inefficient and time-consuming. And the more time we consume, the more we beat up on ourselves.
To work well with computers, to program confidently and debug efficiently, it's necessary to stop blaming yourself for bugs. Bugs happen. Debugging is a pleasant process that invariably and always reveals the bugs and resolves them. No matter how long it takes, eventually it works out. So relax - don't blame or beat yourself - and debugging will become a quick and painless thing. Enjoyable even. --Peter Merel
Agreed. On the best days we don't blame ourselves, but on the worst we do. Every once in a while you just have a bad day. Nothing is working out and the computer becomes just one more reminder of our frailty.
Is there a way of having the computer tell you that you are right more often then it tells you that you are wrong?
Yes. Use a testing frame and write loads of unit tests with it. Run as many of the tests as possible -- all, preferably -- every time you change something. You may very well find yourself distrusting the report of no bugs when that happens. I know I do. I occasionally find it necessary to deliberately introduce a bug to convince myself that the tests are working!'
All that isn't to say that the test don't find bugs; they do. But they also find that most of the code is working. And the parts that are deficient are usually quickly fixed. --Kiel Hodges
Yes, just so. In particular, don't blame yourself - but don't blame anyone or anything else either. Not the computer, not those other guys. No blame. Go to the problem as a puzzle, not an attack on your person. --Ron Jeffries
Wow, you guys seem to attach a LOT of emotion to the word blame. Blame Yourself First is not about beating anyone up - yourself and the machine included. Sure, each problem is a puzzle [or challenge - the company I work for frowns on the word problem in a nouvelle vague kind of way] but in solving a problem I look to what I've just done as a starting point before I start looking at other people's work.
--Paul Dyson
It's not just us, Paul, it's most people. "Blame" carries a connotation of
"deserving punishment".
Personally, I favor somewhat shocking names as they have great mnemonic value. The danger, however, is that some people may never see past the name. In such a case the mmemonic value is not there after all. I think that "blame" may be emotionally charged enough to be counter-productive. After all, communication has as much to do with the receiver as with the transmitter. Though you may intend one thing with "Blame Yourself First", many readers will see something else. --Kiel Hodges
I'm with both Paul and Kiel here. As a big proponent of names with shock value, I can hardly come out against them. At the same time, some folks may well respond poorly to words like "blame". Recall that on C3, we have an official person to blame. We have a card from Chet, signed, saying "It's my fault". One way you can use this is to say things like "OK, we know it's Chet's fault, but what caused this problem?" It reminds people to keep it light.
Where I have a problem with the no-blame thing is that every program defect I've ever seen was caused by a person, and if we don't drill down to see what that person did, and should have done, we can't improve. So I like to know who did it, and what happened. The C3 team doesn't agree with me on this. Probably I'm wrong. --Ron Jeffries
So, the big thing is to learn from the mistakes. Can we find out what a person did and what they should have done without identifying the person? Alternatively, does identification have to involve blame or other negative feelings? To me, an environment is healthy to the degree that people point out their own mistakes to their coworkers to help them learn. -- Michael Feathers
Sure, problems need to be tracked down and learned from, and sometimes the best way to deal with a problem is to deal with the person who caused it. But this isn't blame, and dealing isn't punishment; even if the best way to deal with the person is to hang 'em high, you do it with the most compassion and tenderness you can muster, and try to find a way for them to get something out of the deal too. Too often blame is something that gets in the way of effective dealing; perhaps Blame Yourself First should be Deal With Yourself First ... though that sounds a little auto-erotic ... --Peter Merel.
Who is Chet?
There's a cartoon which shows a nuclear power reactor, very busy, a wall full of read-outs and controls, guys in white coats all going about their work except for one chap. He's in a quiet corner, unshaven, reading a newspaper with a crate of beer beside him. The back of his chair reads "Fail Safe Man". On technician tells another, "If anything goes wrong, we can blame him." Was that Chet?
-- Dave Harris
Our Chet actually does work, but it's the same role.
See original on c2.com 