Home    Hilfe zum Forum    Wie frage ich richtig?    Teilnahmebedingungen    Impressum    Disclaimer
Das Originaldokument trägt den Titel How To Ask Questions The Smart Way. Der folgende Text basiert auf der deutschen Übersetzung des englischen Originals.

Wie frage ich richtig?

Einleitung
Vor der Frage
Bei der Frage
   Wähle dein Forum sorgfältig
   Schreibe klar, grammatikalisch korrekt und ohne Rechtschreibfehler
   Wähle einen sinnvollen, genauen Betreff
   Schildere dein Problem präzise und informativ
   Umfang ist keine Präzision
   Beschreibe Symptome, nicht deine Vermutungen
   Beschreibe die Symptome in chronologischer Reihenfolge
   Sei explizit bezüglich deiner Fragen
   Stelle keine Hausaufgaben-Fragen
   Halbfertige sinnlose Anfragen
   Markiere deine Frage nicht als "wichtig" oder "eilig", selbst wenn sie das für dich ist
   Höflichkeit tut nicht weh, hilft aber manchmal
   Gib weitere Hinweise zur Lösung
Wie Antworten zu interpretieren sind
   RTFM und STFW - Wie dir gesagt wird, dass du es richtig vermasselt hast
   Wenn du nicht verstehst...

Einleitung

In der Welt von Programmierern hängt die Art der Antwort, die man bekommt, von der Art und Weise der Frage genauso ab, wie von der Schwierigkeit, eine Antwort zu finden. Dieses Dokument soll eine Anleitung geben, wie man es schafft, eine zufriedenstellende Antwort zu bekommen.

Die erste Sache, die man verstehen sollte, ist, dass Programmierer schwierige Probleme und gute, zum Denken anregende Fragen zu diesen Problemen mögen. Würden sie das nicht, wären wir nicht hier (und wir würden uns nicht bemühen, die Kommunikation zu verbessern). Wir sind dankbar für gute Fragen, an denen wir uns die Köpfe zerbrechen können, sie sind stimulierend und ein Geschenk. Gute Fragen helfen uns, unser Verständnis weiterzuentwickeln und können uns auf Probleme hinweisen, die wir vielleicht sonst nie gesehen hätten. Unter Programmierern ist "Gute Frage!" ein großes Kompliment.

Trotzdem haben Programmierer den Ruf, auf Fragen so zu reagieren, dass es feindlich oder arrogant wirkt. Es sieht manchmal so aus, als wären wir aus einem Reflex heraus unhöflich und ebenso ignorant, aber das stimmt nicht (wirklich).

Wir sind allerdings, das ist keine Entschuldigung, feindlich zu Leuten, die nicht willens zu sein scheinen, selbst zu denken oder die eigenen Hausaufgaben zu machen, bevor sie fragen. Solche Leute sind Zeitverschwendung - sie nehmen, ohne etwas zurückzugeben, sie verschwenden Zeit, die verwendet werden könnte, um andere, interessantere, Fragen zu beantworten oder anderen Leuten zu helfen, die es eher verdient haben, eine Antwort zu bekommen. Wir nennen solche Leute "Bastler".

Wir haben zur Kenntnis genommen, dass viele Leute einfach nur Fertiglösungen bekommen wollen, die sie in ihren Programmcode ohne große Änderungen übernehmen können, und kein Interesse an technischen Details haben. Für uns sind das Bastler und keine Programmierer. Wir akzeptieren zwar, dass es Leute gibt, die lieber basteln, kein Interesse an der genauen Funktionsweise des kopierten Codes haben und nicht aktiv an der Problemlösung teilhaben wollen. Diese wollen wir jedoch nicht in unserem Forum haben.

Wir sind ausschließlich Freiwillige. Wir nehmen uns Zeit, um Fragen zu beantworten, und manchmal werden wir von ihnen überschwemmt. Also filtern wir rücksichtslos. Genauer: Wir werfen Fragen weg, die anscheinend von Bastlern kommen, um unsere Zeit effizienter zu nutzen, nämlich für richtige Programmierer.

Wenn du diese Einstellung widerwärtig, herablassend oder arrogant findest, prüfe deine Annahme! Wir wollen nicht, dass du vor uns kniest - die meisten von uns würden nichts mehr befürworten, als mit dir gleichberechtigt zu verhandeln und dich in unserer Kultur willkommenzuheißen, wenn du dir die Mühe gibst, das möglich zu machen. Aber es ist einfach nicht sinnvoll für uns, jemandem zu helfen, der sich nicht selbst helfen will. Wenn du mit dieser Art der Diskriminierung nicht leben kannst, empfiehlt es sich für dich eher, einen kommerziellen Support-Dienstleister zu ordern, als einen Programmierer um Hilfe zu bitten.

