Logo von martinzoeller.com mit den Buchstaben „MZ“ in Weiß auf dunkelblauem Hintergrund.

Debugge dein Team wie deinen Code

7. Juli 2026 1 Min. Lesezeit
Portrait von Martin Zöller

Martin Zöller

Hör auf die Fehlermeldungen in deinem Team!

Als Engineers schauen wir häufig in die Logs unserer Programme und finden dort Fehlermeldungen. Wir erwarten, dass unser Programm funktioniert. Eine Fehlermeldung ist ein unerwartetes Problem. Wenn wir eine Fehlermeldung lesen, denken wir: „Oh, da ist etwas kaputt, das muss ich reparieren“ und dann machen wir das. Für uns fühlt sich das natürlich an.

Auch außerhalb unserer Software gibt es Fehlermeldungen, aber aus irgendeinem Grund gehen wir damit häufig ganz anders um. Wenn in unserem Arbeitsalltag, in unserem Teamgefüge etwas passiert, das wir an einem guten Tag nicht erwarten, ist das eine Fehlermeldung, zum Beispiel:

  • ein Streit zwischen dir und einem Kollegen,
  • eine unklare Anforderung, durch die wir eine Erwartung nicht erfüllen,
  • eine Frist, die wir verschieben müssen.

Statt dass wir auch hier den Impuls haben, diesen Fehler zu reparieren, passiert oft eines der beiden folgenden Dinge:

(1) Wir geben uns selbst die Schuld und machen ihn zu einem persönlichen Versagen.

(2) Wir überbewerten den Fehler, sehen darin eine größere Krankheit und wollen grundsätzliche Veränderungen.

Beide Reaktionen sind in meinen Augen der falsche Ansatz, und die Maßnahmen dahinter sind zudem wesentlich anstrengender als ein gesunder Umgang: Wer Fehler auf sich selbst bezieht, greift sich selbst als Individuum an und macht seinen eigenen Alltag damit sehr viel schwerer als notwendig. Wer große Veränderungen fordert und umsetzt, geht eine ebenso große Wette ein, dass diese Veränderung das Kernproblem behebt – ein hohes Risiko mit ungewissem Ausgang.

Wenn unsere Software eine Fehlermeldung liefert, geben wir weder der Software die Schuld, noch schreiben wir sie deswegen sofort um (außer die Rust-Jungs unter euch – jk).

Warum machen wir es im Teamgefüge oft anders? Auch hier können wir den Fehler isolieren, die Ursache suchen und anschließend nur diese beheben. Mehr nicht. Machen wir das einmal, haben wir ein Problem weniger und niemand muss sich deswegen fertigmachen. Machen wir das zur Gewohnheit, schaffen wir schrittweise die große Veränderung, die wir uns vielleicht manchmal wünschen. Nur fühlt sie sich nicht so groß, nicht so anstrengend und nicht so riskant an, weil sie nichts davon ist.

Zurück zu allen Artikeln
Teilen

Verwandte Artikel

Handverlesene Artikel zu eng verwandten Themen.

Updates zu Agentic Software Engineering bekommen

Lass dich benachrichtigen, wenn ich neue Insights über Agentic Coding in der Softwareentwicklung veröffentliche. Du kannst das jederzeit abbestellen.

Deine E-Mail-Adresse wird nicht an Dritte weitergegeben.