Unwired for Weeks

  • We're not saving babies is the expression that the work doesn't have to be done right now and be 100% correct. Could there be implications down the line? Sure, if we miscalculate something for years or we don't get a system done in the next months, perhaps the business fails or people get terminated. Will they die? Maybe, if they can't afford healthcare, but they aren't dying today.

    Most of us are  not in the immediate, we need to have this working today, business. Doctors, first responders, certainly people that are building patches for medical systems or providing technology services to groups that are in some businesses are. They need redundancy and lots of good checks.

    Event those of us that write code for a medical device. If our code isn't done today, or fails a test (please, tell me you're testing your software extensively), we aren't causing babies to die. We need to get the code working and something fixed later, but it's not today.

    Please don't take this out of context and imply or believe I'm saying our work doens't have consequences or might cause impacts down the line. Jeff, you spreadsheet didn't affect babies or  people's lives directly. There were a whole lot of other things that happened along the way after that.

  • GeorgeCopeland - Thursday, August 9, 2018 9:21 AM

    Wow Jeff, just wow. Great post.

    Btw, not saving babies is a quote from you know who--

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

    Heh... yeah... I've had several conversations about this with and near him on several posts. 😀

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

  • jay-h - Thursday, August 9, 2018 10:44 AM

    Any entity in the 'saving babies' business MUST have sufficient redundancy. People are unexpectedly or expectedly out for a variety of reasons (including 'buses'). If you cannot be spared for a week, your employer has no business being in that operation.

    The problem was, there were a ton of people that were much more qualified than I was to make the determination that I did.  And, they were all contacted and I explained it to every one of them.  Redundancy by numbers of people in a given position is not enough.  You also need redundancy in the ability to analyze and then also have the right attitude.  I believe that the people were playing me down the way the did because they didn't want to be the bearer of bad news.  To me, that means they didn't actually know how to do their jobs no matter how much redundancy there was in supposed qualifications and the number of people that supposedly had such qualifications.

    Simple redundancy is not sufficient.

    --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 - Thursday, August 9, 2018 11:15 AM

    The problem was, there were a ton of people that were much more qualified than I was to make the determination that I did.  And, they were all contacted and I explained it to every one of them.  Redundancy by numbers of people in a given position is not enough.  You also need redundancy in the ability to analyze and then also have the right attitude.  I believe that the people were playing me down the way the did because they didn't want to be the bearer of bad news.  To me, that means they didn't actually know how to do their jobs no matter how much redundancy there was in supposed qualifications and the number of people that supposedly had such qualifications.

    Simple redundancy is not sufficient.

    I was thinking more about someone covering when you were out for whatever reason. An organization that is willfully blind is an entirely different problem. Your taking time off would not change the outcome in any way.

    ...

    -- FORTRAN manual for Xerox Computers --

  • I think it's a good perspective to have, because workplaces always tend to take the approach of "we'll accept however much effort you want to put in". Some outright ask for more than others, but nobody is going to stop you if you try to work an 80 hour week. Unfortunately, that will leave you sick and/or dead if you keep it up. So, learning that "work" is a firehose and all you can do is drink what you can and divert the rest, comes in handy. Do what work you do well, with reasonable expectations of yourself, try to manage the expectations of others to be in line with reality. Let the rest go, try not to over-stress about it. Yes, I suck at that too.

    Plus, Yellowstone is awesome. I've never been to the other, but that sounds fun too.

    -------------------------------------------------------------------------------------------------------------------------------------
    Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses

  • jonathan.crawford - Thursday, August 9, 2018 11:43 AM

    I think it's a good perspective to have, because workplaces always tend to take the approach of "we'll accept however much effort you want to put in". Some outright ask for more than others, but nobody is going to stop you if you try to work an 80 hour week. Unfortunately, that will leave you sick and/or dead if you keep it up. So, learning that "work" is a firehose and all you can do is drink what you can and divert the rest, comes in handy. Do what work you do well, with reasonable expectations of yourself, try to manage the expectations of others to be in line with reality. Let the rest go, try not to over-stress about it. Yes, I suck at that too.

    Productivity falls off quickly after 40 hours and workaholics are not nearly so productive as they think. What's more, they drive everyone crazy. So yeah, I am going to tell you that I am not impressed by the hours you put in, why don't you try to pick up your productivity and get it done in 40? A key to success in IT work, maybe anywhere, is to prioritize. If you are always working productively on the most important task, there is very little else that can be asked of you, and you will be maximizing your chances of success.

  • Steve Jones - SSC Editor - Thursday, August 9, 2018 10:58 AM

    We're not saving babies is the expression that the work doesn't have to be done right now and be 100% correct. Could there be implications down the line? Sure, if we miscalculate something for years or we don't get a system done in the next months, perhaps the business fails or people get terminated. Will they die? Maybe, if they can't afford healthcare, but they aren't dying today.

    Most of us are  not in the immediate, we need to have this working today, business. Doctors, first responders, certainly people that are building patches for medical systems or providing technology services to groups that are in some businesses are. They need redundancy and lots of good checks.

    Event those of us that write code for a medical device. If our code isn't done today, or fails a test (please, tell me you're testing your software extensively), we aren't causing babies to die. We need to get the code working and something fixed later, but it's not today.

    Please don't take this out of context and imply or believe I'm saying our work doens't have consequences or might cause impacts down the line. Jeff, you spreadsheet didn't affect babies or  people's lives directly. There were a whole lot of other things that happened along the way after that.

    Correct.  My spreadsheet didn't cause babies to die nor impact anyone's life directly.  The reason for that is that no one took any action and the more immediate the action the better the outcome would have been.  In other words, other people caused people to die and others to have their lives totally disrupted.  If they had acted immediately, as we frequently do in IT, it's a whole lot more likely that the whole mess could have been avoided.  Even if it couldn't have been avoided, not taking immediate action on something that was years out guaranteed that the problem would happen.

    As for testing of medical things, consider this... whatever device is being developed is being developed to save lives or at least improve the quality of life... every day delayed costs more lives or suffering.  Then also consider the recent press on faster deliveries and continuous integration, etc, etc.  Put yourself in a place I hope you'll never be and ask yourself if you might work a little longer and harder trying to get it done and get it done right if someone you loved would die if you didn't get it done. 😉

    Much like Knuth's fine parable about pre-optimization being the root of all evil being warped in such a fashion by people that use it to justify being stupid and lazy, so goes the now tired old saws of "we're not saving babies lives" and "no one will die if we don't do it fast and right".  People are now using it as justification for their stupidity and laziness.  The customers of companies that have such people working for them want those companies to help save their proverbial babies.

    I'd love it if people that were hired to do their jobs would drop sayings like "we're not saving babies lives" and replace them with other sayings like "Make it work, make it fast, make it pretty... and it ain't done 'til it's pretty" and "Built with pride at <companyname>".

    Ironically, if everyone took that attitude during uptime, there would be a lot more room for downtime and going unwired. 😉

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

  • jay-h - Thursday, August 9, 2018 11:19 AM

    I was thinking more about someone covering when you were out for whatever reason. An organization that is willfully blind is an entirely different problem. Your taking time off would not change the outcome in any way.

    "Someone covering" can be done two ways... a body or a brain.  You need to be covered by someone that actually has the brains,the skill, and the correct attitude to cover for you.  If not, then you can't truly go unwired because you'll always have to be prepared to take action even when you're supposed to be unwired.

    --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 you are really firing on all cylinders today. The company where I work recently requested six word stories, here's mine: Perfect accuracy is possible and needed.

  • GeorgeCopeland - Thursday, August 9, 2018 11:58 AM

    Productivity falls off quickly after 40 hours and workaholics are not nearly so productive as they think. What's more, they drive everyone crazy. So yeah, I am going to tell you that I am not impressed by the hours you put in, why don't you try to pick up your productivity and get it done in 40? A key to success in IT work, maybe anywhere, is to prioritize. If you are always working productively on the most important task, there is very little else that can be asked of you, and you will be maximizing your chances of success.

    That's incredibly true.  And that's why training to do it right the first time is so very important.  My personal experiences across many companies is if you don't do it right the first time, you'll spend 4 to 8 times as much time doing rework and retest.  A lot of people, especially a lot of managers, just don't get that.  At the first company that I pressed their nose into on this fact, we doubled productivity by taking the little bit of extra time to do it right the first time instead of allowing the tired ol' "get if off my plate" attitude. 

    And I totally agree... multi-tasking is mostly a myth.  You simply cannot do things well if they all have to be done at the same time by the same person.

    Remember that if you want it real bad, that's the way you'll usually get it. 😉

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

  • jonathan.crawford - Thursday, August 9, 2018 11:43 AM

    Plus, Yellowstone is awesome. I've never been to the other, but that sounds fun too.

    We barely got to the W side of Yellowstone. Already planning on going back to the E side near Cody for a week sometime next year.

    Glacier is amazing. My best hike every was to the Grinnell Glacier, but the Lake McDonald was very cool. Amazing how clear. Want to go back and swim there, as well as hit the Canadian side sometime.

  • Jeff Moden - Thursday, August 9, 2018 11:59 AM

    Correct.  My spreadsheet didn't cause babies to die nor impact anyone's life directly.  The reason for that is that no one took any action and
    As for testing of medical things, consider this... whatever device is being developed is being developed to save lives or at least improve the quality of life... every day delayed costs more lives or suffering.  Then also consider the recent press on faster deliveries and continuous integration, etc, etc.  Put yourself in a place I hope you'll never be and ask yourself if you might work a little longer and harder trying to get it done and get it done right if someone you loved would die if you didn't get it done. 😉

    Much like Knuth's fine parable about pre-optimization being the root of all evil being warped in such a fashion by people that use it to justify being stupid and lazy, so goes the now tired old saws of "we're not saving babies lives" and "no one will die if we don't do it fast and right".  People are now using it as justification for their stupidity and laziness.  The customers of companies that have such people working for them want those companies to help save their proverbial babies.

    I'll still disagree. I need people to work smartly and hard. If I worry about every minute getting code done, even if I'm writing the code for a ventilator or some medical device, I can easily burn out trying to get it done. We need people to work hard, but at a reasonable pace.

    What I dislike about your argument here is that you're arguing to say we should be better, even perfect. Be great. We aren't always great, and we need downtime in order to have those great moments.

  • Jeff Moden - Thursday, August 9, 2018 12:15 PM

    That's incredibly true.  And that's why training to do it right the first time is so very important. 

     I also think that you forget that training people, or people learning to do things well and right, takes time. Most of us won't write code nearly as quickly, or as quality, as you. We need time to get there. We also need time to make mistakes.

    We can't  act as if we're saving babies, which puts pressure on you. Saying we're not saving babies also doesn't imply we can blow things off and not try. It's that we can't treat everything like it's critical. However, we can still work hard, learn to be better, and be professional, doing the best we can, putting in a hard day's work.

  • My own view is closer to Steve's than Jeff's. Cranking up the stress level on the team is rarely a good idea. On the other hand,with our virtual tools, we actually can get our work close to perfection. Please at least make a halfhearted stab to get it that way.

  • If babies die because an IT staff member happened to be on vacation, then there is something very wrong about the organization's functional dependency on information technology.

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

Viewing 15 posts - 16 through 30 (of 36 total)

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