Wenn manche Autaren dieses Buches heute mittelmäßige bis gute Programmierer sind, dann verdanken sie das auch freundlichen Mitmenschen, die ihnen bei Anfängerfragen geholfen haben. In der Antike der Programmierung konnte man sich glücklich schätzen, ' enn man noch ein oder zwei andere kannte, die auch programmierten. Heute gibt es Tausende von Orten im Netz, an denen man als Anfänger seine Fragen loswerden kann nd - wenn man es richtig anstellt - sogar konstruktive Antworten erhält. Wenn man es talsch anstellt, kann es allerdings passieren, dass man mit schroffen Hinweisen wie »erst >u «, hen, dann fragen«, »LMGTFY«¹ oder »RTFM«¹² abgefertigt wird.

• 'iel Verdruss und Ärger kommt dadurch in die Welt, dass Programmierer ihre Hilfegesuche ungeschickt formulieren. Stellen wir uns jemanden vor, der in das Entwicklerforum der (fiktiven) »PHPschnargl«-Bibliothek diesen Hilferuf absetzt:

I am trying to use PHPschnargl in my latest project and it doesn't work. When I access the page, my script stops working. Please tell my why it isn't working!

Eine Anfrage dieser Art wird voraussichtlich gereizte Reaktionen hervorrufen, weil der -agende ein paar Fehler gemacht hat:

• Er hat das falsche Forum gewählt. Er dachte zwar, phpschnargl-dev wäre richtig, weil der Zusatz »dev<< wie Developer auf Entwickler als Zielgruppe hinweist, und so einer ist er ja schließlich. Leider hat er übersehen, dass es sich um das Forum der Entwickler der »PHPschnargl«-Bibliothek handelt. Als Programmierer, der die Bibliothek nur verwendet, hätte er sich an phpschnargl-user wenden sollen.

• »HELP!!!« als Überschrift ist vollkommen nichtssagend. Jeder Hilfswillige muss die Nachricht erst öffnen, um zu erkennen, wo hier Hilfe benötigt wird.

• Die Problembeschreibung ist nicht geeignet, das Problem jemand anderem verständlich zu machen. Der Fragesteller hat keine Informationen über den Kontext, also die PHP-Version, die Version der Bibliothek oder Ähnliches geliefert. Wichtig wären auch Fehlerlogs gewesen, denn aus denen kann ein erfahrener Programmierer meist wichtige Informationen gewinnen.

• Der Code ist sehr lang. Niemandem fällt es besonders leicht, sich in fremden Code hineinzudenken. Kaum jemand wird sich dazu aufraffen, wenn der Code nicht auf das wesentliche Problem reduziert ist.

Auch einfache Hilfsanfragen sind also gar nicht so einfach zu stellen, wie man annehmen könnte. Dieses Kapitel soll ein paar Grundlagen vermitteln, wie Sie so um Hilfe nachsuchen, dass Sie die Nerven der anderen schonen und möglichst sinnvolle Resultate erhalten.

Der richtige Zeitpunkt

Grundsätzlich gilt es, die Zeit der anderen zu respektieren, aber auch die eigene nicht sinnlos zu verschwenden. Wer zu früh fragt, wirkt unselbstständig und stiehlt anderen Menschen die Zeit. Wer zu spät fragt, bringt vielleicht völlig unnötig sechs Stunden mit einem Problem zu, das sich durch eine einfache Frage innerhalb von Minuten hätte lösen lassen. Außerdem sind das Netz und vermutlich auch die übrige Welt voll von Menschen, denen es tatsächlich Spaß macht, sich mit den Problemen anderer Leute zu befassen - vorausgesetzt, diese anderen Leute haben vorher ein Mindestmaß an eigener Vorarbeit geleistet. Diese Vorarbeit ist in jedem Fall ein Gebot der Höflichkeit und hilft, den richtigen Fragezeitpunkt zu treffen. Wenn Sie alle Fragen aus der folgenden Checkliste mit »Ja<< beantworten können, dürfen Sie andere ohne Verlegenheit um Hilfe bitten:

Haben Sie das Problem oder, noch besser, den Wortlaut der Fehlermeldung einer Suchmaschine vorgelegt?

