Jinx or Cassandra? What's the difference?
Well... Cassandra was right! **

I found this quote in a book I read this summer. ( The hungry and the fat - from Timur Vermes) and it reminded me immediately about the endless discussions "Be Positive!" vs "I am just realistic!".

Everything will go wrong

I bet you all know Murphy's law. In all of its variations and corollaries:

• Anything that can go wrong will go wrong.
• Nothing is as easy as it looks.
• Everything takes longer than you think it will.
• If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong.
• If there is a worse time for something to go wrong, it will happen then.

Now, if you have enough experience in software engineering you'd already figure out where I am going.

If you have at least deployed an application or a microservice to production, you definitely have encountered countless bugs and crashes you would have never imagined.

If you are used to code in a TDD manner - or at least you write lots of unit and integration tests, you have surely realized that the more tests you write, the more edge cases you find ( when to stop it's a topic for another post).

And if you had the opportunity to even get close to Chaos Engineering, well.. you must have seen how many things could go wrong.

As an experienced developer, you definitely have the "gift" of foreseeing problems, use cases that were not taken into consideration, flaws in the system that might cause hiccups, breakdowns, bottlenecks in the process that might delay the delivery, suspect the unexpected behavior of quick-fixes that would cause more damage than the current bug - and so on.

Basically, you might be the one always "ruining the party":

• everybody estimates a ticket as a quick and easy task.. there you are bringing in all your - valid - reasons why it is actually a rather complex one which will definitely take longer.

• everyone is already thrilled by how good the application looks and agree it could be shipped even before the deadline and you are there reminding the 80-20 rule, that auth and security are still missing, there is not yet proper error handling or format validation and that, well, this is actually the prototype and it is far from ready to be on production...

Even when everything is actually really good, I bet you still have quite a long list of todos and improvements and tickets for fixing the technical debt.

Is it so hard to Be positive?

Oh come on.. don't be so negative, you always bring up problems. you can't always see problems everywhere!

The truth is, that you are not making up problems, you don't' see problems, you foresee them, and try to be prepared, you try to anticipate them.

This summer I went with my wife and kids and an alpine guide on a 3day tour/course about multi-pitch climbing.
There is a lot to learn: knots, gear, safety but after the second day everything seemed kinda manageable.

During the third day though, the guide started explaining more and more use cases, exceptions, unexpected occurrences that might make a climbing trip more complicated and dangerous:

• what if halfway through a sudden storm approaches,
• what if you drop one of your tools
• what if the rope gets stuck in a tree or stone crack,
• what if you get to the top and one of the bolts you rely on to abseil down is missing or completely rusted?

We knew the basics and we thought we were good to go - and we could indeed, to some extent.

But to avoid problems, to be really safe, to be prepared, to be an expert, you need a lot more.

You are not a Jinx if you remind people to have backup plans and redundancy ( in climbing as in microservices).

Being able to anticipate and be prepared to face adversity has nothing to do with pessimism.

Another interesting book I read this summer Mastermind: Mental training for climbers touches the topic of Optimism and Success:

of course for an impressive performance it is absolutely paramount to have the right positive attitude.
The cornerstone of this positive attitude is laid by optimism.

Up to here, pretty straightforward and expected.

Once you have thought through everything and imagined anything that could go wrong and have solutions ready, then, only then, you can be optimistic.

Oh, now this sounds more realistic. This is the positive attitude I like, that is the result of trust in yourself, expertise and preparation, not just esoteric everything-will-be-fine Dunning–KrugerishEeffect delusional optimism!

The role of Pessimists

Coincidence wanted that over summer my wife read Learned Optimism from Martin E.P Seligman. In a chapter, the author explains the characteristics and consequences of Pessimism (feeling of helplessness, passivity, anxiety, inactivity, lack of trust, more chances of giving up), but he also states that Pessimism can have a very important role: that of correcting the wrong assumptions and behavior of the optimists.

Too often optimists are naive, and overconfident, while pessimists have a better sense and understanding of reality and are more objective in assessing situations with their unpredictable adversity.

Pessimists are described as fundamental in many companies to prevent disasters. A company needs the optimism of founders salesforces and creators who dream and go big, as well as the pessimism of financial analysts solicitors and engineers who keep the feet on the ground.

Of course, they are just professional pessimists experts in their field that are able to listen to their pessimist side only when its justified and learned to choose optimism to move forward, be proactive, and maintain a positive attitude while communicating bad news to the optimists.

So what can you do?

As software engineers, it is our job to prevent bugs, crashes, leaks, etc and it is our job to come up with solutions.

We are problem solvers, we solve problems with code.

An average developer is given a problem and is able to fix it.
A better developer will be able to anticipate it, will proactively suggest ( or directly implement ) solutions for it, or at least will have awareness of it, and will be somehow prepared for it.

It is not necessary to fix everything in advance, sometimes it is enough to bring up the issue so that everyone in the team is aware and can plan confidently taking aspect into account, there are no bad surprises, and eventually, there is a plan B ready. ( it is always a matter of costs and benefit, and often it is worth to take some risks or accepts some potentials problems or bugs)

• Don't be a blocker, don't complain all the time. If possible don't even mention the word "problem", the best that can happen is someone replying with some annoying cheesy things managers say :

There are no problems, only challenges!

or

Either you are part of the problem or part of the solution.

Simply explain the issue, the possible impacts on the product or customers, and eventually what is needed to prevent it.

• Be proactive. Suggest alternatives, bring up a solution, or if you don´t know yet how to solve the problem, bring up at a plan to mitigate the issue.

• Never lie. Never join the happiness and confidence wagon just to be accepted by the team. For the sake of the product, the users, your company, and overall your career and dignity.

• Never, never say I told you that - with a grin on your face if your suggestions were left unheard. Bite your tongue and rather use this as an argument ( not as revenge) in the next discussions.

Once again communication and emphaty are important soft skill s that go together with good coding and exceptional problem-solving capabilities.

Photo by Andrik Langfield on Unsplash

**

Cassandra was a priestess of Apollo in Greek mythology cursed to utter true prophecies, but never to be believed, Jinx is simply someone that is cursed and brings bad luck ( in
German the word Pechvogel is used, in Italian it is Uccello del Malaugurio which both mean Bird that brings unluck - and Jinx is actually the scientific name of the bird Wryneck )