Wenn du dich entscheidest, für Hilfe zu uns zu kommen, willst du kein Bastler sein. Du willst auch nicht wie einer wirken. Der beste Weg, eine schnelle und fachliche Antwort zu bekommen, ist es, wie ein richtiger Programmierer zu fragen, wie jemand mit Grips, Selbstbewusstsein und Anhaltspunkten, der nur gerade Hilfe bei einem bestimmten Problem braucht.

Vor der Frage

Bevor du eine Frage äußerst, tue Folgendes:
  1. Versuche, eine Antwort im Handbuch bzw. der Online-Hilfe zu finden.
  2. Versuche, eine Antwort in den FAQ zu finden (Easy Delphi Helper, Tipps & Tricks).
  3. Versuche, eine Antwort durch Recherche im Web zu finden.
  4. Versuche, eine Antwort zu bekommen, indem du einen Freund fragst, der sich auskennt.
Wenn du deine Frage stellst, lasse durchblicken, dass du diese Dinge getan hast und nicht ein faules Stück bist, das nur anderer Leute Zeit verschwendet. Noch besser: Zeige, dass du aus diesen Schritten bereits gelernt hast. Wir beantworten gerne Fragen, wenn wir sehen, dass du aus Antworten lernst.

Bereite deine Frage vor, denke sie durch. Hastige Fragen bekommen hastige Antworten, wenn überhaupt. Je mehr du demonstrierst, dass du Gedanken und Mühe in eine Problemlösung gesteckt hast, desto wahrscheinlicher ist es, dass du eine Antwort bekommst.

Hüte dich davor, eine dumme Frage zu stellen. Dumme Fragen, dies sind z. B. Fragen, die auf falschen (dummen) Annahmen beruhen, demotivieren den Programmierer, dir eine sinnvolle Antwort zu geben. Zum einen muss der Programmierer bei einer solchen Frage meist raten, um was es dir wirklich geht. Zum anderen zeigt ihm eine solche Frage, dass du dich noch nicht genügend mit dem Problem beschäftigt hast, um dazu eine Frage richtig zu stellen, und damit auch, um eine Antwort darauf wirklich zu verstehen.

Nimm nie an, du hättest ein Anrecht auf eine Antwort. Das hast du nicht, denn du bezahlst ja schließlich nicht für den Service. Du bekommst eine Antwort, wenn du eine bekommst, indem du eine solide, interessante und zum Denken provozierende Frage stellst - eine Frage, die implizit der Gemeinschaft etwas gibt und nicht nur passiv Wissen von jemandem verlangt.

Auf der anderen Seite ist es ein sehr guter Anfang, wenn du verdeutlichst, dass du in der Lage und willig bist, eine Lösung selbst zu finden. "Kann mir jemand einen Wink geben?", "Was fehlt in meinem Beispiel?" und "Gibt es eine Website, die mich weiterbringt" sind wesentlich erfolgversprechender als "Ich hätte gern die exakte Prozedur, der ich folgen muss", denn du zeigst, dass du daran interessiert bist, selbst weiterzumachen, wenn dir jemand einen Stoß in die richtige Richtung gibt.

Bei der Frage

Wähle dein Forum sorgfältig!

Bedenke gut, wo du deine Frage stellst. Du könntest ignoriert oder als Bastler abgestempelt werden, wenn du:

  • deine Frage in einem Forum stellst, in dem sie vom Thema abweicht (off-Topic)
  • in zu vielen Foren crosspostest (also die gleiche Frage an mehreren Stellen stellst)
  • eine persönliche E-Mail an jemanden schickst, den du gar nicht kennst oder der überhaupt nicht für dein Problem verantwortlich ist
Programmierer schmettern Fragen ab, die falsch platziert sind, um ihre Kommunikationswege davor zu schützen, in Irrelevanz zu versinken. Sie wollen nicht, dass dir das passiert.

Eine E-Mail an jemanden zu verschicken, den du nicht kennst, ist riskant. Nimm z.B. nicht an, dass der Autor einer informativen Website dein freier Berater sein will. Mache dir keine optimistischen Hoffnungen, dass deine Fragen willkommen sind - wenn du unsicher bist, schicke deine Frage woanders hin oder lasse es ganz.

Schreibe klar, grammatikalisch korrekt und ohne Rechtschreibfehler