Ein paar Tipps für die Suche finden Sie im Kasten Erst suchen, dann fragen. Falls Sie aus irgendeinem Grund eine deutschsprachige Fehlermeldung erhalten: Haben Sie herausge-

funden, wie sie auf Englisch lautet, und nach dieser Version gesucht? Nebenbei vermeiden Sie so, mit rotem Kopf vor dem Rechner zu sitzen, weil jemand einen Link mit der Antwort postet, versehen mit dem Hinweis, dass es sich um den allerersten Treffer zum Thema handelt.

Wenn Ihre Frage mit HTML, CSS,JavaScript oder XML zu tun hat: Haben Sie den zuständigen Validator bemüht und sichergestellt, dass Ihr Code den Standards entspricht?

Eine Liste gängiger Validatoren für Webtechnologien finden Sie in Kapitel 13. Der Validator wird eine Vielzahl erbsenzählerischer Beschwerden zurückliefern. Eine dieser Beschwerden hat wahrscheinlich unmittelbar mit ihrem Problem zu tun. Solange Ihr Code nicht validiert, stehlen Sie anderen mit Ihrer Frage die Zeit. Übrigens bringen Entwicklungsumgebungen für gängige Sprachen und Formate bereits Validataren mit (siehe dazu den Abschnitt »Entwicklungsumgebungen« in Kapitel 20).

Haben Sie alle Regler Ihrer Programmiersprache für das Anzeigen von Fehlermeldungen und Warnungen ganz nach rechts gedreht? Haben Sie diese Fehlermeldungen und Warnungen berücksichtigt und beseitigt?

Haben Sie herausgefunden, ob es eine offizielle FAQzu der Software, der Bibliothek oder dem Projekt gibt, wovon Ihre Frage handelt? Haben Sie diese FAQ nach einer Antwort durchsucht?

So lässt sich das Eselsmützengefühl vermeiden, das sich einstellt, wenn dreißig Sekunden nach Abschicken der Frage eine Antwort eintrifft, die auf Punkt 2 der offiziellen FAQ verweist.

Haben Sie die Archive der Website durchsucht, auf der Sie Ihre Frage stellen wollen?

Vtelleicht wird dieselbe Frage ständig gestellt und die Zuständigen waren bisher nur zu träge, sie in die FAQ aufzunehmen.

E- gibt keine Entschuldigung dafür, diese Punkte nicht vor dem Fragen abzuhaken. Wer seins Frage mit »Sorry, hab noch nirgends danach gesucht, aber es EILT« oder »Ich weiß s..:hon, der Code validiert nicht, aber das liegt nicht an mir, sondern an ...« einleitet, dessen Nummer soll auf den Listen aller Telefonmarketer Deutschlands landen, und sie solen ihn anrufen Tag für Tag um fünf Uhr morgens und ihre Anrufe einleiten mit: >>Ich \ciß, es ist früh, aber es passte mir grade so gut!<< Außerdem wird er wahrscheinlich keine Antwort auf seine Frage bekommen.

Erst suchen, dann fragen - so geht's

Suchen Sie auf Englisch, nicht auf Deutsch.

Es gibt erheblich mehr Menschen auf der Welt, die sich auf Englisch über Programmierprobleme austauschen. Entsprechend größer ist - speziell bei seltener vorkommenden Problemen - die Chance, eine Antwort zu finden. Wenn Sie gar keine Vorstellung davon haben, wie die Stichwörter lhres Problems auf Englisch heißen könnten, hilft es vielleicht, einen deutschsprachigen Wikipedia-Eintrag zum Thema ausfindig zu machen und dort auf den Link zur englischen Version zu klicken.

Suchen Sie nach der Antwort, nicht nach der Frage.

Eine Suche nach »how do i escape a string in java« wird vor allem Seiten zutage fördern, auf denen andere dieselbe Frage haben. Eine Suche nach »escaping a string in java<< hingegen führt schon eher zu einer Seite, die eine Antwort enthält. Versuchen Sie vorherzusehen, welche Formulierung in der Antwort wahrscheinlich vorkommen wird und suchen Sie danach. ln der Praxis kann das bedeuten, dass Sie zunächst eine Weile herumprobieren müssen, um herauszufinden, nach welchen Stichwörtern man eigentlich suchen müsste, um die Antwort zu entdecken. Tragen Sie es mit Fassung. Auch dieser Vorgang bildet, denn Sie kennen sich danach besser mit den relevanten Begriffen rund um lhr Thema aus.

