Dude, Your Fly is Open

  • In a public forum like SSC, I think it is more important to correct errors in the thread directly than to worry about someone’s feelings. The damage that can be done by poor practices being accepted unchallenged and released into the wild is far worse.

    However, being professional and courteous in criticism is always appropriate, whether in public or private. If you criticize someone in private in an inappropriate manner, you can hurt their feelings just as much as public criticism.

    At the same time, you have to be professional enough to accept criticism and not treat it as a personal attack.

  • Good article, Tim.

    Thanks.

  • We here have a team mascot of Fozzie Bear from the Muppets. He sits on the desk of whoever messed up last. We've even attached a bicycle horn that is honked when he moves desk.

    While humiliating, it serves a purpose of hammering in the need for discipline in following procedures and being aware of the consequences of ones actions.

  • Daniel Hallam (2/25/2010)


    We here have a team mascot of Fozzie Bear from the Muppets. He sits on the desk of whoever messed up last. We've even attached a bicycle horn that is honked when he moves desk.

    While humiliating, it serves a purpose of hammering in the need for discipline in following procedures and being aware of the consequences of ones actions.

    Totally inappropriate. This is just completely wrong. You KNOW you are humiliating people... your "team" must hate you.

    Wayne
    Microsoft Certified Master: SQL Server 2008
    Author - SQL Server T-SQL Recipes


    If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!
    Links:
    For better assistance in answering your questions
    Performance Problems
    Common date/time routines
    Understanding and Using APPLY Part 1 & Part 2

  • Michael Valentine Jones (2/25/2010)


    In a public forum like SSC, I think it is more important to correct errors in the thread directly than to worry about someone’s feelings. The damage that can be done by poor practices being accepted unchallenged and released into the wild is far worse.

    However, being professional and courteous in criticism is always appropriate, whether in public or private. If you criticize someone in private in an inappropriate manner, you can hurt their feelings just as much as public criticism.

    At the same time, you have to be professional enough to accept criticism and not treat it as a personal attack.

    Here is an interesting case:

    http://www.sqlservercentral.com/Forums/Topic873721-145-1.aspx

  • A useful and interesting editorial.

    I think there may be a cultural difference between the two sides of the pond, or maybe between two different kinds of company.

    In my experience people have generally been a bit less sensitive than the editorial suggests. Most places we would have team meetings to discuss progress and problems, and people would make suggestions about problem fixes - and it wouldn't matter if your suggestion was completely nuts, because it might spark someone into spotting the answer. Team leaders and managers made mistakes too, often real howlers. Generally people were not embarrassed by mistakes, even for mistakes that led to roars of laughter. Everyone know we were a team and cared about each other - and I guess that's what it needs.

    Even apart from team meetings, I often found that correcting mistakes in private was pretty pointless: if I took someone aside to explain an error they would generally go back to the rest of the team and tell them, beginning with something like "You'll never guess what an idiot thing I did, thank heavens Tom spotted it before it went into the system" - same if anyone else pulled someone aside to point out an error - everyone would soon know because that's the way the teams worked. Maybe the silliest mistake I ever made was to allow some design to go through into product without first using proper queuing theory to check the likely response delays (I'd done top of the head guessing, always a dangerous thing with communicating processes): my boss took me aside for that one, and suggested I look up some elementary queuing theory stuff. The next Monday I walked into the office where the people who owned the affected code were and said something like "Listen up guys, I've fucked up and we are going to have to redo all the interrupt handling; and we have to do it soon enough that we can ship it as an upgrade before any customers get enough workload onto their systems to be hit by the problem"; then I explained what the problem was, what needed to be done to fix it, apologised for having allowed them to waste time testing a guaranteed to fail on heavy workloads method, promised to fight for better test gear so that next time we could test heavy workloads, and told them I was off to see the boss to expliain that my mistake had wasted a lot of their effort. I wasn't embarrassed, but I was really bloody annoyed with myself. The team didn't think any less of me because I'd screwed up big - they knew that they could screw up too. I learned from my error - I quickly became a real expert on queuing theory and discrete event simulation using stochastic methods, and that was a big gain.

    I guess it's a different culture if people are so embarrassed to have made mistakes that their embarrassment upsets them, more than their annoyance with themselves for having lost the ball, so much that they are discouraged from working rather than encouraged to increase their knowledge so as not to make similar mistakes again - a culture that I would hate to work in.

    I do believe that some mistakes should be handled in private - but this doesn't include trivial programming errors (trivial mistake doesn't neccessarily mean trivial consequences). For example if someone decided that bubble sort would be OK to sort a million strings with a 5 sec response time requirement I would not make that public, unless making it public becaame the only way to stop it happening.

    Maybe Daniel Hallam's Fozzie Bear was a bit over the top, or maybe not: it depends on the team dynamics. I've worked in teams that had similar customs, spent my share of time with the Fozzie Bear equivalent on my desk, and it didn't bother me or anyone else. One guy I worked for kept a pile of cards with "Attaboy" and another pile with "Aw Shit" printed on them, and used to hand them out as appropriate at management meetings. I earned my share of both (once got an Attaboy cancelled by an Aw Shit in about 15 seconds: got the first by explaining that my team had completed development and test of all specified work for the next release, and the second by adding that there were still 3 outstanding requirements that were so vague we couldn't begin to specify them). No-one was ever embarrassed by getting the wrong king of card - why should they be?

    I've known a couple of managers who would whinge and moan and go on and on about peoples mistakes, calling them incompetent and/or lazy and spending a lot of time being as nasty as they could. I've never had a jot of respect for that approach (in fact I've had a lot of disrespect for it) and it is certainly counter-productive. But going to the opposite extreme and lot letting any mistakes be known and discussed by the whole team - well, to me that means you don't trust your team to support each other, and in that case what on earth did you hire them for in the first place?

    Tom

  • Too right Tom! You have to trust the team to be mature enough to enjoy the infantile mechanisms for reasonable and professional purposes. It's crazy but it works because we are humans NOT the androids a lot of HR departments want to treat us as.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Tom.Thomson (2/28/2010)


    ....I often found that correcting mistakes in private was pretty pointless: if I took someone aside to explain an error they would generally go back to the rest of the team and tell them, beginning with something like "You'll never guess what an idiot thing I did, thank heavens Tom spotted it before it went into the system" - same if anyone else pulled someone aside to point out an error - everyone would soon know because that's the way the teams worked.....

    Far from pointless, I'd say that's quite the opposite. Not only do people have the confidence their criticism will be taken the right way, but also when criticised people get the opportunity to control when, how and if that criticism goes public. And to top that, it seems everyone seems secure enough as team members to be content with their mistakes being known. It doesn't matter which angle you use to view it, that's an impressive culture to have developed.

    Semper in excretia, suus solum profundum variat

  • Tom.Thomson (2/28/2010)


    ...The next Monday I walked into the office where the people who owned the affected code were and said something like "Listen up guys, I've fucked up and we are going to have to redo all the interrupt handling...

    One of the most important things you can do is to admit your own mistakes. It you say “I messed up”, it gives people confidence that you won’t try to hide embarrassing mistakes and they will trust you more.

    One time I had a boss come to see me to complain about a mistake in a stored procedure, and I could tell by his red face that he was really mad. I think that he was expecting that I was going to deny there was a problem and to really yell at me. I shocked him when I said that I messed it up and had already fixed it. He was left very angry but with nothing to really yell about.

  • I tend to find that the Open Errors Policy is the best. When you have that kind of culture no error is hidden, a given error gets added to various lists; errors to manage correction, errors to evaluate why they occurred, errors to inform users of (and workarounds for) etc.

    The same goes for errors reported by users. When a user reports an error there definitely exists an error somewhere. It may or may not be a programming/data flaw but if not, it is an error in something like documentation, training or clarity of application UI.

    Hiding mistakes is counter to this culture. It detracts from the feeling that everyone is working together to achieve something. Wearing a silly hat is just a bonus!!!

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 10 posts - 31 through 39 (of 39 total)

You must be logged in to reply to this topic. Login to reply