Verständnis statt Verwirrung: Wie 'Das kommt darauf an' die Zusammenarbeit in der Software entwicklung stärkt

Es gibt wohl keine Aussage, die ein (guter) Senior-Entwickler häufiger sagt als: „Das kommt darauf an“. Für viele mag das nur eine Phrase sein, ein Allheilmittel, um den Gegenüber schnellstmöglich wieder loszuwerden. Auch ich durfte schon unzählige Male in genervte Gesichter blicken, weil ich scheinbar eine simple Frage mit dieser Phrase versucht habe abzuschmettern. Umso schöner ist das Erlebnis für mich, wenn sich die Gesichtszüge erhellen und aus Unverständnis Erleuchtung wird.

Eine Sache kann ich dir auf jeden Fall versprechen: “Das kommt darauf an” löst nicht deine Probleme und du wirst durch die Verwendung nicht automatisch zu einem besseren Senior, aber wenn du den Sinn dahinter einmal verstanden hast, kann die Verwendung dir ganz neue Wege des Verständnisses, der Gesprächsführung und der Zusammenarbeit mit deinem Team eröffnen.

Wenn du lernen möchtest, wie du diese “Phrase” als Hilfsmittel für deinen Alltag einsetzen kannst, dann bleib unbedingt dran.

Der Kontext ergibt das Missverständnis

Um den Sinn dahinter zu verstehen, müssen wir zunächst ein wenig in die menschliche Kommunikation eintauchen und uns mit dem Thema Kontext von Fragen und Antworten auseinandersetzen. Ich wähle hier bewusst ein plakatives Beispiel, dass sich nicht auf Software bezieht und so in der Realität hoffentlich niemals vorkommt. Stell dir folgende Situation vor:

Dein Mitbewohner Fabian ist bereit, die Wohnung zu verlassen. Weil er weiß, dass du regelmäßig deine Wetter-App checkst und dich gerne mit dem Wetter beschäftigst, fragt er dich:

"Brauche ich einen Regenschirm?"

Nach einem Blick aus dem Fenster und auf deine Wetter-App bist du dir sicher, dass es später regnen wird. Also antwortest du Fabian:

"Ja, sonst wirst du nass"

Am nächsten Tag ist strahlend blauer Himmel, die Sonne scheint und du entschließt dich, mit Fabian in den Park zum Grillen zu gehen. Also packt ihr alles zusammen und macht euch auf den Weg. Dabei fällt dir auf, dass Fabian seinen Regenschirm dabei hat. Du fragst ihn also, warum er ihn eingepackt hat. Die Antwort kommt prompt und voller Überzeugung

"Ich brauche den Schirm, sonst werde ich nass!"

Was ist hier passiert? Vermutlich denkst du jetzt, dass Fabian nicht gerade die hellste Kerze auf der Torte ist. Denk an meine Worte zu Beginn: Dieses Beispiel ist etwas konstruiert.. Die Frage hätte also auch in Bezug auf die Softwareentwicklung  lauten können: 

"Soll ich eine Variable mit const oder let deklarieren?" oder "Welche Sprache soll ich für das Backend verwenden?". 

Das Beispiel  läuft auf dasselbe hinaus: Fabian verwendet für alle Variablen ein const und programmiert alle Backends in PHP. 

Bleiben wir  aber erstmal bei unserem Schirm-Beispiel.

Wir wollen Fabian an dieser Stelle nicht verurteilen und betrachten einmal den Auslöser für dieses Missverständnis.

Ich habe dieses Kapitel “Der Kontext ergibt das Missverständnis" genannt. Unsere Gehirne funktionieren im Bereich der Kommunikation häufig recht ähnlich. Wenn du eine Information erhältst, wird diese in deinem Kopf mit zusätzlichen Informationen angereichert. In vielen Bereichen ist das auch sehr hilfreich und macht unsere Kommunikation erst möglich.

In unserem Beispiel könnte sich aus der Frage von Fabian für dich folgender Kontext ergeben:

• Wenn man bei Regen raus geht, wird man nass

• Wenn es regnet und man keinen Schirm hat, wird man nass

• Fabian möchte nicht nass werden

Da dieser Kontext für dich logisch ist, leitest du dadurch indirekt die Frage ab: “Wird es heute regnen?”. Das ist es, was ich einen “unterstellten Kontext” nenne. Du nimmst aufgrund deiner Erfahrungen an, dass sich eine Frage auf diesen Kontext bezieht.

