When the Green Charts Make You Write Garbage Code

The absolute worst production outage I ever caused didn’t happen when I was panicked or running on two hours of sleep. It happened right after three consecutive weeks of flawless deployments.

We had just shipped a major feature, response times were down, users were happy, and the client was tossing compliments around like confetti. I felt unstoppable. So, when it came time to push a database schema update that Friday evening, I didn't bother running the migration script on a staging environment first. Why would I? Everything I touched that month was turning to gold.

Ten minutes later, the DB locked up, production went dark, and I spent half my weekend locked in a cold room in Gbagada trying to restore backups.

I was thinking about that outage while reading a piece by Nadav, a systematic crypto trader, who broke down why winning streaks are actually the most dangerous phase for a trader. He talked about the "house money effect"—a psychological trap where early gains make you treat future risk like it's free money.

Turns out, software developers suffer from the exact same brain rot.

Good Outcomes Hide Bad Engineering

When things are going well, you get hit with a dose of dopamine that slowly erodes your discipline. Nadav pointed out something that hit home: good outcomes hide bad process.

In trading, a lucky leverage play makes you think you’re a financial genius. In software, getting 5,000 signups on launch day makes you think your messy PHP script running on a $5 DigitalOcean droplet is elite engineering. It isn’t. You just haven't hit the load threshold that breaks it yet.

A couple of years back, a friend and I were building a light payment routing service out in an Akure tech hub. Traffic was steadily climbing, revenue was popping, and we felt like we had cracking the code figured out. Because we were "winning," we started taking stupid liberties. We skipped writing unit tests for new endpoints. We pushed straight to main. We swapped out simple, reliable SQL queries for complex ORM methods without checking the query execution plan.

We were playing with "house money." The app was making profit, so who cared if the codebase was getting sloppy?

Sapa is patient, but technical debt is even more patient. The moment a local micro-influencer tweeted about our app and sent 10,000 concurrent requests our way, those hidden N+1 query disasters surfaced all at once. The server didn't just crash; it choked, burned through memory, and died.

Overconfidence Is an Expensive Habit

In Nadav's breakdown, he mentioned a famous study by Barber and Odean showing that the most active traders earned significantly less than the market average because overconfidence drove them to trade too much, size up too big, and ignore their own risk parameters.

Translate that to building tech products:

• Overconfidence in Dev: Spinning up a full Kubernetes cluster and microservices architecture for an MVP that only has 100 active users.
• Overconfidence in Scaling: Upgrading server specs to mask inefficient code instead of refactoring the bad endpoints.
• Overconfidence in Process: Deciding that "we move fast here" is a valid reason to skip code reviews.

It’s the same disease. You start taking shortcuts because your recent history hasn't punished you for them yet. But the market—and production environments—always collect their tax eventually.

Protecting Your Codebase From Yourself

Nadav’s solution for trading is to trade systematically—take the human brain out of the execution loop entirely and fix risk parameters so they don't change whether you're up 50% or down 20%.

For developers, that means building guardrails that don't care about your mood or your recent winning streak.

Your CI/CD pipeline shouldn't care that your last ten deployments were flawless. If the test coverage drops below 80%, the build fails. End of story. Your linter shouldn't give you a pass because you're a founder who "needs to ship fast tonight."

If you rely on your own discipline when you're feeling on top of the world, you will eventually burn the house down. Build automated gates instead. Make the process boring, because boring systems are the only ones that survive when the hype fades away.