Klassische Messageboards sind bei konkreten Problemen so gut wie nie eine Hilfe.

Wenn Sie aus der Suchmaschine auf eine Seite geraten, die Sie schon am Layout als Forum vom Typ phpBB oder vBulletin erkennen, können Sie Zeit sparen und sie gleich wieder schließen. Zudem sind olche Foren häufig nicht sinnvoll von Suchmaschinen indizierbar, der antwortverheißende Link führt also längst zu einem ganz anderen Teil der Diskussion. In den seltenen Fällen, in denen die Suchvorschau eine ganz konkrete Lösung Ihres Problems verheißt, bringt es mehr, dem Link zum Suchmaschinencache zu folgen. Der enthält nämlich tatsächlich noch die damals indizierte Stelle.

Geben Sie nicht gleich auf.

Falls Sie zu viele nichtssagende Treffer erhalten, probieren Sie Ihre Anfrage in Kombination mit antwortverheißenden Stichwörtern wie »FAQ<<, >>solved<<, »Solution«, »Code example«, >>answered«, »thanks« oder >>did the trick«.

Vielleicht ist die Antwort auf Ihr Problem gar nicht im Netz zu finden.

Weil auch andere unbedarfte Programmierer so vorgehen wie Sie, bilden sich automatisch Orte im Netz, an denen schlechte Fragen gestellt und schlechte Antworten gegeben werden. Erwägen Sie die Anschaffung eines O'Reilly->>Cookbook« zu Ihrem Thema oder Ihrer Programmiersprache. 80 Prozent der Lösungen, die Sie suchen (oder suchen würden, wenn Sie wüssten, dass diese Lösungen überhaupt existieren), sind darin bereits abgehandelt.

Wenn Sie als nicht so guter Programmierer keinerlei Suchmaschinentreffer für Ihr Problem erhalten, bedeutet das nicht, dass das Problem ganz neu und aufregend ist und die Welt davon erfahren muss. Es bedeutet, dass Ihr Problem entweder keines ist oder Sie sich ein falsches geistiges Modell von der Art des Problems gebildet haben. Am besten denken Sie bei einer Tasse Tee noch einmal gründlich über alles nach.

An der richtigen Stelle fragen

Die Suche nach Antworten aufProgrammierfragen ist seit der Gründung von Stack Overflow (stackoverflow.com) im Jahr 2008 wesentlich einfacher geworden. Anders als in den bis dahin gängigen Foren schwimmt die beste Antwort dank der Vergabe von Plus- und Minuspunkten nach oben, man muss sich also nicht mehr durch 32 Forumsseiten klicken, um am Ende doch keine Antwort zu finden. Das hat die Site bei guten Programmierern beliebt gemacht. Die Wahrscheinlichkeit, dort auf eine hilfreiche Antwort zu stoßen, ist so hoch, dass Stack Overflow immer dann Ihre erste Anlaufstelle sein sollte, wenn Sie nicht bereits eine auf Ihr Thema spezialisierte Website kennen, von der Sie sich mehr erhoffen. Nebenbei kann man aus den Begründungen dafür, warum eine Frage dort gut oder schlecht bewertet wurde, viel darüber lernen, wie man solche Anfragen sinnvoll formuliert. Seit 2008 ist allerdings schon wieder viel Zeit vergangen, achten Sie deshalb darauf, von wann die gefundene Antwort stammt. Manche Programmierprobleme sind relativ zeitlos, bei anderen kann die Antwort schon nach wenigen Monaten veralten.

Falls Stack Overflow Ihr Problem nicht löst, gibt es bei Open Source-Projekten häufig mehr als eine Anlaufstelle. Gibt es den Luxus eines Einsteigerforums, dann sollte man als .Anfänger unbedingt dort fragen, weil man vermutlich zunächst triviale Probleme haben nrd, die in den Foren für Fortgeschrittene nur stören würden. In Einsteigerforen wird juch weniger harsch über dusselige Fehler geurteilt.