Die Erfahrung hat gezeigt, dass Leute, die sehr oberflächlich Texte verfassen, auch oberflächlich denken und programmieren. Solchen Leuten Fragen zu beantworten, ist wenig ertragreich; man sollte seine Zeit besser anderweitig verwenden.

Deine Frage klar zu formulieren ist wichtig. Wenn dir das zu mühsam ist, ist es uns zu mühsam, dir Aufmerksamkeit zu widmen. Betreibe den Aufwand, und poliere deine Sprache auf. Sie soll nicht steif oder formal sein - zwanglose, humorvolle Sprache, mit Präzision angewandt, hat in der Programmierer-Kultur einen hohen Wert. Aber sie muss präzise sein, man muss erkennen, dass du denkst und aufmerksam bist.

Achte auf Rechtschreibung, Interpunktion und Groß-Klein-Schreibung. Schreibe NICHT ALLES GROSS, das impliziert ein Schreien und wirkt daher sehr unhöflich. (Alles klein zu schreiben, ist kaum weniger unangenehmen, denn es liest sich sehr schlecht.)

Generell: Wenn du wie ein halb-gebildeter Trottel schreibst, wirst du wahrscheinlich ignoriert. Sich als c00les script kiddie zu outen ist der absolute Todeskuss und garantiert, dass du absolute Stille (oder vielleicht ein Haufen Hohn und Sarkasmus) als Antwort erhältst.

Wähle einen sinnvollen, genauen Betreff

In Foren hast du mit dem Betreff eine ideale Möglichkeit, die Aufmerksamkeit qualifizierter Experten mit 50 oder weniger Zeichen zu erlangen. Verschwende diese nicht mit Gestammel wie "Brauche Hilfe" (ganz zu schweigen von "BRAUCHE HILFE"; Fragen mit einem solchen Betreff werden schon aus Reflex überlesen). Versuche nicht, uns mit dem Gewicht deines Problems zu beeindrucken; nutze den Platz für eine präzise Problembeschreibung.

Eine sinnvolle Konvention für Betreffzeilen, die oft von Technik-Support-Organisationen verwendet wird, ist "Objekt - Abweichung". Das "Objekt" ist das Ding bzw. die Gruppe von Dingen, mit denen du ein Problem hast, und die "Abweichung" beschreibt eben die Abweichung vom erwarteten Verhalten.

Dumm:
HILFE! Anzeige funzt nicht auf meinem Laptop!
Klug:
XFree86 4.1 verformter Maus-Zeiger, Fooware MV1005 Video Chipsatz
Klüger:
XFree86 4.1 Mauszeiger mit Fooware MV1005 Video Chipsatz - ist verformt

Der Prozess des Verfassens eines "Objekt-Abweichung"-Betreffs hilft dir, detaillierter über dein Problem nachzudenken. Was ist betroffen? Nur der Mauszeiger oder auch andere grafische Elemente? Passiert das Ganze nur mit XFree 86? Nur mit Version 4.1? Hängt es mit den Fooware Video-Chipsätzen zusammen? Mit dem Model MV1005? Ein Programmierer, der das sieht, kann sofort erkennen, womit du ein Problem hast, und was für ein Problem es ist.

Schildere dein Problem präzise und informativ

  • Beschreibe Symptome deines Problems klar und sorgfältig.
  • Beschreibe die Umgebung (Maschine, OS, Programm, ...).
  • Beschreibe deine bisherigen Recherchen, um das Problem zu verstehen.
  • Beschreibe die Diagnoseschritte, die du gegangen bist, um das Problem bis zum jetzigen Stand zu lokalisieren.
  • Nenne eventuelle Änderungen deines Systems, die dir relevant erscheinen.
  • Versuche, die Fragen, die dir gestellt werden könnten, so gut wie möglich vorauszusehen, und beantworte sie im Voraus.

Umfang ist keine Präzision

Du solltest präzise und informativ sein, das erreichst du aber nicht, indem du riesige Mengen von Code und Daten in deine Nachricht hineinpumpst. Wenn du einen großen, komplizierten Testfall hast, versuche, ihn auf ein Minimum zu reduzieren.

Das ist für mindestens 3 Dinge wichtig:
  1. Wenn sichtbar ist, dass du dir die Mühe und die Gedanken machst, ein Problem zu vereinfachen, ist eine Antwort wahrscheinlicher.
  2. Die Frage zu simplifizieren, erhöht auch die Wahrscheinlichkeit, eine sinnvolle Antwort zu bekommen.
  3. Durch den Prozess der Verkürzung und Vereinfachung kannst du selbst eine Lösung finden.

