Are mainframers too negative?

Self-help gurus have become the equivalent to pop stars and TV idols. They are well-known and have thousands of followers on social media. And their message is always to be positive. We should always think about successful outcomes to anything that we want to achieve. And if we want those outcomes enough, then we will achieve them. It’s a simple and compelling message, but is it the right message for people looking after a mainframe? Shouldn’t all mainframers spend their day hoping that everything will work out successfully? Let’s look at the evidence.

Suppose, for example, that I am a systems programmer working on a mainframe. I am making some changes to z/OS. And, while I enjoy a brief coffee break, I am visualizing my colleagues congratulating me on my work. I’m imagining the senior management at my organization coming over to my desk and shaking my hand because of my great work. Is that visualization likely to spur me on to doing great work? Or is it likely to reduce my motivation for doing great work? As strange as it seems, it’s likely to reduce my drive to get the job done!

How do psychologists explain this? It seems that the brain can’t tell the difference between real events and imagined events—after all, the information travels round the brain as electrical signals in neurons. So, what happens is this: you want to do something and set out to achieve your goal (ie update some SIT settings in CICS). When you’ve achieved the final result and everyone congratulates you, your drive to achieve the goal reduces to almost nothing—you’ve probably already begun planning your next project. However, when you visualize success, with its associated handshaking, that also reduces your drive to achieve your goal. Your brain thinks it has already achieved it, so you can stop now. And that can prevent you from actually achieving the goal in real life that you set yourself. The conclusion is to never visualize the success at the end, but only the steps on the journey.

Let’s take another scenario. You have made some changes to the basic definitions of your z/OS system in parmlib. You’re going to reboot on Sunday afternoon, and you hope that everything will work. Let’s look at that key word, ‘hope’. Again, we’re looking on the bright side, being positive—isn’t that what all the self-help gurus tell us?

Let’s remind ourselves of the story of Pandora’s box—the one that had all the curses of mankind (sickness, death, etc) in it. You remember that Pandora was curious about the box and let out all the troubles except hope. The problem is that the story we tell is quite different from the original told by the ancient Greeks. For example, the box was originally an urn or large jar. And ‘hope’, the Greek word ‘elpis’, is more often translated as ‘expectation of evil’ rather than ‘expectation of good’. And that really doesn’t make ‘hope’ a good thing, which is how we usually use the term.

But let’s divide the world into two parts, the parts we can change (where we have agency—as they say) and the parts we can’t change, like the weather (where we don’t have agency). Hoping that it won’t rain on Saturday is probably fine because there really is nothing we can do about it. Hoping that the mainframe will boot up and run perfectly is probably not OK, because we do have agency, if we are the systems programmer making the changes. We should be taking all the steps we can to make sure it works, and not just leaving it to chance that everything is going to be ‘alright on the night’.

Let’s take that example and go further with it. Let’s suppose that we are all on a spaceship, miles out in the solar system. And, yes, I do like science fiction. I want the people at mission control to be considering the worse-case scenario of every action that we take on that spaceship. I also want them to consider what needs to be done now in order for that worst case not to occur. I want them to think whether an event will cause a fire, or a loss of oxygen, or life-support to fail, and make sure that appropriate steps are taken to prevent that outcome ever occurring.

In the mainframe world, this would be taking steps to ensure the operating system and subsystems were still running. To ensure that customers could still log in and buy product etc. It’s like having a built-in health and safety officer making sure that whatever people do, no worst-case scenario will result. I guess the example in the news at the moment would be how we can prevent ransomware getting on our mainframe. Steps need to be taken now to ensure that it can’t happen. And, in the event that it does, there need to be processes in place to prevent getting to the situation where backups are corrupted, files have been copied elsewhere and local copies encrypted, and a Bitcoin ransom message appears on the console.

In this case, not so much planning for the worse as planning the steps to avoid the worse happening is really a good idea. It’s like working on the business continuity plan (BCP) to make sure that the company can stay in business should some kind of disaster occur.

The problem that many people find is that they have the opinion that thinking of bad things happening is their brain having negative thoughts. And, obviously, thinking that everything will turn out the way you want is having positive thoughts. So, it’s not uncommon for mainframers and others to somehow feel guilty that they are not being positive. It’s as if going against the wisdom of self-help gurus is wrong. But not all self-help or therapy techniques work like that. There’s a thing called Acceptance and Commitment Therapy (ACT) that encourages people to embrace their thoughts and feelings rather than fighting them or feeling guilty about them. The approach was originated by Steven Hayes in 1982. The ACT model for people to follow is:

• Accept your thoughts and emotions
• Choose a valued direction
• Take action.

I mention this to show that mainframers don’t need to worry about having negative thoughts. There is a talking therapy that helps people to accept those negative thoughts.

Almost lastly, I want to mention defensive pessimism. Defensive pessimism is a cognitive strategy that was first identified in the 1980s by Nancy Cantor, and it works like this. A person prepares for an event that causes them to be anxious (like installing new software or preparing against a security breach occurring) by using defensive pessimism. They do that by setting low expectations of their performance—ignoring how well they may have done in the past. They then think about all the setbacks etc that could happen to prevent things going successfully. Defensive pessimism allows them to avoid the pitfalls they imagined, or have strategies in place to deal with them. And the final outcome is usually success. Their anxiety has produced a positive outcome.

One final thing before we finish: don’t think about a pink elephant! In numerous psychology experiments where people have been told not to think about something, they have failed. It’s very hard not to think of something that you have just been told not to think of. Similarly with these self-help gurus: when they tell you not to think negatively, it’s very hard not to.

When you’re thinking about your mainframe and all the things that might happen, being negative is a good thing. It gives you the opportunity to prepare for worst-case scenarios, and be in a position to remediate them if they occur, and prevent them from occurring. Negativity keeps you focused and is probably what drives you to perform one more check that everything is OK before updating the system—rather than just hoping for the best! The truth is that mainframers can’t be too negative.