Richtig um Hilfe bitten

Richtig um Hilfe bitten

Als Entwickler:innen treffen wir tagtäglich Situationen an, bei denen wir auf Unterstützung angewiesen sind. Dabei suchen wir Hilfe im eigenen Team, in Entwickler-Communities oder auch bei einem Softwarehersteller am anderen Ende der Welt.

Diese Kommunikation findet besonders häufig virtuell statt: Schriftlich via Chat, mündlich via Telefonanruf oder visuell in einem Video Call.

Damit der Austausch möglichst effizient stattfinden kann, gilt es einige Regeln zu beachten.

Aus persönlicher Erfahrung kann ich sagen, dass besonders unerfahrene Entwickler:innen oft Mühe haben, gezielt Unterstützung anzufordern. Häufig, weil sie die falsche Methodik anwenden.

Dieser Blog-Beitrag richtet sich in erster Linie an «Einsteiger:innen», aber auch für erfahrene Personen ist sicher etwas Spannendes dabei.

Damit die Beispiele einfach lesbar sind, wird alles aus der Perspektive der Hilfe leistenden Person geschrieben. Mit dem «Du» wird die Hilfe suchende Person angesprochen.

Online-Chats und Supportforen

Einen Grossteil der Kommunikation findet heute in schriftlicher Form via Chat oder Forum statt. Slack, Teams, GitHub Issues und Supportforen sind in den letzten Jahren ein fester Bestandteil des Entwicklungsalltags geworden. Über diese Kanäle wird nicht nur mit engen Team-Mitgliedern kommuniziert, sondern oft auch mit weltweiten Communities.

Möchtest du um Hilfe in einem schriftlichen Online-Chat bitten, gilt es die wichtigste Grundregeln dieses Blog-Beitrags zu beachten:

Dieser einfache Grundsatz ermöglicht es im besten Fall, ohne grosse Zeremonie, mit einer einzigen Antwort auf deine Nachricht dein Problem lösen zu können. Werden weitere Details benötigt, kann ich nachfragen. Erhältst du innert nützlicher Zeit keine Antwort, hilft der nächste Tipp besonders bei grossen Online-Communities:

Möglicherweise war die Person, die dir helfen kann, vor einer Stunde nicht online oder hatte keine Zeit.

Wenn auf einer Plattform allgemein viel geschrieben wird und es sich nicht primär um eine Support-Plattform handelt, dann hilft folgender Tipp:

In Slack könnte dies beispielsweise ein #help Channel sein, in den du schreiben kannst, wenn du Hilfe benötigst. So geht deine Anfrage nicht zwischen Memes und Smalltalk unter. Wenn kein dedizierter Channel vorhanden ist, schlage vor einen zu erstellen!

Wenn wir schon beim Thema «Ordnung» sind:

Leider sind Werkzeuge wie Slack und Teams immer noch sehr eingeschränkt, wenn es um die Strukturierung von Unterhaltungen geht. Fast alle bieten jedoch eine «Thread»-Funktion an, bei der Antworten auf eine Nachricht gruppiert werden. Wenn du für Antworten oder weitere Informationen zu deiner Anfrage die Thread-Funktion nutzt, trägst du dazu bei, dass deine und andere Unterhaltungen übersichtlich bleiben.

Du hast jetzt also einige Tipps erhalten, wie du deine Frage stellen sollst. Doch was, sollst du Fragen?

Oft warst du bereits einige Stunden damit beschäftigt, dein eigentliches Problem selbstständig zu lösen, bevor du an den Punkt angekommen bist, an dem du Hilfe benötigst. Folglich hast du einen Lösungsansatz ausgearbeitet und stehst jetzt bei einem Detail der Umsetzung an.

Wenn du um Hilfe bittest, beschreibe was du im allgemeinen vor hast («Ich muss eine Mail versenden, wenn sich ein Benutzer registriert.») und nicht, bei welchem Umsetzungsschritt du gerade Probleme hast («Wie rufe ich im Framework X eine Service-Methode auf, sobald ein neuer Eintrag in einer Datenbank erstellt wird?»).

Diese Situation wird als «XY-Problem» bezeichnet: Dein Lösungsansatz (Y) ist vielleicht nicht ideal und es gibt eine bessere Lösung. Wenn du dein eigentliches Problem (X) beschreibst, kann dir die passendste Problemlösung angeboten werden. Natürlich ist es nicht verboten, den eigenen Lösungsansatz zusätzlich zu erwähnen, damit man weiss, wie weit du mit der Problemlösung bist.