Beschreibe Symptome, nicht deine Vermutungen

Es ist nicht sinnvoll vorwegzunehmen, was du denkst, was den Fehler verursacht. (Wenn deine Diagnosen gut wären, würdest du dann um Hilfe fragen?) Stelle sicher, dass du nur die wirklichen Symptome beschreibst, nicht deine Interpretationen oder Theorien. Lasse den Helfenden interpretieren und diagnostizieren.

Beschreibe die Symptome in chronologischer Reihenfolge

Die brauchbarsten Erkenntnisse beim Feststellen von Fehlerursachen liegen in den Ereignissen kurz davor. Deine Erläuterungen sollten also präzise beschreiben, was du getan hast und was die Maschine getan hat, bis es zum Problem kam. Bei Programmierangelegenheiten ist die Zeile, in der ein Programm abbricht, sowie die relevanten Zeilen davor, sehr nützlich.

Wenn deine Ausführungen am Ende lang werden (mehr als etwa vier Absätze), ist es sinnvoll, das Problem zu Anfang zu klären und dann die Geschichte chronologisch zu verfassen. So wird der Leser wissen, wonach er im Text suchen will/muss.

Sei explizit bezüglich deiner Fragen

Fragen mit offenem Ende werden als Zeitverschwendung mit offenem Ende angesehen. Die Leute, die am ehesten eine brauchbare Antwort geben können, sind auch die Beschäftigtsten. Diese Leute reagieren allergisch auf Zeitverschwendungen ohne Ende, also auch auf Fragen mit offenem Ende.

Du wirst mehr Erfolg haben, wenn du auch explizit äußerst, was du vom Antwortenden willst (Hinweise, Code, Links, ...). Das gibt deren Anstrengungen ein absehbares Ziel und begrenzt den zu erwartenden Aufwand bereits nach oben. Das ist gut.

Um die Welt, in der Experten leben, besser zu verstehen, sieh Expertise als umfangreiche Ressource an, Zeit zum Antworten als eher spärliche. Je weniger Zeitverbrauch du implizit von einem Antwortenden erwartest, desto wahrscheinlicher wird es, eine Antwort von einem sehr guten und wirklich beschäftigten Experten zu bekommen.

Es ist also sinnvoll, den Rahmen der Frage auf einen minimalen Zeitaufwand, sie zu beantworten, zu minimieren - aber das ist oft nicht gleichbedeutend mit Vereinfachung der Frage. So ist die Frage "Kann mir jemand einen Verweis auf eine gute Erklärung von X geben?" einfach klüger als "Kann mir jemand bitte X erklären?". Wenn du Code hast, der nicht funktioniert, ist es klüger, nach einer Erklärung des Fehlers zu fragen, als nach eine Behebung desselben.

Stelle keine Hausaufgaben-Fragen

Programmierer erkennen Hausaufgaben sehr gut; sie haben sie selbst einmal gemacht. Diese Fragen sind für dich gedacht, du sollst daraus lernen. Es ist in Ordnung, nach Hinweisen zu fragen, aber nicht nach Fertiglösungen.

Halbfertige sinnlose Anfragen

Widerstehe der Versuchung, deine Anfrage mit semantisch nichtigen Fragen wie "Kann mir jemand helfen?" oder "Gibt es eine Antwort?" zu beenden. Erstens: Wenn du dein Problem halbwegs kompetent beschrieben haben, sind solche angehängten Fragen allerhöchstens überflüssig. Zweitens: Weil sie überflüssig sind, werden sie als störend empfunden - und du wirst vermutlich völlig korrekte, aber wenig hilfreiche Antworten wie "Ja, man kann helfen." oder "Nein, dafür gibt es keine Lösung." bekommen.

Generell gilt es, Ja-oder-Nein-Fragen zu vermeiden, wenn man keine Ja-oder-Nein Antworten will.

Markiere deine Frage nicht als "wichtig", selbst wenn sie das für dich ist

Es ist dein Problem, nicht unseres. Priorität anzumelden ist eher kontraproduktiv: Die meisten Programmierer werden solche Nachrichten als ungehobelte und egoistische Versuche, schnelle und spezielle Hilfe zu erhalten, ignorieren.

Höflichkeit tut nicht weh, hilft aber manchmal

Sei höflich. Sage "Bitte" und "Danke im Voraus". Stelle klar, dass du die Zeit, die andere für dich opfern, schätzst.

