Why developers panic when 'it doesn't work' (while normal people just get on with their lives)

The other day in the kitchen: the coffee machine is on strike. My wife says: "The coffee machine isn't working." Done. End of error analysis.

Me on the other hand:

"What exactly do you mean by 'doesn't work'? Is the LED lit? What color? Does it make a noise? Have you photographed the error message? How long has the problem been occurring? Can you reproduce it? What were the last changes to the system?"

My wife looks at me as if I've just tried to talk to the toaster on the phone.

Welcome to the parallel world of developers - where "it doesn't work" is not a statement, but the start of a debugging marathon lasting several hours.

The world in which normal people live (and we don't)

Situation 1: The restaurant visit

Normal people:

"The food was delicious."

Developer:

"Define 'delicious'. On a scale of 1-10? What specific flavor components? Temperature at serving? Consistency? Would you rate that as reproducible or was that an edge case?"

Normal people just order the same thing again. Developers create a 23-page spreadsheet with weighted evaluation criteria and perform A/B tests between different dishes.

Situation 2: The directions

Normal people:

"Just go straight, then eventually turn left."

Developers:

"After how many meters turn left? At which intersection exactly? Are there any landmarks? What do I do if there is a detour? Have you tested the route? Under what conditions? Daylight or darkness? What is the traffic situation normally like?"

Normal people get there anyway. Developers first create a specification for the route description, including error handling and rollback strategy.

Situation 3: Dating

Normal people:

"Let's go out for a drink sometime."

Developer:

"Define 'sometime'. This week or next? What day of the week? Time preferences? Location requirements? And what does 'what' mean? Coffee, beer, wine, whiskey? Hot or cold? Sparkling or still?"

I have a developer colleague who attached an Excel spreadsheet with date windows to his date request. She didn't reply. He said: "Probably a timeout."

TYPO3 support hell: a lesson in communication

Every TYPO3 developer's nightmare

Monday, 9:15 am. The email:

"Hello, the website is not working. Please fix it quickly. Thank you."

What the developer is going through inside:

Breaking out in a sweat. The website? WHICH page? Front end? Backend? For all users? For a specific user? In which browser? On which device? What does "does not work" mean? White screen? Error message? Strange behavior? SINCE WHEN?

The next 4 hours:

• 12 queries to the customer
• 3 "You would have to tell me that in more detail"
• 1 desperate attempt to develop clairvoyant abilities
• 47 possible scenarios played out

The real problem:

The customer had entered their password incorrectly. The website worked perfectly.

What developers actually need

"Hello, I have been unable to log in to the backend since around 9 a.m. this morning. I get the error message 'Invalid credentials'. The password is correct, I copied it from my password manager. Browser: Chrome 141.0.7390.123 on Windows 11. Screenshot attached. The login still works for my colleague Müller."

Reaction from the developer:

Tears of joy. "That's the best error description I've seen since 2019. Can we get married?"

Why developers actually tick like this (the almost serious part)

The thing is: we're not crazy. We're traumatized.

The semicolon trauma

A missing semicolon can mean three hours of debugging. THREE. HOURS. Because of one CHARACTER.

After the fifth time, you're sitting in front of your code at 11pm, staring at 847 lines and thinking: "Somewhere here... somewhere... there's a fucking semicolon missing."

That changes a person. Forever.

"It works for me" - The four most terrible words

Customer: "It doesn't work for me."

Developer: "It works for me."

This is the beginning of a journey to hell. Because now the game begins: "Find the one tiny difference between your system and mine that breaks everything."

Possible causes:

• Browser version (oh, you're still using Firefox 52?)
• Cache (did you press Ctrl+F5 or just F5?)
• PHP version
• TYPO3 version
• Extension conflict
• Moon phase
• Whim of the server
• Cosmic radiation

The trigger phrases that cause developers to panic

"Do it quickly"

There is no such thing as "quickly". There is only "thorough" and "broken". Choose wisely.

"It can't be that hard"

Yes, it can be. It is. It will be.

"Can't you just..."

No. No, I can't "just". Nothing is "simple". Everything is complex, has dependencies and can go wrong in 47 different ways.

The other side: What WE can learn from "normal people"

In our defense: Yes, we are annoying sometimes. I admit it.

The "good enough" principle

Normal people: "That's good enough."

Developers: "But if we implement error handling here in case someone operates the application under water..."

Sometimes "good enough" really is good enough. Not often. But sometimes.

Communication without technical terms

My mother asks: "What do you do for a living?"

Me: "I implement content management systems with PHP-based frameworks using modern DevOps practices."

My mother: "...I see."

Could have said: "I build websites." Would have been more honest.

The "just let it be" gene

Normal people can accept things that aren't perfect. Developers see a pixel misalignment and can't sleep until it's fixed.

At 3 o'clock in the morning.

At the weekend.

On Mallorca.

The happy medium: How to talk to developers without freaking them out

For non-developers: the magic words

Instead of: "It doesn't work."

Better: "I get error message X when I do Y."

Instead of: "Do it quickly."

Better: "How urgent is urgent? And what do we have to leave out?"

Instead of: "That used to work."

Better: "It's been different since [date/event]."

For developers: How to stop being annoying

Not every coffee machine needs a debugging protocol.

Not every route description needs GPS coordinates.

Not every restaurant needs a rating framework.

Sometimes, "Okay, I'll check it out" is enough.

The confession: We can't help it

The truth is: we KNOW that we sometimes exaggerate. We KNOW that "the coffee machine doesn't work" is a perfectly adequate statement.

But we can't help it.

We've spent too many hours looking for faults caused by vague descriptions. We've heard "it doesn't work" too many times and then realized that the user just clicked on the wrong button.

We're not being pedantic because we want to be. We are pedantic because we HAVE to be.

One missing detail can mean the difference between 10 minutes and 10 hours of work.

Conclusion: A plea for more understanding (in both directions)

For the "normal people"

If a developer asks annoying questions - he really just wants to help. Promise. He's not being pedantic to annoy you. He's just trying not to spend the next 6 hours in the dark looking for a bug that you could have described in one sentence.

For the developers

Sometimes "it doesn't work" is really all the user knows. And that's okay. That's what we're here for. We don't have to debug every area of life. The coffee machine can just be "broken" without us opening a ticket.

The universal truth

Developers are not funny. Their world is simply more precise, more structured and more error-prone. In this world, context isn't perfectionism, it's self-protection.

But maybe - just maybe - we could all become a little more relaxed.

Ordinary people a little more precise.

Developers a little more relaxed.

And then there would be fewer misunderstandings, less frustration and maybe even... more working coffee machines.

---

P.S.: While I was writing this article, my wife said: "The Wi-Fi isn't working."

I took a deep breath.

And then asked, "On which device?"

Old habits die hard.

---

Do you know this too? Share your best "It's not working" stories in the comments. Or on LinkedIn. Or by email. With a full description of the error, of course.

Back