Schreibe"i Sie nur im äußersten Notfall (also nie) individuelle Entwickler von Open "ource-Software mit der Bitte um Hilfestellung an. Die einzige Ausnahme von dieser Regel: Wenn das Open Source-Projekt so obskur und/oder hochspezialisiert ist, dass Sie einer von ungefähr sieben Nutzern weltweit sind, freut sich der Entwickler vermutlich über jede Frage. Die einzige andere Ausnahme: Ihre Firma kann dem Entwickler ein Beratungshonorar zahlen.

Die Anfrage richtig strukturieren

Machen Sie sich vor dem Abschicken der Frage klar, was Sie eigentlich wissen wollen. Bei kreten Programmfehlern ist das noch relativ einfach. Versteht man aber nicht, wie zum Beispiel eine bestimmte Bibliothek verwendet wird, dann sollte man sich vorher '!enau überlegen, was man fragen will. Die Frage könnte etwa so lauten:

»Hat jemand ein Codebeispiel, wie PHPschnargl unter PHP 5.0 auf Ubuntu >Stoned Snail< initialisiert wird⁵«

»Die Initialisierung von PHPschnargl unter PHP 5.0 auf Ubuntu Stoned Snail liefert den Fehler e_param_range_violation zurück. Wer hat das auch schon erlebt und kann mir sagen, was ich falsch mache?«

Im ersten Fall signalisiert man, dass man einfach nur lauffähigen Code haben will, im zweiten, dass man sich für das Problem und seine Lösung interessiert. Beides ist legitim, kann aber zu unterschiedlichen Antworten führen.

Wenn man sich klargemacht hat, was man sich eigentlich von den anderen Leuten wünscht, kann man die Anfrage formulieren. Es ist hilfreich, zunächst eine Kurzzusammenfassung zu liefern. Sie sollte enthalten, was man zu erreichen versucht hat und was dabei schiefgeht. Für »Ticket Tracking«-Systeme gibt es - ähnlich wie auf den Aufklebern an Notrufsäulen, nur ohne Verletzte - die immer gleichen Fragen:

An dieser Liste kann man sich auch orientieren, wenn man eine Anfrage an eine Benutzer-Community stellt. So können sich die Leser einen schnellen Eindruck davon verschaffen, was das Problem ist und ob sie helfen können. Gleichzeitig geben Sie der Welt eine Chance, Sie darauf hinzuweisen, dass Ihr Lösungsansatz zu kompliziert oder einfach falsch ist.

»Ich will php_schnargl. init mit Parameter x und y aufrufen, erhalte aber den Fehler e_param_range_violation.«

»Ich will PHPschnargl für ein Personenverzeichnis mit Angaben zu deren Social-Net-work-Profilen einsetzen. Um ein Personenobjekt zu erhalten, dessen Profil in einer URL-Liste enthalten ist, rufe ich php_schnargl.init mit Parameter x (leeres Personenobjekt) und y (URL-Array) auf, erhalte aber den Fehler e_param_range_violation.«

Das Schreiben dieser Zusammenfassung hilft Ihnen übrigens auch dabei, Wichtiges von Unwichtigem zu trennen - häufig verbessert das Ihren Code. Er ist dann zwar immer noch fehlerhaft, aber die Fehler sind eleganter.

Dann folgt eine längere Beschreibung, in der Sie Ihre Voraussetzungen, Annahmen und die Idee, die Sie verwirklichen wollen, darlegen. Vielleicht ist PHPschnargl gar keine besonders gebräuchliche Lösung für Ihr Problem, und der Rest der Welt verwendet SozialGraf. Aber Ihre uneinsichtigen Kollegen zwingen Sie dazu, auf PHPschnargl zu setzen, weil es ein seit Jahren in der Firma eingeführter Standard ist, der Chef in seiner aktiven Programmierzeit damit gearbeitet hat und keiner sich mit einer anderen Library befassen will. Das ist eine wichtige Information für jeden, der sich mit Ihrer Supportanfrage befassen soll. Verschweigen Sie sie, dann werden die ersten Antworten sich darauf beschränken, Sie über das Vorhandensein von SozialGraf aufzuklären. Außerdem nehmen Sie Ihren hilfsbereiten Lesern die Möglichkeit, Sie auf einen dritten Lösungsweg aufmerksam zu machen, der besser ist als PHPschnargl und gleichzeitig Ihre speziellen Voraussetzungen berücksichtigt.

