What do you do when you make a mistake?

  • Comments posted to this topic are about the item What do you do when you make a mistake?

  • What do I do when I make a mistake?  Own it.  I first let the right people know that a mistake was made and what it affected.  I also let them know I'm working on a fix or that I need some help making the fix. 

    I don't normally make mistakes, though... It's not that I'm some sort of genius that doesn't make mistakes.  Nah... nothing quite so arrogant.  My secret is that I follow the same rules that I laid out for everyone else.  I submit to a design review not only by the users involved but by peers, the SME on whatever I'm working on, etc..  I submit to a code/peer review just like everyone else.  I develop and test in dev and have someone else deploy my reviewed code to QA (we have the rule that no one promotes the code they wrote and the auditors absolutely love it).  The same goes for staging and production.  We all do the same thing and if it's a production "urgency", then the same thing happens but at a greatly accelerated rate (sometimes in as little as 10 minutes depending on the problem).  If the fix can only be tested in prod, we do so on a hardware snapshot of the database that we have ready to rock at the drop of a hat... any hat.

    The 2nd to the bottom line is 1) no matter who caused the problem, I'll jointly own it with the person that made the mistake or own it entirely if I'm the one who made the mistake and then 2) time proven procedures are expedited by 3) people that are rehearsed at 4) following the procedures/rules and 5) doing their job.

    The bottom line is that because we all work as a team (me, the devs, QA, the window/infrastructure folks, the users, and the managers), it's a very rare thing for any of us to deploy a problem to production.  The auditors like the fact that we can prove all of that with documentation we enter in the ticketing system, source control, and the code itself.

    --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.

    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)

  • Peacefulness and calm are always appropriate. Best say little for a short while until I've mentally adjusted. 'Hmm, interesting, let me take a look.' may be my only response for a short while until I / we can authoritatively come up with a sensible response. It's sensible to take the heat off other employees where possible, when a team member's error is responsible (of course if it is yours) - everyone wins in that scenario, they feel supported, you come over well. Steps to avoid in the future is the next thing.

  • We have our code reviewed within the team and it is amazing how often little mitsakes (ahem) get through. When that is not an option, I leave it until the next morning when a fresh pair of eyes will see things that I hadn't seen the day before. We don't always have squiggly read underlines to help us. I can and do freely admit to mistakes on my/our part now, because it is the fastest and easiest way to get a problematic situation resolved. I/we were the cause of the problem, we will resolve it as soon as we can. I am likewise more tolerant of people who forget to send me attachments in e-mails, people who send me scripts with errors in them, clients who forgot a vital requirement for a task. Mistakes work both ways.

    In the past though, I learned never to admit mistakes because the penalties were high. If a mistake had been discovered, one denied it or simply kept quiet. This was the company culture and no one wants to be a pariah. It took many years in another company to learn to be able to freely admit that I had made a mistake.

  • I always tell folks that recognizing your own mistakes is important because it doesn't really  count as a mistake if you spot and fix your own before anybody else notices.

    And if you can't fix it before it becomes noticeable, people will still tend to give you credit for working on fixing instead of denying.

  • One of the things I learned from my father is "Bad news gets worse with age."

    When you make a mistake, I agree with all that has been said about owning it - just make sure you own it quickly, and that anyone affected by your error gets notified as soon as is practical.

    Sometimes it makes sense to take enough time to do analysis of the impact, so that you can provide the whole story - but never delay out of embarrassment or fear - that just makes it worse.

    That said, if at all possible, try to propose a solution along with your 'confession' - or at least suggest next steps for dealing with the fallout. Bonus points if you are proposing to do the hard parts yourself!

  • I own up straight away. There was one time I briefly thought I'd taken out a live trading system, and my blood ran absolutely cold but I went and told my manager straight away. (Fortunately it turned out that it wasn't me, but I must have aged 20 years that morning.) I got credit and credibility for owning up. As others have said, it really depends on where you work. If there's a toxic workplace culture, then owning up my not be the smartest move.

  • An honest mistake is a good mistake, because it is a learning opportunity. When you own up to it, you learn from it, you learn how not to make it again, you get better. Deny it, and you will be no better tomorrow than you are today. I wrote about this on this very website a little while ago: 

    http://www.sqlservercentral.com/articles/Editorial/91174/

    Hakim Ali
    www.sqlzen.com

  • I agree it is best to own up to one's mistakes and notify those impacted as soon as possible and of course fix them quickly, but carefully. It is the mature thing to do. It is also important what you do if you discover someone else's mistakes. When feasible, I privately let them know and make sure they understand the issue to prevent it from reoccurring. I make it clear that I am not concerned with blaming, and that I make mistakes, too. I let others know who are impacted and avoid naming the person responsible, but let people know it has been dealt with and steps taken to prevent a recurrence.

  • Smart people learn from mistakes, arrogant people ignore mistakes and make them again

  • tcronin 95651 - Thursday, July 13, 2017 7:56 AM

    Smart people learn from mistakes, arrogant people ignore mistakes and make them again

    This is a good quote to quote at parties and to live by... 🙂

    Hakim Ali
    www.sqlzen.com

  • I have made lots of mistakes it is much easier to solve mistakes when you own up, I would have more respect for any Jr DBA who would own up to a mistake than one with 10 certifications who won't.

  • I own up to the mistakes I make. I believe it is the right thing to do, so that's why I do it. But I have to say that my experience isn't like you described, Ben. Unfortunately for me, most of my professional career has involved working with some people who never own up to their mistakes when they make them and holding in contempt anyone who makes a mistake and owns up to it. Perfection is expected of all, which is of course unrealistic, but it doesn't matter. Perfection is still expected.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Rod at work - Thursday, July 13, 2017 8:50 AM

    I own up to the mistakes I make. I believe it is the right thing to do, so that's why I do it. But I have to say that my experience isn't like you described, Ben. Unfortunately for me, most of my professional career has involved working with some people who never own up to their mistakes when they make them and holding in contempt anyone who makes a mistake and owns up to it. Perfection is expected of all, which is of course unrealistic, but it doesn't matter. Perfection is still expected.

    I also have colleagues who have never owned up to mistakes. They have lost credibility because of it. When someone reports an issue and they deny it could have anything to do with their area of responsibility, but shortly after the problem mysteriously resolves itself and this happens repeatedly -- especially  when the colleagues reporting the problems are extremely knowledgeable and respected by others at our workplace. . .

  • Julie Breutzmann - Thursday, July 13, 2017 9:30 AM

    I also have colleagues who have never owned up to mistakes. They have lost credibility because of it. When someone reports an issue and they deny it could have anything to do with their area of responsibility, but shortly after the problem mysteriously resolves itself and this happens repeatedly -- especially  when the colleagues reporting the problems are extremely knowledgeable and respected by others at our workplace. . .

    Doesn't source control force you to check in changes so you know for sure what changed when and by whom?

    Hakim Ali
    www.sqlzen.com

Viewing 15 posts - 1 through 15 (of 28 total)

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