Struggle and Learnt Optimism in Engineering

Engineering is an intellectually violent profession.

To remain relevant, you must constantly disrupt your own mind. You must discard tools you spent years mastering because a better one appeared yesterday. You must sit in code reviews where your logic is dissected line by line. You must accept that your “perfect” architecture from six months ago is today’s technical debt.

Humans are hardwired to seek validation. We want to believe our choices are “right.” But in engineering, “right” is a moving target. This creates a dangerous psychological trap: we attach our self-worth to our code. When the code breaks, we feel broken.

The Paradox of High Performance

I have worked with brilliant engineers who can architecture complex distributed systems in their sleep. They produce high-quality code at an astonishing pace.

Yet, many of them share a common symptom: chronic self-criticism.

They are unable to internalize their success. They brush off compliments as luck (“The library did the heavy lifting”) but internalize failures as character flaws (“I’m just not smart enough”).

It is painful to watch talented friends struggle with this. Imposter syndrome isn’t just a buzzword; it is an occupational hazard. While personality is partly innate, resilience is a skill that can be learned.

The Science of Resilience

Martin E.P. Seligman, the father of positive psychology, did not study “happiness.” He studied helplessness. He wanted to know why some people give up while others keep going.

His research culminated in the book Learned Optimism. The core finding is simple but profound: Optimism isn’t about smiley faces; it’s about your Explanatory Style—how you explain life’s events to yourself.

Seligman identifies three dimensions of explanation:

1. Personalization: Is this about me, or is it about the situation? (Internal vs. External)
2. Pervasiveness: Is this a specific problem, or does it ruin everything? (Specific vs. Universal)
3. Permanence: Is this temporary, or will it last forever? (Temporary vs. Permanent)

Rewiring the Engineering Mind

The difference between a burned-out engineer and a resilient one often lies in how they explain failure (bugs, outages, rejected PRs).

Scenario: Your Production Deployment Caused an Outage

The Pessimist (The Burnout Path):

• Personal: “I am such an idiot. I should have caught this.” (Internal)
• Pervasiveness: “I’m bad at engineering. I can’t do anything right.” (Universal)
• Permanence: “I’m never going to be a senior engineer. This will haunt me forever.” (Permanent)

The Optimist (The Resilient Path):

• Personal: “The deployment script had a race condition that our testing environment didn’t catch.” (External/Situational)
• Pervasiveness: “This specific deploy failed, but my track record for the quarter is solid.” (Specific)
• Permanence: “This is a fixable incident. We will patch it, write a post-mortem, and it will be over by tomorrow.” (Temporary)

Notice the difference? The optimist acknowledges the failure but compartmentalizes it. It is specific, temporary, and situational. This allows them to fix the problem without destroying their ego.

Leading with Optimism

As leaders, we can weaponize this framework to support our teams. When giving feedback, we can guide the explanatory style.

• When criticizing (Constructive Feedback): Make it Impersonal, Specific, and Temporary.
  • Instead of: “You are sloppy.” (Personal/Permanent)
  • Say: “This specific module (Specific) missed the edge-case validation (Impersonal) in this sprint (Temporary).”
• When praising: Do the opposite. Make it Personal, General, and Permanent.
  • “You (Personal) have a great eye for system reliability (General). That was a solid catch that shows your long-term growth (Permanent).”

Debugging Your Resilience

Engineering is hard enough without your own brain working against you.

The next time you face a difficult bug or a harsh review, pause and check your explanatory style. Are you making it personal? Are you making it permanent?

Resilience is just like coding. It requires debugging, refactoring, and constant iteration. But unlike code, this is one system you can never fully deprecate.

For a deeper dive, I highly recommend Reg Braithwaite’s summary of Learned Optimism on Github, or picking up Dr. Seligman’s book.