Ähnliches gilt für die in Ihrem Lösungsansatz enthaltenen Annahmen über die Welt. Wenn Sie sie explizit formulieren, helfen Sie den anderen, Fehler in diesen Annahmen zu finden und Sie darauf hinzuweisen.

■■Wenn ich PHPschnargl initialisiere, bekomme ich die Fehlermeldung e_param_range_ violation zurück.«

■ Ich initialisiere PHPschnargl mit einem leeren Personenobjekt und einem Array mit ■'trings. die URLs repräsentieren. Ich erwarte ein gefülltes Personenobjekt und den Status status_ok, bekomme aber stattdessen das leere Personenobjekt und die Fehlermeldung e_param_range_violation zurück.«

Legen Sie alle Schritte dar, die Sie zur Lösung des Problems schon selbst unternommen haben. Das macht für den Leser transparent, was Sie versucht haben und wie Ihr Gedankengang bei der Suche nach einer Lösung aussah, und es zwingt Sie nebenbei dazu, diese schritte überhaupt erst mal zu unternehmen. Manchmal wird man im Web zwar fündig, aber das Problem ist in der entsprechenden Diskussion auch nicht gelöst worden. Dann ollte man sich die URL notieren und bei der Bitte um Hilfe in Form einer Bemerkung anhängen: >>Ich habe schon folgende Diskussionen gelesen, dort ist das Problem auch beschrieben, aber nicht gelöst: ...« So dokumentieren Sie, dass Sie schon vorgearbeitet haben, und vermeiden, auf die schon bekannten Diskussionen verwiesen zu werden.

Zuletzt kommen der Code und die relevanten Fehlermeldungen und Logfiles. Hängen Sie möglichst viele Informationen über Betriebssystem, Sprachversion und dergleichen an. Manche Fehler sind bekannt und treten nur auf einer bestimmten Plattform auf. Wenn die jeweilige Community explizit um bestimmte Angaben bittet, kommen Sie dieser Bitte unbedingt nach, auch wenn Sie den Grund dafür vielleicht nicht ganz verstehen. Es gibt ^anz sicher einen.

Wichtig ist, eine reduzierte Version des Codes mitzuliefern. Es sollte idealerweise das kleinste Codestück sein, das das beschriebene Problem noch hervorruft. Anfängern fällt es oft schwer, ihren Code zu reduzieren, weil sie keine Versionskontrolle verwenden, keine Backups machen und kein Testsystem haben, auf dem sie die reduzierte Version testen können, ohne die Ursprungsversion unwiderruflich zu verändern. Das ist aber in keinem Fall eine legitime Ausrede, sondern sollte Ihnen ein Ansporn sein, Ihre Arbeitsmethoden so zu verbessern, dass Sie jederzeit Tests durchführen können. Das macht Ihr Programmierleben auchdann viel einfacher, wenn Sie gerade nicht in einem Forum nachfragen müssen.

Wenn Sie Webseiten oder -apps entwickeln, dann legen Sie Ihr reduziertes Codebeispiel auf einer Site wie jsfiddle.net oder codepen.io ab. Das HTML kommt in ein Kästchen, das CSS in ein anderes und das JavaScript in ein drittes. Überprüfen Sie dann, ob Ihr Problem immer noch existiert, und wenn ja, dann veröffentlichen Sie den Link zum Testcode. Der Vorteil: Alles ist beisammen, und Ihre Leser können ohne großen Aufwand den Code und die Auswirkungen des Fehlers sehen und den Link zu einer korrigierten Fassung zurückmailen.

Sehr vielen Anfängern, auch mittelmäßigen und manchmal sogar guten Programmierern ist ihr Code peinlich. Selbst wer kein großes Interesse an Eleganz und Effizienz hat, verspürt häufig ein Gefühl von Unterlegenheit, wenn er seinen Code mit den Beispielen in Lehrbüchern vergleicht. Während der Entwicklung schämt man sich heimlich, ist aber auch nicht gezwungen, den Code anderen Personen zu zeigen. Was aber, wenn man eine Frage hat und dazu die relevanten Passagen anhängen will?