Wenn der Grund für deine Anfrage eine unerwartete Fehlermeldung ist, dann gilt:

«Ich erhalte den Fehler ‹Undefined index 4›.», ist hier nicht mit Fehlerdetails gemeint! Zu jedem Fehler findest du direkt im Output oder in einer Logdatei auch den «Stacktrace». Der Stacktrace dient als «Wegbeschreibung», mit der ersichtlich ist, in welcher Situation und auf welcher exakten Codezeile ein Fehler entsteht. Besonders für Neueinsteiger wirkt der Stacktrace meist wie unverständlicher Müll, doch sie ist der wichtigste Anhaltspunkt, wenn es um die Fehlersuche geht.

Erwähne auch, wie der Fehler reproduziert werden kann und mit welchen Software-Versionen das Problem auftritt. Auch hier solltest du nicht sparsam mit Informationen umgehen: Versionen des Betriebssystem, der Programmiersprache, des Frameworks, einzelner Libraries oder des Web-Browsers sind in jedem Fall zu erwähnen.

Solltest du deine Problemlösung alleine oder mit Hilfe anderer dann gefunden haben gilt:

Dieser Tipp ist besonders bei langlebigen Medien wie Supportforen wichtig. Die Inhalte werden von Suchmaschinen indexiert und können somit von Personen, die auf das gleiche Problem stossen, gefunden werden.

Aber auch in Chats sollte die Lösung veröffentlicht werden, denn es lesen oft mehr Augen mit, als man denkt: Vielleicht hilft man so jemand anderem, der in Zukunft auf das gleiche Problem stösst.

Interaktion mit Open Source Projekten

Ich führe die Interaktion mit Open Source Projekten, beziehungsweise deren Maintainern, in einem eigenen Kapitel auf, da dies ein besonders heikles Thema mit viel Potenzial für digitale «Fettnäpfchen» ist.

Angenommen, du möchtest im neuesten Frontend-Framework der Stunde die beste Todo-Liste der Welt bauen. Bei der Installation der Abhängigkeiten fällt dir auf, dass ein einzelnes npm Package zu einem Fehler führt. Du suchst das GitHub-Repo des Projekts auf und siehst, dass für genau dein Problem bereits eine Issue eröffnet wurde. Du erfasst einen Kommentar: «Ich habe das gleiche Problem!»

Kommentare wie «+1», «same problem» oder «please fix this» haben ausschliesslich negative Auswirkungen. Alle Personen, die der Issue folgen, werden über deinen Kommentar benachrichtigt. Dies kann besonders die Maintainer auf Zeit psychisch belasten, da sie wegen solcher Kommentare permanent wieder an offene Pendenzen erinnert werden. Wer diese Situation selber noch nie erleben durfte, kann im Beitrag «What it feels like to be an open-source maintainer» von Nolan Awson einen Einblick erhalten.

Nicht zuletzt leidet auch die Lesbarkeit der Unterhaltung durch unnötige Kommentare.

Nutze anstelle der Kommentare die Reaktionen-Emojis von GitHub. Maintainer sehen so auf einen Blick, welche Issues Aufmerksamkeit benötigen.

Die Issue zu deinem Problem ist bereits einige Wochen alt. So könntest du auf die Idee kommen zu fragen, ob es «any update on this?» gibt. Auch diese Kommentare sind unnötig. Die meisten Open Source Projekte werden per Definition öffentlich entwickelt. Würde also jemand an einem Problem arbeiten, könntest du das sehen. Die Wahrscheinlichkeit ist gross, dass bisher einfach niemand Zeit hatte, sich dem Problem anzunehmen.

Du schaust dir das Problem mit dem npm Package also selber genauer an und stellst fest, dass man lediglich zwei Zeilen Code ändern muss, um es zu beheben. Auf geht’s also zur Issue, um deine Lösung als Kommentar zu posten… aber halt!

Insbesondere dann, wenn es sich um eine kleine Anpassung handelt. Der Mehraufwand für dich ist minim. Für die verantwortliche Person des Projekts erleichtert ein fertiger Pull Request die Arbeit jedoch enorm. Abhängig von der Projektgrösse, kann es als Maintainer auch schwierig bis unmöglich sein, Lösungsansätze aus spezifischen Unterhaltungen überhaupt zu bemerken. Mit einem Pull Request führst du die Korrektur direkt in den für Korrekturen vorgesehenen Arbeitsablauf ein. Dies erhöht die Chance, dass deine Anpassung integriert wird.

