Planning for a Bad Day

  • Comments posted to this topic are about the item Planning for a Bad Day

  • This was removed by the editor as SPAM

  • The third time I faced a 'downsizing' situation I actually planned too well.  I took an 'early retirement' offer and headed out to my long-planned-for  Rocky Mountain cabin.  I was only there for about three weeks when I was contacted by the company my job had been  outsourced to asking if I would like to return to work.  We negotiated a very nice arrangement including a salary increase and time off and I put in another three years back in my same cubicle.

    Sometimes bad days can turn good after all.

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • This is an excellent topic. One I concern myself with a lot. I intend to respond later today to give information from my own experience, but at the moment I haven't the time.

    I do want to address one thing you brought up Steve, and that's DevOps, ITOps, GitOps, etc. I feel rather good about my DevOps skills and experience. I am the technical lead where I work on DevOps, handling the technical aspect of it with our legacy TFS and helping to move us to GitHub. But what I don't get is GitOps. I've seen the phrase for several months now, but I don't really get what GitOps is about. Could you provide some explanation, please?

    Kindest Regards, Rod Connect with me on LinkedIn.

  • https://www.redhat.com/en/topics/devops/what-is-gitops#:~:text=GitOps%20uses%20Git%20repositories%20as,set%20for%20the%20application%20framework.

    Really all the XOps stuff is using code to do things instead of humans clicking (or typing in real time). Store your infrastructure stuff in Git and then use that to deploy stuff. Terraform, CloudFormation, Azure Resource Manager, etc.

     

    I did a webinar with Octopus Deploy, and part of the OD setup was building up new Azure databases, which would be GitOps. Repo and OD setup here:

  • Definitely have a profile on LinkedIn and read matching job descriptions that land in your email - even if you are in no way considering a move. Do this to keep your skills current with what employers in your local job market are looking for. Remember that staying current helps (but certainly doesn't guarantee) you not ending up on a short list of candidates to be laid off in the first place. If it seems like your current employer is moving in a new direction, then "get on board the train" and don't be a grumpy old contrarian stewing a corner somewhere, because that's not useful. Employers tend to hold onto things they deem useful.

    Also, keep at least three months of minimal living expenses in an account that you can easily tap when needed.

    Many years ago, I was laid off when my wife was six months pregnant with our two kids. I got the news early in the morning, and before returning home, I stopped at a park and spend several hours accessing the situation and preparing myself psychologically, before I notified my family. It's important to open yourself to all the available options, stay positive, and remain in control.

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

  • Thank you, Steve, for the explanation of GitOps and the link to RedHat's discussion on it.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • I have spent most of my career working in the public sector. Working in the public sector affects how you think. One quite common belief, as a public sector employee, is that you can never be laid off. And for most public sector/civil servant employees that will be true. However, I have been laid off twice from public sector jobs. I've come to believe there's no such thing as any job that is 100% safe from layoffs.

    Steve and Kendra's admonition to consider what you might have to do, if the "bad day" comes, is excellent. Looking back at my last layoff, there were some hard lessons I learned from that. At the time I was working for a university. Working for a university meant that they understood the need for continuous learning. I took advantage of that, but I still failed to be properly prepared. For example, I had heard of unit testing, but we didn't practice unit testing in my group. (I'm a software engineer as was my colleague at the time.) Unit testing isn't one of those skills commonly listed, even 8 years ago when I was laid off. But it is one of those basic skills that is expected you would know. I found a free video tutorial on unit testing online. I watched it and practiced it. It helped me get re-employed.

    So, in conclusion, make sure that you know the basics of your trade. Those basics probably won't show up in job post listings, but when you're in an interview and it becomes evident that you don't know some of the basics, you're through.

    Rod

  • I always did 'unit testing, even back in the days of Assembler, COBOL, and RPG.  We 'commented' out everything after the part to be tested to stop processing at each stage.  SQL is SO much easier!

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

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

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