Wenn Sie relativ viel Zeit haben, können Sie versuchen, den Code vor dem Abschicken aufzuräumen. Soll es aber schnell gehen, dann müssen Sie einfach damit leben, dass der Rest der Welt jetzt Ihr kleines schmutziges Geheimnis kennt. Investieren Sie Ihre Zeit lieber darin, den Code zu reduzieren, und trösten Sie sich damit, dass viele der Leser auch keinen besseren Code schreiben würden - Lehrbuchcode stammt nun mal nicht aus der freien Wildbahn, sondern wird von Menschen mit sehr viel Erfahrung speziell für eine Lehrbuchsituation geschrieben.

Testen Sie auf jeden Fall vor dem Abschicken der Frage, ob diese Minimalversion Ihres Codes das Problem überhaupt noch hervorruft. Die Versuchung ist wahrscheinlich groß, diesen Schritt zu überspringen. Oft ergibt sich aber gerade dabei ganz von allein die Antwort auf die Frage, die man eigentlich stellen wollte. Wenn das geschieht - ob durch das Reduzieren des Codes oder durch einen anderen Teil der Fragevorbereitung - und wenn Sie ein besonders netter Mensch sind, dann formulieren Sie Ihren Beitrag von einer Frage zu einer Lösung um und veröffentlichen ihn trotzdem.

An den Leser denken

Ihnen ist das Problem vertraut, und Sie wollen schnell Hilfe. Diejenigen, die Ihnen helfen sollen, müssen sich erst einlesen. Geben Sie Ihrer Frage daher eine aussagekräftige Überschrift mit auf den Weg. »HILFE!!!« als Überschrift ist in verschiedener Hinsicht falsch: Es wirkt durch die Großschreibung und die übertriebenen Ausrufezeichen aufdringlich und gibt keinerlei Aufschluss darüber, wo das Problem liegt. »PHPschnargl -

Initialisierungsproblem unter Debian Shady« ermöglicht dem Leser schon eher, vorab zu beurteilen, ob er hier wohl helfen könnte. Schreiben Sie nicht »Wichtig!« oder »Dringend!« in die Überschrift, das führt bloß dazu, dass die Leser sich gedrängt und ausgenutzt fühlen. Die Dringlichkeit ist Ihr privates Problem, nicht das Ihrer Helfer. Behalten Sie auch Ihre Vermutung für sich, dass andere an Ihrem Problem schuld sind: »Epischer Bug in PHP 5.0???«

Fassen Sie sich generell kurz. Aus Höflichkeit leitet man zwar normalerweise Sachfragen gerne einmal mit einer sozialen Hilfsfrage ein, wie >>Äh, kann mir mal jemand bitte helfen?«, um nicht das Gefühl zu erwecken, mit der Tür ins Haus zu fallen. Bei Anfragen in

IMipportforen oder Chats sollte man aber direkt zur Sache kommen und einleitende Fragen wie »Kennt sich jemand hier mit ^X aus?<< weglassen. Dass sich an diesen Orten hilfswillige Leute aufhalten, darf man voraussetzen.

schreiben Sie möglichst korrektes Englisch oder Deutsch. Schalten Sie die Rechtschreibkontrolle der jeweiligen Sprache ein - Anfragen, in die der Verfasser ein ersichtliches Minimum an Mühe investiert hat, werden ernster genommen als fehlerdurchsetztes Geschreibsel.

Verzichten Sie auf Demutsgesten. Wenn Sie Ihre Hausaufgaben (siehe oben) gemacht haben, brauchen Sie Ihre Frage nicht mit »Ich weiß, ich bin doof, sicher liegt es an mir, ich programmiere auch erst seit fünf Minuten, aber ...« einzuleiten. Und wenn Sie Ihre Hausaufgaben nicht gemacht haben, dann werden Floskeln Ihre Leser nicht darüber hinwegtäuschen.

Wenn Sie Daten anhängen, wählen Sie verbreitete, offene Formate. Nicht jeder besitzt eine Lizenz für Microsoft Office und kann Ihre Word- oder Excel-Dateien lesen. Exportieren Sie solche Daten zum Beispiel als HTML, PDF oder CSV.

Nicht zu viel erwarten