Dein Pull Request ist also erstellt, doch selbst nach zwei Wochen wurde er noch nicht gemerged. Noch nicht einmal eine Rückmeldung hast du erhalten! Du ärgerst dich und beginnst einen wütenden Kommentar zu verfassen… Doch dabei solltest du folgendes beachten:

Der Grossteil aller Open Source Projekte wird von Personen in ihrer Freizeit unterhalten. Doch auch bei grösseren Projekten mit Vollzeit-Maintainern hast du grundsätzlich kein Anspruch auf (gratis) Support. Wann immer du eine Antwort auf eine Issue erhältst oder extra für dich ein Bugfix veröffentlicht wird, ist dies ein Geschenk des Maintainers an dich ‒ genauso wie jede einzelne Zeile Code, die das Fundament für deine Applikation bildet.

Open Source ist ein Gemeinschaftsprojekt. Wenn du also einen Bug findest, ist es genau so deine Verantwortung diesen zu fixen, wie die Verantwortung der Person, die den fehlerhaften Code ursprünglich geschrieben hat.

Wenn du also einen Pull Request bereitgestellt hast, dann hast du deinen Beitrag geleistet. Wenn die Korrektur nicht in das Projekt integriert wird, hast du jederzeit die Möglichkeit, deine Korrektur über einen Fork des Repos in deine Applikation zu integrieren.

In diesem Zusammenhang...

Wenn deine Todo-Liste bis nächste Woche online gehen muss, du aber wegen des gefunden Bugs den Zeitplan nicht einhalten kannst, dann liegt dies zu 100% in deiner Verantwortung. Den Maintainern Druck zu machen, damit sie das Problem über das Wochenende für dich lösen, wäre hier also komplett der falsche Ansatz.

Der persönliche Kontakt

Es gibt Situationen, bei denen du nicht um den persönlichen Kontakt mit einer Person im echten Leben oder via Telefonanruf oder Video Call herum kommst. Je enger du mit einer Person zusammenarbeitest, desto einfacher ist es, persönlich in Kontakt zu treten. Genau diese Einfachheit kann für einzelne Teammitglieder aber schnell zu einem Tag voller Unterbrechungen führen.

Möchtest du zum Beispiel ein Kollege um Hilfe bitten, versuche folgenden Grundsatz einzuhalten:

Um die «Störung» der anderen Teammitglieder möglichst gering zu halten, solltest du Kontaktanfragen über asynchrone Kanäle starten. Damit ist gemeint, dass du bei nicht dringenden Anliegen nicht einfach aus heiterem Himmel zum Hörer greifst oder zum Pultnachbar rennst.

Das Gespräch mit rhetorischen Fragen wie «Darf ich dich kurz etwas fragen?» oder «Störe ich gerade?» zu beginnen, macht die Situation nicht besser: Vielleicht störst du gerade wirklich, aber der Schaden ist bereits entstanden.

Sobald du eine Person über einen synchronen Kanal kontaktierst, muss die komplette Aufmerksamkeit der Person sofort dir gehören und die Konzentration ist dahin. Schreibst du jedoch eine Slack Nachricht und bittest um einen Video Call, kann dir die Person dann, wann sie ohnehin gerade mit Slack Nachrichten beschäftigt ist, eine Rückmeldung geben.

Ein weiterer wichtiger Punkt bei der persönlichen Kontaktaufnahme:

Zum Einen erlaubt dies, eine längere Unterhaltung bereits im Voraus zu vermeiden («Das Problem ist bekannt, du musst nur die Software auf Version 5.4 aktualisieren»). Zum Anderen habe ich so die Möglichkeit, mich auf das Problem vorzubereiten und gegebenenfalls erste Recherchen zu betreiben. Auch erfahrene Entwickler:innen wissen nicht immer alles aus dem Stegreif!

Hast Du noch weitere Tipps?

Die Tipps in diesem Blog-Beitrag wurden über mehrere Monate aktiv aus Beispielen aus dem realen Arbeitsalltag zusammengetragen. Hast du weitere Tipps aus deinem Arbeitsalltag, die hier noch fehlen? Sende sie uns via Twitter oder E-Mail (info@offline.ch)!