Aber kannst du dir sicher sein, dass Fabian tatsächlich wissen wollte, ob es regnen wird? Ist er aufgrund seiner Erfahrung überhaupt in der Lage, diesen Kontext zu kennen? Oder möchte er eventuell auf etwas ganz anderes hinaus?

Fakt ist: Du kannst es nicht wissen.

Mit der Antwort “Ja, sonst wirst du nass” nimmt das Missverständnis seinen Lauf. Indem du dein “Ja” mit der Ergänzung “sonst wirst du nass” erweitert hast, gibst du einen Teil des von dir unterstellten Kontextes an Fabian weiter. Für ihn ergibt sich aus deiner Antwort folgende Information:

• Wenn ich raus gehe, brauche ich einen Schirm.

• Wenn ich ohne Schirm raus gehe, werde ich nass.

Jetzt könntest du unterstellen, dass es selbstverständlich ist, dass Fabian deinen Kontext erkennt. Lass mich das mit einem Beispiel aus der Praxis verdeutlichen:  

Stell dir vor, dass Fabian der neue Junior-Entwickler im Team ist. Dinge, die für dich selbstverständlich sind, sind für ihn völliges Neuland. Er kommt nun auf dich zu und fragt dich, ob er ein Feature für eure Webseite in NodeJS oder PHP entwickeln soll und du antwortest “PHP, das ist schneller”.

Für dich war in dem Moment klar, dass “schneller” in diesem Kontext bedeutet, dass es eine kürzere Entwicklungszeit benötigt, weil der Rest der Webseite auch in PHP entwickelt wurde. Fabian könnte jetzt davon ausgehen, dass eine Webseite in PHP immer eine schnellere Antwortzeit hat, als eines in NodeJS.

In diesem Beispiel hättest du einen Kontext unterstellt, der auch zu klaren Missverständnissen führt.

Was können wir also tun?

Stelle immer klar, was dein Kontext ist

Ein erster Schritt, um in unserer Regenschirm-Situation Fabian helfen zu können, wäre es, deine Antwort genauer zu gestalten. Oben hatten wir als Antwort folgendes gewählt:

Ja, sonst wirst du nass!

Bei der Beantwortung dieser Frage hatten wir vorher als Kontext unterstellt, dass Fabian nicht nass werden möchte und unser Wissen, dass es später noch regnen wird. Für die Antwort ist es jetzt wichtig, dass du alle wichtigen Informationen, die du unterstellst, auch in deiner Antwort verwendest. So könnte deine Antwort aussehen: 

Es wird heute noch regnen. Wenn du nicht nass werden möchtest, solltest du einen Schirm mitnehmen.

So gibst du Fabian die Chance, deine Antwort einzuordnen. Er kann somit nachvollziehen,  warum du ihm diesen Rat gibst und dir sagen, ob seine Frage damit beantwortet ist.

Es kommt auf die Frage an

In allen Beispielen war es bisher recht einfach den Kontext zu erkennen und der Spielraum für Fehlinterpretationen relativ gering.

Aber wenn wir ehrlich sind, gibt es in der Softwareentwicklung fast keine Frage, die sich einfach nur mit “Ja” oder “Nein” beantworten lässt. Trotzdem wird genau das von uns Softwareentwicklern häufig erwartet. Es gibt für fast alles mehr als eine “korrekte” Lösung. Und eine Lösung, die in einer Situation sinnvoll ist, ist es nicht automatisch in einer anderen.

Wenn du jetzt damit beginnst, in allen Situationen einen Kontext zu unterstellen, wird das für dich unheimlich anstrengend, aber auch dein Gegenüber wird zwangsläufig häufig Antworten bekommen, die ihn gar nicht interessieren. Das wird für beide Seiten langfristig sehr frustrierend werden.

Was können wir also tun, damit wir weniger Kontext unterstellen müssen?

Lass uns dazu einfach auf Fabians Frage, ob er einen Schirm braucht, mit folgender Aussage antworten:

Das kommt darauf an!

Welche Möglichkeiten bekommt er durch diese Antwort? Es könnte ein trockenes “Worauf?” erwidern, was tatsächlich auch die häufigste Antwort ist. Wenn du Glück hast, wird er dir aber direkt erklären, worum es ihm tatsächlich geht. So könnte er dir seine Frage wie folgt konkretisieren:

Ich fahre ins Büro zu einem Termin mit einem wichtigen Kunden. Da möchte ich gerne vernünftig aussehen und nicht nass sein, wenn ich dort ankomme. Deswegen werde ich auch das Auto für die 10 Minuten Fahrt nehmen.