Die einfachste Unterstützung erhalten Sie dort, wo sich Leute unbezahlt tummeln. Sie müssen keine Wartungsverträge abschließen und kein Service Level Agreement definieren, und es ist natürlich schön, für den Support kein Geld zahlen zu müssen. Die Kehrseite ist, dass die«e Leute ihre Freizeit für die gute Sache opfern. Wenn Sie eine Frage der Form »Kann mir jemand bitte die Funktionsweise von X erklären?« stellen, bitten Sie Ihre Mitmenschen darum, sehr viel Zeit zu investieren und einen längeren Text zu schreiben. Das funktioniert eher selten und ist ein respektloser Umgang mit der Zeit anderer Leute. Eine Frage der Form »Kann mir jemand bitte einen Link zu einer für Anfänger verständ-ehen Erklärung der Funktionsweise von X geben?« ist schon viel besser. Noch besser ist . natürlich, den Link selbst zu suchen.

Wenn Sie eine Antwort nicht gleich verstehen, versuchen Sie sich erst durch Suchen und Nachdenken selbst zu helfen, bevor Sie beim Autor nachfragen. Sobald Sie eine hilfsbereite .' 'on gefunden haben, die Ihre Anfangsfrage beantworten konnte, ist die Versuchung

groß, sich mit allen weiteren Fragen ohne vorheriges Nachdenken direkt an sie zu wenden. Bitte beißen Sie niemandem den ganzen Arm ab, nur weil er ihnen den kleinen Finger gereicht hat. Für Folgetragen gilt das gleiche Gebot der höflichen eigenen Vorarbeiten.

Je präziser Sie um Hilfe bitten, desto eher werden Sie sie bekommen. Gute Fragen sind Fragen nach (schwer zu findenden) Anleitungen, nach funktionierenden Codebeispielen oder danach, ob sich jemand ein eng umrissenes, im Idealfall sogar interessantes Problem anschauen und Hilfestellung zur Lösung leisten mag.

Erwarten Sie auf keinen Fall, dass die anderen Ihnen den Code debuggen und eine fixfertige Lösung für ein nur ungefähr skizziertes Problem schreiben. Anfragen der Art >>Send me the codes please« sind in Programmierforen verhasst, weil solche Poster schamlos versuchen, andere ihre Arbeit machen zu lassen. Jede Community verkraftet gelegentlich solche Postings, aber auf Dauer führt zu große Toleranz dazu, dass sich gute Leute abwenden und die entsprechende Community kollabiert.

Keine unbewussten Fallen stellen

Häufig schildern Fragesteller ihre Annahmen darüber, wodas Problem liegen könnte, und vernachlässigen darüber die Problembeschre/bwng. Das ist aus zwei Gründen nicht hilfreich: Erstens wäre die Zeit und der Platz, in dem diese Fragesteller ihre Annahmen beschreiben, besser für echte, möglichst annahmenfreie Informationen genutzt. Dadurch, dass sie Annahmen und Problembeschreibung verwechseln, haben sie das gute Gefühl, das Problem hinreichend klar dargestellt zu haben. In Wirklichkeit haben sie aber nur ihre Sicht der Dinge dargelegt.

Zweitens führt eine solche Schilderung die Leser auf eine falsche Fährte. Denn auch wenn die Vorstellung des Fragenden mit dem tatsächlichen Problem nichts zu tun hat, wird sie im Kopf des Lesers erst einmal verankert. Er wird zunächst genau in diese beschriebene Richtung suchen. Da Sie aber schon mit Ihrer Vermutung gescheitert sind, ist die Wahrscheinlichkeit hoch, dass auch der hilfreiche Leser den wahren Grund so nicht finden wird. Trotz eines solchen Ankers das echte Problem zu sehen, ist viel schwerer, als wenn man als Leser ohne vorgefasste Annahmen an das Problem herangeht.

Höflich bleiben - egal, was passiert

Nicht immer ist die Antwort im Tonfall so, wie man es sich erhoffen würde. Dafür kann es verschiedene Gründe geben, etwa dass die Frage am falschen Ort gelandet ist, unpräzise gestellt oder schon über 9.000 Mal beantwortet wurde. Antworten Sie mit einer kurzen Entschuldigung und reichen Sie gegebenenfalls die fehlenden Informationen nach. Gibt es unterschiedliche Reaktionen, antworten Sie nur auf die konstruktiven und ignorieren pampige Antworten und offensichtlichen Quatsch. Aber Vorsicht: Was sich beim ersten Betrachten pampig und wie offensichtlicher Quatsch anfühlt, das kann auch eine richtige, aber unbequeme Antwort sein. Versuchen Sie zu unterscheiden, ob Sie schlechte Laune bekommen, weil die Antwortende Sie gekränkt hat, oder ob Sie schlechte Laune bekommen, weil die Antwortende recht hat und Sie nicht.

