Warum Entwickler bei 'Es funktioniert nicht' in Panik verfallen (während normale Menschen einfach weiterleben)

Neulich in der Küche: Die Kaffeemaschine streikt. Meine Frau sagt: "Die Kaffeemaschine geht nicht." Fertig. Ende der Fehleranalyse.

Ich hingegen:

"Was genau meinst du mit 'geht nicht'? Leuchtet die LED? Welche Farbe? Macht sie Geräusche? Hast du die Fehlermeldung fotografiert? Seit wann tritt das Problem auf? Kannst du es reproduzieren? Was waren die letzten Änderungen am System?"

Meine Frau schaut mich an, als hätte ich gerade versucht, mit dem Toaster zu telefonieren.

Willkommen in der Parallelwelt der Entwickler – wo "es funktioniert nicht" keine Aussage ist, sondern der Beginn eines mehrstündigen Debugging-Marathons.

Die Welt, in der normale Menschen leben (und wir nicht)

Situation 1: Der Restaurantbesuch

Normale Menschen:

"Das Essen war lecker."

Entwickler:

"Definiere 'lecker'. Auf einer Skala von 1-10? Welche spezifischen Geschmackskomponenten? Temperatur bei Servierung? Konsistenz? Würdest du das als reproduzierbar einschätzen oder war das ein Edge Case?"

Normale Menschen bestellen einfach das Gleiche nochmal. Entwickler erstellen ein 23-seitiges Spreadsheet mit gewichteten Bewertungskriterien und machen A/B-Tests zwischen verschiedenen Gerichten.

Situation 2: Die Wegbeschreibung

Normale Menschen:

"Fahr einfach geradeaus, dann irgendwann links."

Entwickler:

"Nach wie vielen Metern links? An welcher Kreuzung genau? Gibt es Landmarks? Was mache ich, wenn eine Umleitung ist? Hast du die Route getestet? Unter welchen Bedingungen? Tageslicht oder Dunkelheit? Wie ist die Verkehrslage normalerweise?"

Normale Menschen kommen trotzdem an. Entwickler erstellen erst ein Pflichtenheft für die Wegbeschreibung, inklusive Fehlerbehandlung und Rollback-Strategie.

Situation 3: Dating

Normale Menschen:

"Lass uns irgendwann mal was trinken gehen."

Entwickler:

"Definiere 'irgendwann'. Diese Woche oder nächste? Welcher Wochentag? Uhrzeit-Präferenzen? Location-Requirements? Und was bedeutet 'was'? Kaffee, Bier, Wein, Whiskey? Heiß oder kalt? Mit oder ohne Kohlensäure?"

Ich habe einen Entwickler-Kollegen, der seiner Date-Anfrage eine Excel-Tabelle mit Terminfenstern beigelegt hat. Sie hat nicht geantwortet. Er meinte: "Wahrscheinlich ein Timeout."

Die TYPO3-Support-Hölle: Ein Lehrstück in Kommunikation

Der Alptraum jedes TYPO3-Entwicklers

Montag, 9:15 Uhr. Die E-Mail:

"Hallo, die Website funktioniert nicht. Bitte schnell beheben. Danke."

Was der Entwickler innerlich durchmacht:

Schweißausbruch. Die Website? WELCHE Seite? Frontend? Backend? Für alle User? Für einen speziellen User? In welchem Browser? Auf welchem Gerät? Was bedeutet "funktioniert nicht"? Weißer Bildschirm? Fehlermeldung? Seltsames Verhalten? SEIT WANN?

Die nächsten 4 Stunden:

• 12 Rückfragen an den Kunden
• 3 "Das müssten Sie mir schon genauer sagen"
• 1 verzweifelter Versuch, hellseherische Fähigkeiten zu entwickeln
• 47 mögliche Szenarien durchgespielt

Das eigentliche Problem:

Der Kunde hatte sein Passwort falsch eingegeben. Die Website funktionierte einwandfrei.

Was Entwickler eigentlich bräuchten

"Hallo, seit heute Morgen ca. 9 Uhr kann ich mich im Backend nicht mehr anmelden. Ich bekomme die Fehlermeldung 'Invalid credentials'. Das Passwort ist korrekt, ich habe es aus meinem Passwort-Manager kopiert. Browser: Chrome 141.0.7390.123 auf Windows 11. Screenshot im Anhang. Bei Kollegin Müller funktioniert die Anmeldung noch."

Reaktion des Entwicklers:

Freudentränen. "Das ist die schönste Fehlerbeschreibung, die ich seit 2019 gesehen habe. Können wir heiraten?"

Warum Entwickler eigentlich so ticken (der fast schon ernsthafte Teil)

Die Sache ist: Wir sind nicht verrückt. Wir sind traumatisiert.

Das Semikolon-Trauma

Ein fehlendes Semikolon kann drei Stunden Debugging bedeuten. DREI. STUNDEN. Wegen einem ZEICHEN.

Nach dem fünften Mal sitzt du um 23 Uhr vor deinem Code, starrst auf 847 Zeilen und denkst: "Irgendwo hier... irgendwo... fehlt ein verdammtes Semikolon."

Das verändert einen Menschen. Für immer.

"Es funktioniert bei mir" – Die vier schrecklichsten Worte

Kunde: "Bei mir geht es nicht."

Entwickler: "Bei mir funktioniert es."

Das ist der Beginn einer Reise in die Hölle. Denn jetzt beginnt das Spiel: "Finde den einen winzigen Unterschied zwischen deinem System und meinem, der alles kaputtmacht."

Mögliche Ursachen:

