The Road to Success

  • Comments posted to this topic are about the item The Road to Success

  • One of my previous bosses said that "If you don't make mistakes, I'm not pushing you hard enough".

    While I agree with that, the place to experiment and make mistakes is on the Dev box, not the Prod box. Folks should also buy a copy of the Developers Edition and spend a little time solving problems they find on forums or experimenting with new things. In other words, they should spend some time practicing their trade so they don't find so many bumps in the road. Doctors read about new things after hours and attend seminars on their own time. Pianists practice every day. Athletes practice on a regular basis. Why do people consider the job of being a DBA or Developer any different?

    The time to make mistakes is during practice... not when it counts. Mistakes when it counts should really piss you off at yourself.

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

  • Like it or not stuff will go wrong, very occasionally not through third party externalities. It's how you roll with the punches that determines perceived level of success in my experience. Mostly our own errors are in not setting strategy early to cope with the actual events rather than the expected ones. I like to continually review all the design decisions made and think 'how could this have been improved, what was successful or not in this design?'.

    Then I go down the pub, after dealing with the supplier who has switched account numbers and product codes in the ftp'd file that was just imported, with hilarious results.

  • I'm always careful. I avoid every mistake I can as much as possible, while working to meet a given deadline.

    I still have bugs, and there are even still deployment issues even with a formal process in place.

    We're imperfect. Even as much as we'd like to think not, our equipment is imperfect at times (even though we try to design it not to be).

    Things are going to happen. That's the only thing you can count on. You just have to remedy them, then move on.

  • Actually, what is really missing is the thought that all these will appear as a mistake in the short term (or even a mistake at all).

    "...If you've ever driven (or walked) down a cobblestone road, you know what I mean. It's not a path you'd want to take every day in a wheeled vehicle..."

    The irony of this statement is that cobblestone roads were put in for wheeled vehicles. They were a huge improvement over the muddy ruts that proceeded them and where NOT there for people to walk on. If anything understand that when you look back on a blunder realize it may have been a huge improvement. And your improvement today may become an impediment tomorrow.

  • Mistakes happen anytime you're developing something new that's just part of development, and the more radical the new development is the more likely you'll find odd and potentially critical issues. That's to be expected and handling them gracefully is also important.

    Mistakes I don't like are mistakes that google could have prevented with a 5 minute search.

  • I just worry about the programmers that want to "fix" something that isn't broken, just to make it more efficient. As often as not they really don't understand all of the code and introduce errors.

  • Programmers have it a lot easier than doctors. We have the luxery of practicing on test subjects, before moving on to the real thing, and even when we get stuck on a real problem, we can just put it aside and come back to it later.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell (8/20/2015)


    Programmers have it a lot easier than doctors. We have the luxery of practicing on test subjects, before moving on to the real thing, and even when we get stuck on a real problem, we can just put it aside and come back to it later.

    I was going to write much the same.

    I have spent 12 years in the medical field (5 years working on EMR's and 7 as a caregiver) and an additional 11 years in non-medical tech areas.

    Making a mistake on a stored procedure in general tech can bring back bad data (which can cause cascading issues), bring down a DB or just be rather inefficient in processing.

    Making a mistake in a stored procedure in an EMR can be benign or can cause a patient to receive an incorrect procedure/medication dose (very bad things).

    Making a small mistake when taking care of a patient (incorrect ventilator setting, incorrect medication dose, incorrect diagnosis, missing something on x-ray, incorrect interpretation of lab results, etc) can lead to permanent impairment or death of the patient.

    In healthcare, we were VERY well trained in our jobs/responsibilities, can't say that about any tech environment that I have worked in.

    In healthcare, we had an incentive to keep up to date on a lot of different things. New meds, new techniques and new ways to protect ourselves. Spent a lot of time on self protection.

    You don't get MRSA/VRE/HIV/Hep C/TB from a computer, you can from a patient.

    Mistakes are to be avoided as much as possible.

    When the environment that you are in requires you to work on multiple, complicated projects at once with tight timelines, sometimes/often without the required training/experience and without enough staff; you better expect mistakes and quite frankly, your employer deserves those mistakes for their short sightedness.

    Yes, some hospitals 'work' like this. These are usually the hospitals that end up closing or being bought out (with massive staff/management 'movement').

    In healthcare, we were required to accumulate X amount of CEU's (continuing education 'hours') over X period of time in order to keep our licenses. This was a requirement to work in the field. Most hospitals will provide much of this training free of cost and will pay you to attend.

    I don't need a license to be a DB Developer/DBA.

    I have never worked for a tech employer that would pay you for training or encouraged you to train on company time (barring being sent offsite for training which was VERY rare).

    There is a big difference between medical practice and being a technologist.

    Sorry, this hits a vein.

  • Jeff Moden (8/19/2015)


    One of my previous bosses said that "If you don't make mistakes, I'm not pushing you hard enough".

    While I agree with that, the place to experiment and make mistakes is on the Dev box, not the Prod box. Folks should also buy a copy of the Developers Edition and spend a little time solving problems they find on forums or experimenting with new things. In other words, they should spend some time practicing their trade so they don't find so many bumps in the road. Doctors read about new things after hours and attend seminars on their own time. Pianists practice every day. Athletes practice on a regular basis. Why do people consider the job of being a DBA or Developer any different?

    The time to make mistakes is during practice... not when it counts. Mistakes when it counts should really piss you off at yourself.

    Well said

  • Jeff Moden (8/19/2015)


    One of my previous bosses said that "If you don't make mistakes, I'm not pushing you hard enough".

    While I agree with that, the place to experiment and make mistakes is on the Dev box, not the Prod box. Folks should also buy a copy of the Developers Edition and spend a little time solving problems they find on forums or experimenting with new things. In other words, they should spend some time practicing their trade so they don't find so many bumps in the road. Doctors read about new things after hours and attend seminars on their own time. Pianists practice every day. Athletes practice on a regular basis. Why do people consider the job of being a DBA or Developer any different?

    The time to make mistakes is during practice... not when it counts. Mistakes when it counts should really piss you off at yourself.

    Well said

  • kiwood (8/20/2015)


    Actually, what is really missing is the thought that all these will appear as a mistake in the short term (or even a mistake at all).

    "...If you've ever driven (or walked) down a cobblestone road, you know what I mean. It's not a path you'd want to take every day in a wheeled vehicle..."

    The irony of this statement is that cobblestone roads were put in for wheeled vehicles. They were a huge improvement over the muddy ruts that proceeded them and where NOT there for people to walk on. If anything understand that when you look back on a blunder realize it may have been a huge improvement. And your improvement today may become an impediment tomorrow.

    It's a sign of change and progress. These roads were the best "technology" at the time for mass roads. We've moved on. We should do the same thing with our skills.

  • Iwas Bornready (8/20/2015)


    I just worry about the programmers that want to "fix" something that isn't broken, just to make it more efficient. As often as not they really don't understand all of the code and introduce errors.

    I'd be more concerned if I didn't have any programmers that wanted to make things more efficient especially since it seems that we double our business every year or two.

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

  • Jeff Moden (8/20/2015)


    Iwas Bornready (8/20/2015)


    I just worry about the programmers that want to "fix" something that isn't broken, just to make it more efficient. As often as not they really don't understand all of the code and introduce errors.

    I'd be more concerned if I didn't have any programmers that wanted to make things more efficient especially since it seems that we double our business every year or two.

    They just need to prove it's fixed in development and QA first, before submitting it for production.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell (8/20/2015)


    Jeff Moden (8/20/2015)


    Iwas Bornready (8/20/2015)


    I just worry about the programmers that want to "fix" something that isn't broken, just to make it more efficient. As often as not they really don't understand all of the code and introduce errors.

    I'd be more concerned if I didn't have any programmers that wanted to make things more efficient especially since it seems that we double our business every year or two.

    They just need to prove it's fixed in development and QA first, before submitting it for production.

    As much as I'm all for making improvements when possible/needed I get worried when developers have nothing better to do than just start randomly picking things to improve 😛

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

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