As emotional creatures, we are very sensitive to our environment, to people around us and events that happen. The way we respond to these events shapes who we are and determines our character and how we will behave in the future. If you try to find out who are the most optimistic or pessimistic countries in the world you will quickly realize that the data varies across multiple studies and timelines. Maybe in 2012 Greece was the most pessimistic country in the EU while in 2018 it was France, or maybe you find out that Romanians are the most optimistic people when asked about European Union’s future and the most pessimistic when asked about their country’s future.

Optimism is also experienced in software development teams and engineers are emotional and sensitive people too. Many times when developing software you hear things like “This code is shit” or “Everything breaks all the time” or “Not another deadline”. It’s very easy for teams to get demotivated, have low morale and be full of pessimistic outlooks about the future. In the long run, this leads to bad quality software, low or no engagement and headaches for HR.

Not only this affects the company and the work environment, but also it affects every single individual. The link between pessimism and health issues has been clearly established as well as the link between optimism and longevity. It’s important that we learn to be optimist, not only at our workplace but in every situation and not for other people, but for ourselves. In his book “Learned optimism”, Martin Seligman makes a synthesis of the research he has done in the past decades. It’s backed by thousands of hours of work, hundreds of experiments and dozens of peer-reviewed studies. It’s one of the best books I have ever read and I have great admiration for the work behind it.

Optimism defined

Putting a definition of optimism is one of the toughest things and it’s easier to explain how you can measure it. Optimism is the response (positive or negative) that you have in a situation and the dimension of that response. There are 3 dimensions: permanence, pervasiveness, and personalization. Is the situation good or bad? Is it permanent or temporary? Is it happening only here or everywhere? Are you part of the cause or is the cause external?

Permanence is the tendency of making bad events a persistent state, for example, if you forget to do a release, do you think about yourself as someone who tends to forget things often or is that something that happened because you were busy? If you think you’re forgetful, then you are pessimistic about it. Optimistic people tend to think about such events in “sometimes” and blame it on transient conditions. Alternatively, in case of good situations, optimistic people try to identify the traits, abilities and “always”’s. You finished the project on time and you think about yourself as a great engineer or do you think that it happened because you got an easy project this time? You probably guessed which one makes you an optimist.

To keep oneself optimistic and positive, when good things happen such as finishing the project on time, preventing major bugs and fixing a bug quickly, here are some things to consider:

• define yourself and your team in a positive manner — professional engineers, fast responders, great analysts, smart people
• Identify the skills used and emphasize them — debugging skills, ability to create abstracts, ability to identify the business domain, proficiency in a programming language or framework, etc.
• Identify the specific processes used: testing twice before releasing, putting software in users’ hands, writing good unit tests, releasing frequently, breaking down tasks, splitting work according to team skills and abilities, etc

The second important dimension is pervasiveness and it refers to space. Pessimistic people make universal explanations for bad situations while making specific explanations for good situations. For example, if someone thinks the code in the application is of bad quality because managers always stress the team, then that is a pessimistic explanation. On the other hand, if someone who is identifying the specific areas where the code needs refactoring and knows that the code was written last December when marketing was running the biggest campaign of the year, then that person is presenting an optimistic view. The pervasiveness also applies for good situations and is more subtle, pessimistic engineers tend to identify the specific causes of good events, instead of generalizing them. “We’re great at debugging software” (pessimistic) vs “We’re great” (optimistic). “We’re good at testing APIs” (pessimistic) vs “We’re good at testing” (optimistic)

Personalization is the final aspect of explanatory style and in my opinion, is the trickiest one to handle. In bad situations, pessimists internalize and show low self-esteem while in good situations externalize. “We are bad at handling incidents” or “We were the worst suppliers this month” or “We were lucky we had a backup” are signs of pessimism. The opposite happens in case of good situations, pessimists try to identify external explanations instead of internal explanations: “The support team doesn’t know how to use the application” or “The vendor library caused the bug” or “We can take advantage of our front-end skills” are all optimistic.

One important note about this dimension is to always consider the context of the organization. While it’s good to look for external explanations, when being part of an organization, the externals might be another team or department and it’s never a good idea to blame others. If this becomes a recurrent blame pattern, then a different action course needs to be considered and one should start looking at the values and culture in the company.

Becoming optimist

In his book, Martin Seligman, also presents a process for increasing optimism. It’s a little “technical” and very easy to apply.

A difficult situation arises from adversity. This generates thoughts which rapidly turn into beliefs without even realizing it. The beliefs generate consequences for what we feel and do. below are 2 examples.

Someone breaks the build, you think he is a bad engineer and you stop what you’re doing and tell him to fix it immediately — pessimistic

You have a debate with the product manager about a feature, you believe you can always clear misunderstandings with visuals and you quickly create a diagram for it — optimistic

There are two ways to deal with pessimism: disputation and distraction. Distraction is all about changing focus, interrupting a bad thought process, changing the subject in a discussion or switching to a different task. Disputing is more effective in the long run because disputed beliefs are less likely to occur. The most common way of disputing a negative belief is by bringing evidence and proving it’s incorrect. You put on the detective hat and ask “What is the evidence for this?” Other ways of disputing are by thinking about the implications and testing them against a future scenario or by trying to see if the beliefs are useful in future situations.

Someone breaks the build, you think he is a bad engineer and you stop what you’re doing and tell him to fix it immediately. After a few minutes, you realize you generalized too much and you ask yourself: How many times has this person broken the build? You will quickly find out that it’s not that many times or that the build breaks quite frequently and that doesn’t define you as a good or bad engineer. Alternatively, if that person really is a bad engineer, are all the builds of that person going to break in the future? Of course not.

Another way of disputing things is by finding alternatives. Almost everything that happens has more than one cause. If you failed to deliver a task on time all of the following might have contributed: the difficulty of the task, a lack of understanding about the subject, how much support you received from other people, how tired you were. Pessimists try to find the most pervasive, permanent and personal one. Why latch onto the most insidious one? Think about the less destructive cause and choose that as part of your belief.

After identifying it, energize yourself by putting it in the 3 dimensions: think of it as a rare occurring event, that happens locally and is external: “We had a bug on production, but I don’t feel bad about it. I was able to fix it fast and this kind of incident rarely happens to me. Plus this happened because nobody considered that complicated use case”

To sum up the process:

• A (adversity) — identify the situation
• B (belief) — identify the belief behind it
• C (consequence) — think about the consequences
• D (disputation) — dispute the belief: look for evidence, use implications, search for alternatives or identify the usefulness
• E (energization) — exit the situation with a positive energy

Applying the process of identifying beliefs and disputing them is not easy to do on the spot in the beginning. It’s a good idea to practice it for 5 minutes a day for a few days and after getting proficient at it to start doing it on the spot and with other people.

There is one word of caution about optimism that comes from Martin Seligman: never use it to plan for the future. Use it to create a healthy mindset, an empowering environment and to change the perspective of situations, but never use it for planning the future.