Bekommen Sie nur abweisende oder grobe Antworten, ohne sich eines Fehlers bewusst zu sein, oder können Sie partout nicht nachvollziehen, warum die Vorwürfe an Sie gerechtfertigt sei sollen, dann haben vielleicht die anderen einen schlechten Tag oder sind generell unhöfliche Menschen. Auch Netz-Communities haben ihre guten und ihre schlechten Phasen, und gegen Ende ihrer Lebensdauer ist von der anfänglichen Hilfsbereitschaft oft nicht mehr viel zu spüren. Vermeiden Sie eine aufgebrachte oder zurechtweisende Antwort, so verlockend das in der ersten Empörung scheint. Und zwar auch dann, wenn Ihnen die schlagfertigste Replik der Welt in den Fingern juckt. Wir wissen, wie schwer das fällt, und fühlen mit Ihnen. Aber nicht nur im Internet ist es häufig am klügsten, aufkommenden Streit durch Nichtbeachtung wieder einschlafen zu lassen -jede Antwort facht die Flammen nur weiter an, bringt Sie Ihrem Ziel nicht näher und zehrt an Ihren Neren und Ihrer Zeit. Zusatzvorteil: Schon nach einigen Jahrzehnten der Übung erlangen Sie so die Gemütsverfassung eines buddhistischen Weisen, werden aus dem Leidenskreislauf der fühlenden Wesen befreit und können den Beruf des erleuchteten Meisters ergreifen.³

Wenn Sie nur blöde oder gar keine Antworten erhalten, sehen Sie davon ab, die Frage unverändert und mit Vorwürfen garniert ein zweites Mal zu stellen. Probieren Sie es anderswo. Falls es Ihnen dort ebenso ergeht, ist die Wahrscheinlichkeit groß, dass es doch an Ihnen liegt. Lesen Sie dieses Kapitel dann noch einmal von vorn.

Haben Sie konstruktive Antworten erhalten, dann bedanken Sie sich bei den Helfenden und schreiben Sie eine kurze Zusammenfassung, die anderen mit der gleichen Frage weiterhelfen kann. Sie geben so ein wenig von dem zurück, wovon Sie profitiert haben -und machen die Welt zu einem besseren Ort. Die Zusammenfassung sollte unter der gleichen Überschrift wie die Ursprungsfrage stehen, aber zusätzlich ein »GELÖST:« oder >>SOLVED:<< enthalten. Leser, deren Zeit knapp ist, können sie überspringen, wenn sie wissen, dass hier nur noch eine Zusammenfassung und Dank zu erwarten sind. Andere Leser, die sich für die Diskussion um die Lösung nicht interessieren, können viel Zeit sparen, indem sie nur die Eingangsfrage und die Lösung lesen.

Auch wenn Suchmaschinen keine Antwort lieferten und in den zuständigen Supportforen niemand weiterhelfen konnte oder wollte, so dass Sie Ihr Problem im Schweiße Ihres Angesichts selbst lösen mussten: Gerade dann sollten Sie sich die Mühe machen, Ihren Lösungsweg noch einmal nachvollziehbar aufzuschreiben und an einer passenden Stelle im Internet zu verewigen. Diese Stelle darf gern auch Ihr eigenes Blog sein, wenn das Problem spezifisch genug dafür ist, dass zukünftige Suchende eine Chance haben, von Suchmaschinen direkt an Sie verwiesen zu werden. Die Welt dankt es Ihnen (manchmal sogar in Form begeisterter E-Mails).

Let me google that for you«, wird gern in Form eines Links zu hngtfy.com gereicht.

Read the fucking manuak die nicht ganz so freundliche Bitte, doch erst mal die Dokumentation zu lesen und dann wiederzukommen.

Alle Ihre Programmiertragen sind dadurch automatisch beantwortet: »Es gibt kein Problem.«

Hilfe suchen