What's a forgivable mistake?

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 717790

    Comments posted to this topic are about the item What's a forgivable mistake?

  • Jeff Moden

    SSC Guru

    Points: 995976

    I've got mixed emotions here.  First, I do agree that the best of us will make mistakes.  No question about that.

    But that's also why we have certain procedures at work and those procedures also include some checks and balances.  "Urgencies" and "Emergencies" all follow the exact same procedure as all of the normal stuff except that we have people standing by to accelerate the steps in the process.

    "The Process" we follow has prevented us from making many mistakes and, don't forget, you'll make the most mistakes when you can least afford to and that's when there's an emergency.

    With that in mind, there is something pretty much unforgivable at work and that's when someone doesn't follow the established, documented, buttered and breaded, very well known process.  That doesn't happen anymore, either.  We're pretty close to zero defects being deployed to production and we haven't deployed even a missed defect in well over 2 years or so.

    It DOES take teamwork,  though.  Even in previous companies I worked for, we were doing what people are calling DevOps long before it became a term (current company employment started after that).

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • BrainDonor

    SSCoach

    Points: 19214

    I worked at a place where the slightest mistake was met with derision, shouting and a generally abusive atmosphere. On the last day of my probation period I pulled the rip-cord - forever thankful that the probation works both ways. I was one of four DBAs that left during that period (and it was a small team). An utterly toxic atmosphere.

    Where I work now there are still mistakes occassionaly made. However, there is no 'blame game' - admit to what you've done and the issue it has caused and there are follow-up meeting to work out how to change processes that will reduce the possibility of such things happening again. It makes people more willing to discuss potential issues and ask for assistance. Oddly enough, staff retention is far better here.

    People make mistakes and it's how they (and others) deal with those mistakes that matters. Deliberate efforts to quietly bypass processes and then hide any issues should still be punishable to some degree - that isn't a mistake, it is deliberate behaviour.

    Steve Hall
    Linkedin
    Blog Site

  • Michael L John

    One Orange Chip

    Points: 25887

    BrainDonor wrote:

    I worked at a place where the slightest mistake was met with derision, shouting and a generally abusive atmosphere. On the last day of my probation period I pulled the rip-cord - forever thankful that the probation works both ways. I was one of four DBAs that left during that period (and it was a small team). An utterly toxic atmosphere.

    Where I work now there are still mistakes occassionaly made. However, there is no 'blame game' - admit to what you've done and the issue it has caused and there are follow-up meeting to work out how to change processes that will reduce the possibility of such things happening again. It makes people more willing to discuss potential issues and ask for assistance. Oddly enough, staff retention is far better here.

    People make mistakes and it's how they (and others) deal with those mistakes that matters. Deliberate efforts to quietly bypass processes and then hide any issues should still be punishable to some degree - that isn't a mistake, it is deliberate behaviour.

     

    I work at a place that is quite the opposite.  Essentially, you need to murder someone to get fired.  In the past 4 weeks, we have had 11 complete outages of every damn system in the company because their are folks who keep making changes to our infrastructure.

    We get whoops, I caused it. Sorry.

     

    Michael L John
    If you assassinate a DBA, would you pull a trigger?
    To properly post on a forum:
    http://www.sqlservercentral.com/articles/61537/

  • Doctor Who 2

    SSCertifiable

    Points: 7764

    I've made the mistake of implementing a spec wrong. Simply put, I misinterpreted it. If there's some confusion on what a spec says, then I've asked for clarification, more than once, on a spec to get it right. But when I'm sure I understand something, but only later discover I've misinterpreted it, I don't know how you can prevent that. 95% of the time I interpret the spec right, its that 5% where I'm certain I've understood it and later discover I didn't that I don't think anyone can prepare for.

    Rod

  • Thom A

    SSC Guru

    Points: 98563

    This is somewhat sweeping, but I think the biggest mistake you can make is making a mistake and then not admitting you made that mistake (and further more hiding it). There have been a number of times this year where we found problems on a system, where someone had made a mistake, realised it, covered it up (poorly) and not fixed the route cause (causing more problems later on), and as we didn't know about the mistake it took a lot longer to fix when it became a much bigger problem.

    That member of staff learned their lesson the hard way, after doing that multiple times; they aren't with the business any more.

    We all make mistakes, yes, but provided you admit it early, and help fix the issue, then they can often be forgivable. Mistakes are far easier to fix and resolve when people are transparent about them. Hiding them just makes them worse.

    Thom~

    Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.

  • David.Poole

    SSC Guru

    Points: 75308

    I think you have to make the distinction between decisions and outcomes.

    A decision that was correct at the time it was made may have a disastrous outcome and the decision is interpreted as a mistake.  Martin Lewis of MoneySavingExpert gives the example of people who chose to a fixed rate mortgage just before interest rates collapsed.  The decision was good because at the time people were making the judgement that they needed financial predictability.  The fact that they ended up paying more than people on variable rates was a bad outcome but there was no way to know that interest rates were going to crash at the time the decision was made.

    I think a lot also depends on the quality of management and also the personalities involved.  A good manager tries to be impartial, a bad one either has favourites or is simply unobservant.  I know of one person who tried to see their boss several times over a 2 month period.  Some time around month 4 their boss asked why that person hadn't attended an important meeting that the boss had emailed them to attend.  Turns out that at the end of month 2 that person had put in their 1 month resignation in writing in the bosses in tray where it was found gathering dust 2 months later.

    There are some people whose behaviour and results are such that others cannot understand why they are still employed.  Then there are others who seem to be harshly judged for relatively minor misdemeanors.

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 717790

    Doctor Who 2 wrote:

    I've made the mistake of implementing a spec wrong. Simply put, I misinterpreted it. If there's some confusion on what a spec says, then I've asked for clarification, more than once, on a spec to get it right. But when I'm sure I understand something, but only later discover I've misinterpreted it, I don't know how you can prevent that. 95% of the time I interpret the spec right, its that 5% where I'm certain I've understood it and later discover I didn't that I don't think anyone can prepare for.

    This is why I'm a testing advocate. Document what you think with simple test cases. Then if there's a question or issue, you can show what you thought easily. Or you can send the simple cases to someone else to have them look at the goes-inta and goes-outta.

     

Viewing 8 posts - 1 through 8 (of 8 total)

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