The best education your developers never got

I didn’t start my career thinking I’d one day be yelled at by a stranger because a button didn’t do what they expected. Or that I’d have managers calling me demanding to know why someone’s data had "f%$ked off into the ether”, as though the system had achieved sentience and developed a personal grudge.

But here we are.

If you’ve never supported software, you probably imagine an inbox with a few polite bug reports. Maybe a suggestion here, a gentle query there. Lovely.

What you actually get is a crash course in human emotion under duress.

That’s where developers really learn how software works - not on their expensive laptops in perfect conditions, but in the messy, angry, unpredictable wild.

The moment everything falls apart

You can write code for years without realising what it’s like on the support side of the fence. The side where user emotions are raw, stakes are high, and people have absolutely no interest in whether your sprint velocity improved this quarter.

I still remember the emails.

• The angry ones.
• The ones written entirely in CAPITAL LETTERS.
• The ones that arrive at 6:13am before you’ve had a Red Bull and are essentially hate mail directed at a function you refactored three months ago.

And then there are the managers who absolutely lose their shit because a user spent hours entering data that “just disappeared”. You try to explain that the workflow wasn’t designed to do that, or that their browser session expired, or that pressing back three times and refreshing does not do what they think it does.

They don’t care. They’ve lost tens of thousands of dollars. And they want someone - ideally you - to explain how this could possibly happen in software that was “done”.

Nothing teaches you faster. Nothing teaches you harder.

It’s character building in the same way being chased by a magpie is “good exercise”.

Support is the real classroom

Once you’ve spent time supporting a live product - not imagining support, not simulating it, actually living inside it - your entire perspective shifts.

You start to realise:

Logs are not optional.

They’re the forensic evidence you need when someone insists the system “ate” their data. Without logs, you’re arguing with ghosts.

Metrics are oxygen.

You suddenly care deeply about memory spikes, queue lengths, request times, error ratios, and that one mysterious metric that starts climbing for no reason at 2am.

Monitoring helps prevent disasters.

A simple alert can save you from an awkward call where someone asks, “How long has the system been down?” and you realise the truthful answer is, “Longer than I’d like to admit.”

User behaviour is chaos.

You build a feature expecting users to do A → B → C. In production, they do B → C → X → pray → restart their computer.

Designing software without ever supporting it is like parenting by only reading the books, and never raising a child.

In theory, it’s all very orderly. In reality, something shitty is happening, and someone is crying.

Developers who only build don’t know how to build for reality

When a developer has never supported a product, they tend to think:

• “The requirements were met. Job done.”
• “This edge case is unlikely.”
• “The logs are fine, I only needed then to test this worked anyway”
• “We don’t need that alert - we’ll notice the issue.”

This is how systems go down silently at 3am. This is how users lose work. This is how expensive, reputation-denting mistakes happen.

A developer who has felt production pain starts coding differently:

• They add logs everywhere because every missing log becomes a future argument.
• They write error messages with the clarity of someone who has been yelled at.
• Exceptions are really that, an exception, something completely unexpected.
• They guard against edge cases because they’ve learned users live in edge cases.
• They create dashboards and alerts before adding fancy features.
• They think about recovery steps, not just happy paths.

Support turns developers into grown-ups, sometimes traumatised grown-ups, but grown-ups nonetheless.

The product mindset or owning your shit

Support forces a shift from project mindset to product mindset.

Project mindset: “We built it. Ship it. Move on.”

Product mindset: “We built it. Now we protect it, improve it, and learn from it.”

Project thinking is tidy, convenient, and great for executive presentations.

Product thinking is messy and real, because it acknowledges that software is never finished, and that users will always find new and exciting ways to break things.

If you’ve never supported a system, you can’t truly design a good one.

You don’t know what’s coming.

You haven’t lived through the 2am outage, the frantic rollback, the weird bug triggered only by people using Internet Explorer 9 on a hospital kiosk.

You’re doing software wrong unless your developers know the world beyond the Dev, Test and UAT.

In the end, you’ll still be wrong - just less wrong than before

Supporting your own software doesn’t make you perfect.

It makes you humble.
It makes you aware.
It makes you better.

You will still be wrong.
Users will still complain.
Something will still go wrong at an inconvenient time involving a stakeholder who begins every sentence with “I thought we agreed…”

But developers who’ve supported their own work are wrong in smarter ways. They’re wrong with better logs, better alerts, and better assumptions. They’re wrong - but recoverable.

And that’s the quiet truth behind Doing Software Wrong:

You’ll never do it right in everyone’s eyes. But supporting what you build gives you a fighting chance of doing it less wrong than the day before.