Mit diesem zusätzlichen Kontext, den Fabian dir gibt, musst du weniger unterstellen. Wir erkennen so auch den ersten Irrtum in unserer ursprünglichen Unterstellung. Fabian ist nur für den Weg zum Auto und für den Weg vom Auto ins Büro draußen. Da du sicher bist, dass es erst heute Abend regnen wird, kannst du deine Antwort entsprechend anpassen. Schließlich wird Fabian in den nächsten 10 Minuten auch ohne Schirm trocken bleiben.

Merk dir also Folgendes: Wenn du einen Ratschlag gibst, vergewissere dich, dass der Ratschlag auch zu der Frage passt, die dir gestellt wurde.

Und an dieser Stelle merkst du, dass es unglaublich wichtig ist, die richtigen Fragen zu stellen. Besonders auf deiner Reise zum Entwickler, ist dies ein wichtiger Soft-Skill, den du erlernen musst.

Wie macht dich das zu einem besseren Senior

Ich habe dir zu Beginn versprochen, dass dich die wahre Bedeutung  hinter “Das kommt darauf an” zu einem besseren Senior machen wird. Um das zu erkennen, musst du zunächst verstehen, dass es nicht nur darauf ankommt, exzellenten Code zu schreiben oder komplexe technische Probleme zu lösen. Als Senior hast du auch die Verantwortung, dein Wissen an andere Entwickler weiterzugeben, diese zu fördern und weiterzuentwickeln. In einem gewissen Maß kommt diese Verantwortung auch zum Tragen, wenn du Ratschläge gibst oder Kollegen sogar anleitest.

Einer der Unterschiede zwischen einem erfahrenen Entwickler und einem guten Senior liegt demnach in der Fähigkeit, Wissen zu vermitteln, Kollegen anzuleiten und steuernd einzugreifen.

Stell dir vor: Du arbeitest in einem Team an einem Online-Shop für ein Unternehmen. Du bist im Team schon länger dabei und Daniel ist als Junior-Entwickler relativ frisch dazu gestoßen. Nach einiger Zeit fragt er dich nach Rat, weil er an einer Stelle nicht weiterkommt.

Ich muss für mein Feature mit der Backend-API des Shops sprechen, aber ich bekomme immer den Code 401 zurück. Woran liegt das?

Du kennst das System gut, bist dir also direkt sicher, dass die Zugangsdaten in der Konfiguration fehlen. Was kannst du jetzt tun?

Eine Variante, die ich früher selber oft gewählt habe, war die Antwort: “Darf ich mal kurz?". Dann habe ich mich selbst an die Tastatur gesetzt und in wenigen Sekunden  das Problem selbst behoben. Im Anschluss war ich noch stolz auf mich, dass ich so schnell helfen konnte und sich Daniel nun um die “echten” Probleme kümmern konnte. Was hat Daniel für sich mitnehmen können? Er weiß, dass du gut bist und seine Probleme für ihn löst.

Problem gelöst = alles gut? Bei weitem nicht! Nächste Woche kommt Daniel mit derselben Frage zu dir und ihr könnt das selbe Spiel erneut spielen. Und so wird es weitergehen.

Die Folge: Du bist irgendwann genervt, dass dir immer dieselben Fragen gestellt werden und Daniel ist genervt, weil er keine Probleme alleine lösen kann. Ob ihr am Ende überhaupt noch miteinander Redet, könnte man in Frage stellen.

Eine etwas bessere Reaktion auf Daniel ́s Problem wäre gewesen, wenn du Daniel gesagt hättest, er sollte die Umgebungsvariablen mit den Zugangsdaten setzen. Du hast nicht aktiv eingegriffen und Daniel hat sein Problem “selber” gelöst.

Also eine Win-win-Situation für alle! Oder doch nicht?

Erinnerst du dich noch an Fabian, der bei gutem Wetter mit dem Schirm rausgeht? Du hast gerade einen Daniel erschaffen, der jedes Mal, wenn der Fehler 401 auftaucht, Umgebungsvariablen setzen wird.

Hilfe zur Selbsthilfe

Konfuzius sagte einst: “Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.”

Deine Aufgabe in dieser Situation ist es also Daniel das Fischen beizubringen. Ein Entwickler hat meiner Meinung nach den besten Lerneffekt, wenn er sich die Antwort selber erarbeitet. Also ist es nicht deine Aufgabe Daniel beizubringen, wie er den Fehler behebt, sondern du unterstützt ihn, selber auf die Lösung zu kommen.