Ehrlich gesagt, ist Höflichkeit nicht so wichtig wie grammatikalische Korrektheit, Klarheit, Präzision, ausreichende Beschreibung etc. (und kann diese auch nicht ersetzen); Programmierer bevorzugen eher schroffe, aber technisch exakte Bug-Reports als höfliche Unsicherheit. (Wenn dich das verwirrt, denke daran, dass wir eine Frage danach bewerten, was sie uns lehrt.)

Wenn du also all das Technische auf die Reihe bekommen hast, erhöht Höflichkeit deine Chancen, eine sinnvolle Antwort zu bekommen, ungemein.

Gib weitere Hinweise zur Lösung

Schreibe nach der Lösung deines Problems eine Antwort für alle, die dir geholfen haben; lasse sie wissen, wie sich alles geklärt hat, und danke getrost ein weiteres Mal für die Hilfe.

Deine Antwort muss nicht lang oder kompliziert sein; ein einfaches "Es war ein kaputtes Netzwerk-Kabel. Danke an alle, Bill" ist auf jeden Fall besser als nichts. Eigentlich ist eine kurze Zusammenfassung sogar besser als eine lange Dissertation, es sei denn die Lösung hat derartige technische Tiefe. Sage, welche Aktion dein Problem gelöst hat, du brauchst aber nicht die ganze Fehlerbehebungsgeschichte nachzuspielen.

Für Probleme mit einiger Tiefe ist es angebracht, eine Zusammenfassung der ganzen Geschichte anzugeben. Beschreibe das finale Problem, beschreibe, was als Lösung funktioniert hat, und weise auf vermeidbare Sackgassen hin. Nenne die Namen derer, die dir geholfen haben; so gewinnst du Freunde.

Neben Höflichkeit und Information wird diese Art von Feedbacks anderen helfen, die das Archiv des Forums nach einer Lösung dieses Problem durchsuchen.

Letztendlich kann diese Art von Feedback jedem Beteiligten ein gewisses zufriedenstellendes Gefühl der Abgeschlossenheit des Problems geben. Wenn du selbst kein Techie oder Programmierer bist, glaube uns, dass dieses Gefühl für die Gurus und Experten, die dir geholfen haben, wirklich wichtig ist.

Bedenke, dass du in der Lage bist, zu verhindern, dass andere das gleiche Problem bekommen. Frage dich, ob eine Dokumentation oder Erweiterung der FAQ hilfreich wäre, und wenn die Antwort "ja" ist, schicke dieses Material an den Verantwortlichen (webmaster@delphi-groups.de)!

Unter Programmierern ist dieses Verhalten sogar wichtiger als konventionelle Höflichkeit. Es ist ein Weg, Anerkennung für gute Zusammenarbeit zu bekommen, was eine wertvolle Anlage sein kann.

Wie Antworten zu interpretieren sind

RTFM und STFW - Wie dir gesagt wird, dass du es richtig vermasselt hast

Es gibt eine alte und heilige Tradition: Wenn du die Antwort "RTFM" erhältst, meint der Antwortende, du hättest das verdammte Handbuch lesen sollen (Read The Fucking Manual). Derjenige hat fast garantiert recht. Lies es.

RTFM hat einen jüngeren Verwandten: Wenn jemand schreibt "STFW", meint er, du solltest das verdammte Web durchsuchen (Search The Fucking Web). Auch das ist im Grunde immer richtig. Durchsuche es.

Oft hat die Person, die diese Antwort gibt, das Web oder Handbuch direkt vor sich und sieht die Informationen, die du suchst, während sie diese Antwort verfasst. Diese Antworten bedeuten, dass derjenige meint, (a) diese Antworten sind leicht zu finden und (b) du lernst mehr, wenn du diese Informationen selbst suchst, als wenn man sie dir vorkaut.

Bekommst du die Antwort: "Dies ist eine dumme Frage", dann überlege, was diesen Eindruck erweckt hat und formuliere die Frage neu. Frage dich dabei auch, ob der Ansatz überhaupt sinnvoll ist.

Du solltest dich nicht angegriffen fühlen; derjenige zeigt dir eine raue Art von Respekt, indem er dich nicht ignoriert. Du solltest ihm lieber für seine großmütterliche Güte danken.

Wenn du nicht verstehst...

Wenn du die Antwort nicht verstehst, verlange nicht sofortige Aufklärung. Verwende die gleichen Methoden, die du probiert hast, um deine Ausgangsfrage zu beantworten (Handbücher, FAQs, das Web, Freunde), um die Antwort zu verstehen. Wenn du dann immer noch nicht weiter weißt, zeige, was du gelernt hast.



Copyright © 2002 Delphi-Groups.de