• Browser-Version (oh, Sie nutzen noch Firefox 52?)
• Cache (haben Sie Strg+F5 gedrückt oder nur F5?)
• PHP-Version
• TYPO3-Version
• Extension-Konflikt
• Mondphase
• Laune des Servers
• Kosmische Strahlung

Die Trigger-Sätze, die Entwickler in Panik versetzen

"Mach mal schnell"

Es gibt kein "schnell". Es gibt nur "gründlich" und "kaputt". Wähle weise.

"Das kann doch nicht so schwer sein"

Doch. Kann es. Ist es. Wird es sein.

"Kannst du nicht einfach..."

Nein. Nein, ich kann nicht "einfach". Nichts ist "einfach". Alles ist komplex, hat Abhängigkeiten und kann auf 47 verschiedene Arten schiefgehen.

Die andere Seite: Was WIR von "normalen Menschen" lernen können

Zu unserer Verteidigung: Ja, wir nerven manchmal. Ich geb's zu.

Das "Good Enough"-Prinzip

Normale Menschen: "Das reicht so."

Entwickler: "Aber wenn wir hier noch die Fehlerbehandlung für den Fall implementieren, dass jemand die Anwendung unter Wasser bedient..."

Manchmal ist "gut genug" wirklich gut genug. Nicht oft. Aber manchmal.

Kommunikation ohne Fachbegriffe

Meine Mutter fragt: "Was machst du beruflich?"

Ich: "Ich implementiere Content-Management-Systeme mit PHP-basierten Frameworks unter Verwendung moderner DevOps-Praktiken."

Meine Mutter: "...Aha."

Hätte auch sagen können: "Ich baue Websites." Wäre ehrlicher gewesen.

Das "Lass-doch-einfach-sein"-Gen

Normale Menschen können Dinge hinnehmen, die nicht perfekt sind. Entwickler sehen einen Pixel-Versatz und können nicht schlafen, bis er behoben ist.

Um 3 Uhr nachts.

Am Wochenende.

Auf Mallorca.

Der goldene Mittelweg: Wie man mit Entwicklern spricht, ohne dass sie durchdrehen

Für Nicht-Entwickler: Die magischen Worte

Statt: "Es geht nicht."

Besser: "Ich bekomme Fehlermeldung X, wenn ich Y mache."

Statt: "Mach mal schnell."

Besser: "Wie dringend ist dringend? Und was müssen wir dafür weglassen?"

Statt: "Das hat doch früher funktioniert."

Besser: "Seit [Datum/Ereignis] verhält es sich anders."

Für Entwickler: Wie man aufhört, nervig zu sein

Nicht jede Kaffeemaschine braucht ein Debugging-Protokoll.

Nicht jede Wegbeschreibung braucht GPS-Koordinaten.

Nicht jedes Restaurant braucht ein Bewertungs-Framework.

Manchmal reicht: "Okay, ich schau's mir an."

Das Geständnis: Wir können nicht anders

Die Wahrheit ist: Wir WISSEN, dass wir manchmal übertreiben. Wir WISSEN, dass "die Kaffeemaschine geht nicht" eine vollkommen ausreichende Aussage ist.

Aber wir können nicht anders.

Wir haben zu viele Stunden damit verbracht, Fehler zu suchen, die durch vage Beschreibungen entstanden sind. Wir haben zu oft "Es funktioniert nicht" gehört und dann festgestellt, dass der User einfach nur auf den falschen Button geklickt hat.

Wir sind nicht pedantisch, weil wir es sein wollen. Wir sind pedantisch, weil wir es sein MÜSSEN.

Ein fehlendes Detail kann den Unterschied zwischen 10 Minuten und 10 Stunden Arbeit bedeuten.

Fazit: Ein Plädoyer für mehr Verständnis (in beide Richtungen)

Für die "normalen Menschen"

Wenn ein Entwickler nervige Rückfragen stellt – er will wirklich nur helfen. Versprochen. Er ist nicht pedantisch, um dich zu ärgern. Er versucht nur, nicht die nächsten 6 Stunden im Dunkeln nach einem Fehler zu suchen, den du mit einem Satz hättest beschreiben können.

Für die Entwickler

Manchmal ist "es geht nicht" wirklich alles, was der User weiß. Und das ist okay. Dafür sind wir ja da. Wir müssen nicht jeden Lebensbereich debuggen. Die Kaffeemaschine darf auch mal einfach "kaputt" sein, ohne dass wir ein Ticket aufmachen.

Die universelle Wahrheit

Entwickler sind nicht komisch. Ihre Welt ist einfach präziser, strukturierter und fehleranfälliger. In dieser Welt ist Kontext nicht Perfektionismus, sondern Selbstschutz.

Aber vielleicht – nur vielleicht – könnten wir alle ein bisschen entspannter werden.

Die normalen Menschen ein bisschen präziser.

Die Entwickler ein bisschen gelassener.

Und dann gäbe es weniger Missverständnisse, weniger Frust und vielleicht sogar... mehr funktionierende Kaffeemaschinen.

---

P.S.: Während ich diesen Artikel geschrieben habe, hat meine Frau gesagt: "Das WLAN geht nicht."

Ich habe tief durchgeatmet.

Und dann gefragt: "Auf welchem Gerät?"

Alte Gewohnheiten sterben schwer.

---

Kennst du das auch? Teile deine besten "Es-funktioniert-nicht"-Geschichten in den Kommentaren. Oder auf LinkedIn. Oder per E-Mail. Mit vollständiger Fehlerbeschreibung natürlich.

Zurück