Versuch dich nochmal in die Situation hineinzuversetzen und beantworte seine Frage direkt mit: “Das kommt darauf an”.

Daniel wird zu Beginn vermutlich etwas überrascht sein, schließlich ist er es ja gewohnt, dass du seine Probleme einfach für ihn löst. Also fängt er an, darüber nachzudenken. Vielleicht wird er auch anfangen aufzuzählen, was er schon alles ausprobiert hat, um das Problem zu lösen. Wichtig ist an dieser Stelle, dass du ihm den Raum gibst, frei zu reden. Unterbrich ihn nicht und lass ihn seinen Gedanken folgen. Es gibt viele Möglichkeiten, wie du ihn hier unterstützen kannst. Wenn möglich, kannst du hier Aussagen von ihm aufgreifen, wenn eine davon in die richtige Richtung geht. Aber denk daran: Keine Lösungen präsentieren! Versuche alle deine Hilfestellungen in Fragen zu formulieren, so kannst du ihn in eine gewisse Richtung lenken und er hat die Chance, sich selbst mit der Problematik weiter auseinanderzusetzen.

Im konkreten Beispiel könntest du also die einfache Frage stellen:

Wofür steht der Fehler Code 401?

Hier geht es nicht darum, das Wissen abzufragen, sondern ihm eine Richtung zu geben, über die er nachdenken kann. Daniel kennt sich in der Webentwicklung schon ein bisschen aus und kann dir direkt sagen, dass der HTTP Code 401 für “Unauthorized” steht. Wenn er jetzt noch nicht selbst auf die Lösung kommt, kannst du besonders im persönlichen Gespräch das Mittel “Schweigen” einsetzen. Für viele Menschen ist es eine sehr unangenehme Situation, wenn in einem Gespräch Stille herrscht. Wenn du genug Selbstbewusstsein hast, schaust du Daniel an und sagst einfach nichts. Er wird anfangen, dir mehr Informationen zu liefern, um die Stille zu füllen. Vermutlich wird er dir alles über den 401 erzählen, was ihm einfällt. Eine etwas "sanftere" Methode wäre es, ihn als Nächstes zu fragen, “Was bedeutet das?”.

Dieses Spiel spielt ihr so lange, bis Daniel dir in irgendeiner Form erklärt, dass der Fehler 401 in der Regel dann ausgelöst wird, wenn für eine Anfrage zusätzliche Zugangsdaten benötigt werden.

Du merkst förmlich, wie Daniel direkt vor der Lösung seines Problems steht, oder? Jetzt kannst du das Gespräch zurück zu seiner ursprünglichen Frage lenken und sie so umformulieren, dass die Antwort auf die Frage seine Erklärung zu 401 ist, die er dir gerade gegeben hat. Das könnte zum Beispiel lauten:

Zurück zu deiner Frage: Warum bekommst du vom Backend den Fehler 401?

Und genau dieser Moment ist einer meiner liebsten Momente bei meiner Arbeit. Die Zufriedenheit in Daniels Gesicht ist für mich ein richtig gutes Gefühl. Spätestens jetzt wird er erkennen, dass er die Lösung für sein Problem die ganze Zeit selbst wusste und bisher nur nicht die richtigen Verbindungen hergestellt hat.

Und wie reagierst du jetzt, wenn er dich fragt, woher er die Zugangsdaten bekommt? Mit einem Lächeln im Gesicht sagst du jetzt bitte einfach nur: “Das kommt darauf an!”

Fazit

“Das kommt darauf an” ist also keineswegs eine Phrase, um eine Frage möglichst schnell loszuwerden. Vielmehr ist es ein sinnvolles Werkzeug, von dem beide Seiten nachhaltig profitieren können.

Durch dieses Gespräch versetzt du den Fragesteller nämlich in die Lage, sein Problem mit möglichst wenig Unterstützung selber zu lösen und hilfst ihm dabei, sich selbst weiterzuentwickeln.

Was haben wir also gelernt?

• Wenn du mit der Phrase “Das kommt darauf an” konfrontiert wirst, steckt häufig mehr dahinter als du spontan denkst

• Die Wahrscheinlichkeit, dass der Fragesteller dich nicht loswerden sondern dir nachhaltig weiterhelfen möchte ist hoch

• Um Entwickler zu sein, musst du lernen die richtigen Fragen zu stellen

Eine Sache musst du dir aber merken: Übertreib es nicht und setzte dieses Werkzeug mit Bedacht ein. Hältst du einen Hammer in der Hand, wird schnell jedes Problem zum Nagel.