Wie ich als Anfängerin die Tutorials lese, die du als Entwickler für mich geschrieben hast

• Ein humorvoller Text, der die Verwirrung und Hürden beschreibt, die Anfänger beim Lesen von von Entwicklern geschriebenen technischen Tutorials erleben
• Fachbegriffe und Abkürzungen, die Entwickler ständig verwenden, klingen für Anfänger völlig kontextlos wie eine „Fremdsprache von einem anderen Planeten“
• Installationsschritte, Dateipfade und Terminalbefehle sind oft übermäßig komplex oder lückenhaft erklärt und daher schwer zu verstehen
• Die Autorin weist darauf hin, dass Erklärungen, die aus Entwicklersicht selbstverständlich sind, für Anfänger zu Hindernissen werden, die stundenlange Suche und Versuch-und-Irrtum erfordern
• Der Text erinnert Entwickler, die Tutorials schreiben, daran, aus der Perspektive von Einsteigern freundlicher und klarer zu erklären

---

Hintergrund und Problemstellung

• Die Autorin beschreibt als Nicht-Entwicklerin und Anfängerin ihre Erfahrungen beim Lesen von Tutorials, die von Entwicklern geschrieben wurden
• Sie schildert satirisch die Situation, in der man überhaupt nicht versteht, was die technischen Begriffe und Tool-Namen im Tutorial eigentlich bedeuten
• Beispiel: Mit fiktiven Techniknamen wie Hoobijag, Snarfus oder Shamrock portal wird betont, wie kompliziert für Anfänger alles wirkt

---

Übersetzung des Originaltexts

„Hallo! Ich bin Entwickler. Meine einschlägige Erfahrung ist folgende: Ich code mit Hoobijag und verwende gelegentlich jabbernocks, und natürlich mache ich auch ABCDE++++ (aber niemals ABCDE+/^+, das wäre doch absurd, oder? Haha!) Und ich arbeite gern mit Shoobababoo und habe manchmal auch mit kleptomitrons zu tun. Ich kam dazu, bei Company[1] mit Shoobaboo-bezogenem Code zu arbeiten, und das führte mich zu Snarfus. Also, legen wir los!

Über dieses Tutorial

Ich fing damit an, in Snarfus eine ganz einfache Sache[2] zu machen, aber je mehr ich es benutzte, desto mehr Potenzial sah ich! chromus ist zwar etwas verheddert, aber eigentlich unglaublich vielseitig. Also fing ich an, pintafore mit quagmire statt mit hoobastank zu argylieren! Ich weiß, verrückt. Aber irgendwie funktionierte es, und ehrlich gesagt machte es ziemlich Spaß … bis ich auf eine große Hürde stieß: fisterfunk sprach überhaupt nicht mit dem shamrock portal und schickte auch keine beep-boops an Snarfus! Natürlich weißt du, was das bedeutet[3] — jetzt ist der ganze hoob-Tunnel mit gramelions verstopft. Inakzeptabel.

Ich war kurz davor aufzugeben, aber dann wurde mir klar: Wenn man den backside Snarfus stagnator mit dem backside shamrock Klingon troglodyte emulater verbindet, klappt es! Alles machte beep-boops und ding-dongs, und endlich kamen wir beim eigentlichen Thema des Tutorials an. Und ich konnte eine ganz einfache Sache auf die Art tun, wie ich es wollte! Ziemlich cool[4].

Also richtet man es so ein:

1. Gib im Terminal ajkl;gawgor;iqeg;iJLkqen. wl;R aw;oeiga 4648664 arjarwgj;llj;ja fadgfgajkljl; wlj;sdjk;lfas ein
2. Geh jetzt zu folder/hidden/deep/in/the/file/system/surprise!.file und kopiere den Dateiinhalt. Falls er dort nicht ist, könnte er auch in library/library/library/llibrary/liiiiiibrarrrary/llllliiiiibrary/hidden/hidden/hiding/you can’t find me/hidden/nope/never/hahahahereiam.file liegen
3. Geh wieder zurück ins Terminal, füge den Dateiinhalt ein und gib 64A786AGR45JAR; rdja;jg [[]][[]][[]][[]]][[]()()()()()()()()(){{}{}{}|{}{|}{}{|}{ ////////////////!! !!!! !! //// !!! agjlkargji;lwej;OI [ASRGASG[]ASGDASG[]EAEadgasg[]EAGE[edaga][]ahgr-0-0=-0-=0-=0=0-0=-0-=0=-0-=0=-0=-0!!! ein
4. Boop![5]
5. Öffne Snarfus und lade die Datei hoch, die du gerade erstellt hast
6. Nur zum Spaß kannst du auch —()()(]]asdg a=-do —cd go cd stay —sususudododo baby shark—][] ausführen, wenn du den sham der chronostatiomatrix aufheben willst. Optional
7. Fertig!

Lass mich wissen, wie es läuft. Mich würde auch interessieren, ob jemand diese Methode mit GewGawGamma oder ometer2.7 verwendet.“

---

Erläuterung der Fußnoten

1. Scheint eine bekannte Firma zu sein, aber ich kenne sie nicht
2. Überhaupt nicht einfach
3. Ich habe keine Ahnung, was das bedeutet
4. Cool ist es schon, aber verstanden habe ich es nicht. Trotzdem schön, dass du es kannst
5. Die ersten drei Schritte werden ungefähr 7 Stunden und 193 Suchanfragen brauchen. Aber wenn man Boop! erreicht, ist es ein großartiger Kick

Zum Schluss

• „Das ist nur aus Spaß geschrieben. Ein aufrichtiger Dank an alle, die ihr Wissen teilen und Tutorials schreiben.“

[GN⁺]

Hacker-News-Kommentar

• Ich kann den Ansatz nur sehr empfehlen, jemanden mit wirklich minimalem Vorwissen eine Doku Schritt für Schritt durchgehen zu lassen und dabei still daneben zu sitzen. Dabei sollte man überhaupt nicht helfen, sondern nur beobachten. So merkt man schnell, wo Nutzer hängen bleiben, welche Dinge dem Autor so vertraut sind, dass er sie gar nicht mehr wahrnimmt, oder welche Einstellungen und Voraussetzungen fehlen. Wenn die Person ihr Ziel ohne größeren Stress erreicht, hat die Dokumentation bestanden. Wenn nicht, sollte man jede einzelne Stelle notieren, an der es scheitert, sie verbessern und dann mit einer neuen Person erneut testen. Ich habe sogar Dokumentation großer Konzerne wie FAANG erlebt, die diesen Test nicht bestehen würde. Ich bin unserer Organisation wirklich dankbar, dass wir hier hohe Maßstäbe haben. Wenn man Dokumentation so erstellt, braucht es weniger wiederkehrende Meetings, Support-Anfragen und Videoanrufe, und die Nutzer können Probleme eher selbst lösen

  • Das erlebe ich oft bei der Apple-Dokumentation. Begriffe werden dort häufig einfach nur mit ihrem Namen wiederholt, ohne echte Erklärung. Das müsste viel konkreter geschrieben sein
  • Die Regel „nicht reden, nur beobachten“ klingt einfach, aber in der Praxis konnten sich viele Leute nicht zurückhalten und haben doch erklärt oder Hinweise gegeben. Manche haben sogar selbst die Maus in die Hand genommen. Um solche sehr menschlichen Reaktionen zu vermeiden, hilft es, eine neutrale Moderation zu haben und Autor bzw. Entwickler nur beobachten zu lassen. Trotzdem ist es wichtig, diese Fähigkeit des „einfach nur Zuschauens“ zu lernen, und wer weitergehen will, sollte sich das „think-aloud protocol“ ansehen
  • Die Onboarding-Dokumentation in den meisten Unternehmensteams ist so schlecht, dass sie bereits einen Vorgeschmack auf die tatsächliche Arbeitslast gibt. Bei den letzten drei Teams, zu denen ich gestoßen bin, gab es entweder fast keine Doku oder sie war veraltet, sodass ich die relevanten Leute einzeln aufsuchen musste, um an nötige Zugriffsrechte oder Infos zur Deployment-Pipeline zu kommen. Dabei schreibt man zwar neue Dokumentation, aber sobald sich Systeme oder Berechtigungen ändern, ist sie schon wieder veraltet. Nur ein einziges Team hat mir innerhalb von zwei Tagen die komplette Umgebung eingerichtet, und das war die beste Erfahrung. Ich arbeite jetzt in einem neuen DevEx-Team daran, die Dokumentationsumgebung selbst zu verbessern
  • Sich mit miserabler Setup-Dokumentation einzuarbeiten, fühlt sich wirklich zehnmal stressiger an. Ich habe immer dazu ermutigt, dass neue Mitarbeitende die Probleme, die sie erlebt haben, direkt als ihren ersten Beitrag korrigieren. Neue Leute haben keinerlei Kontext und sind deshalb oft die besten Reviewer
  • Unsere Organisation nutzt denselben Workflow. Jemand mit wenig Erfahrung folgt der Dokumentation, und danach werden alle dazu ermutigt, sie kontinuierlich zu verbessern. Neue Mitarbeitende erkennen die blinden Flecken erfahrener Leute besonders gut. Aus meiner Erfahrung ist es außerdem sehr wichtig, das Selbstvertrauen der Nutzer aktiv mitzudenken. Deshalb klappen wir bei Anweisungen wie „Führen Sie diesen Shell-Befehl aus“ standardmäßig einige Abschnitte ein, etwa ein Beispiel für erfolgreiche Ausgabe, ignorierbare Warnungen, mögliche Fehler mit Lösungen oder eine Erklärung komplexerer Befehle. Manche Schritte bekommen dadurch fast eine ganze Seite zusätzlicher Erklärung, aber gerade beim Onboarding hilft diese Detailtiefe enorm

• Der Titel des Blogposts war „Ich als Nicht-Entwicklerin lese ein Tutorial, das du als Entwickler für mich geschrieben hast“, aber auf HN wurde daraus „Ich als Anfängerin in der Entwicklung ...“. Nicht-Entwickler und Junior-Entwickler sind etwas völlig anderes. Für Leute aus HR oder komplette Quereinsteiger können schon interne Begriffe oder Grundkonzepte völlig unbekannt sein. Wenn Entwickler dafür dann Erklärungen schreiben, die komplett an der Zielgruppe vorbeigehen, ist Kritik absolut berechtigt. Ein Junior-Entwickler dagegen kann auch schwierige neue Begriffe oder Konzepte selbst nachschlagen und später vielleicht sogar die Doku für die nächsten Einsteiger aktualisieren

  • Nur zur Einordnung: Der Beitrag wurde ursprünglich mit „Nicht-Entwicklerin“ eingereicht und unterwegs in „Anfängerin in der Entwicklung“ geändert. Die Autorin ist technische Laien-Bloggerin und musste sich für Dinge wie Websites oder CSS wahrscheinlich durch verschiedene technische Dokumentationen arbeiten. Vielleicht wäre eine Diskussion über Website-Publishing und fehlende Doku für Nicht-Fachleute passender gewesen, aber es ist auch okay, wenn die HN-Community das Thema in eine andere Richtung zieht
  • Diese Unterscheidung ist wirklich wichtig. Annie beschreibt sich selbst als jemand, der mit Content bzw. Dokumentation arbeitet und CSS als Hobby betreibt, also eher als „nicht berufliche Hobby-Entwicklerin“. Ich glaube, das ist eine wachsende Gruppe. Wenn man Tutorials für Anfänger oder Nicht-Entwickler schreibt, reicht oft schon ein ganz kurzer Zusatz zu Dingen wie „cd ~/.snarfus (erstelle den Ordner, falls er nicht existiert)“. Bei meiner Debian-Installation früher hat mir genau so eine kleine Erklärung enorm geholfen
  • Eine Seite, die mich beim Einstieg ins Programmieren stark beeindruckt hat, war „FromZero“. Sie erklärte für Nicht-Entwickler alles Schritt für Schritt, von der IDE-Installation bis zum Öffnen der Konsole, und beruhigte einen bei unbekannten Begriffen mit Hinweisen wie „Das behandeln wir später, darum müssen Sie sich jetzt nicht kümmern“. Das war großartig. Natürlich kostet gute Dokumentation Zeit und Mühe, deshalb ist manchmal auch unvollständige Erklärung besser als gar keine. Aber Dokumentation für Junior-Entwickler sollte mit der Rücksicht geschrieben sein, die man Nicht-Entwicklern entgegenbringt
  • Manche behaupten, alles sei Gatekeeping, wenn es nicht maximal einfach erklärt wird, und übersehen dabei, dass man nicht ohne jedes Vorwissen sofort alles verstehen kann, nur weil es sich gerade schwierig anfühlt
  • Wenn es sich um ein Tutorial für Junior-Entwickler handelt und nicht um einen Text für erfahrene Profis, ist es trotzdem seltsam zu erwarten, dass wirklich jedes Konzept wie „Hoobijag“ oder „shamrock portal“ einzeln erklärt wird. Wir alle haben anfangs unbekannte Begriffe gegoogelt und uns so eingearbeitet

• Die meisten Tutorials sind nicht für Nicht-Entwickler gedacht, sondern eher dafür, dass Entwickler Informationen untereinander austauschen. In dieser Hinsicht ähneln sie wissenschaftlichen Arbeiten, die sich an eine bestimmte Wissensgemeinschaft richten. Daran ist nichts grundsätzlich falsch. Tatsächlich finde ich es auch praktisch, wenn ich später meine eigenen alten Notizen wiederfinden kann. Deshalb gibt es zusätzlich eigene Kurse und Lehrmaterialien für Anfänger. Wenn Tutorials jedes Mal mit 30.000 Zeichen Hintergrundwissen anfangen müssten, würde niemand bis zum Ende lesen. Andererseits kann selbst zusätzliche Kontextinformation für manche Menschen immer noch nicht ausreichen

  • Mein Sohn, 17, interessiert sich sehr für Programmierung, und ich habe ihm neulich public/private/internal/static sowie Rekursion erklärt. Ich bin gespannt, wie er beim nächsten Mal darauf reagiert
  • Ich stimme der Aussage nicht zu, dass Tutorials größtenteils nicht für Nicht-Entwickler gedacht seien. Schon die Überschrift dieses Tutorials macht klar, dass hier Nicht-Entwickler gemeint sind. Wenn Leute sich durch die Installation eines Open-Source-Projekts quälen, braucht es unbedingt Stimmen, die sagen, dass selbst sehr grundlegende Installationsanleitungen so einfach sein sollten, dass Anfänger ihnen folgen können. Ein einzelner ausgelassener Mini-Schritt kann in einem unvertrauten Bereich Stunden kosten
  • Ich finde auch nicht, dass es schlecht wäre, Dokumentation allgemein zugänglicher zu schreiben. Gute Dokumentation ist nicht nur für Anfänger, sondern auch für Entwickler nützlich. Dass zugängliche Dokumentation oft fehlt, liegt meiner Meinung nach einfach daran, dass man den kleinen Mehraufwand scheut. Außerdem sind Entwicklerdokumente im Unterschied zu wissenschaftlichen Arbeiten oft so knapp oder so gleichgültig geschrieben, dass am Ende nur Experten etwas damit anfangen können. Das ist ein Scheitern
  • Ich stimme zu, dass es Dokumentation braucht, die Kontext für Anfänger schrittweise aufbaut. Gleichzeitig sehe ich aber die Tendenz, bei DX heutzutage vor allem das „Einfache“ zu optimieren und dabei nützliche Logs oder die Möglichkeit, nach Fehlermeldungen zu suchen, zu opfern. Dann richtet sich alles nur noch an Anfänger, und bestehende Nutzer arbeiten schlechter damit
  • Heute wirken viele Tutorials eher wie Beiträge zur Pflege des eigenen Lebenslaufs nach dem Motto „Ich habe zu Projekt X beigetragen“. Wenn der Autor seinem eigenen Tutorial drei Monate später noch einmal folgen würde, würden die Lücken wahrscheinlich deutlich auffallen und das Ergebnis stark verbessern

• Viele Technical Writer sind sich des „Fluchs des Wissens“ nicht wirklich bewusst. Ich habe früher eine WoW-Gilde geleitet. Da mussten 40 Leute gleichzeitig in einen Dungeon, koordiniert mehrere Bosse bekämpfen, und ein einziger kleiner Fehler konnte den kompletten Wipe bedeuten. Deshalb versammelten sich alle in Teamspeak, und wir erklärten die Strategien vorher ausführlich. Die wichtigste Lehre daraus war: „Gehen Sie davon aus, dass die andere Person nicht weiß, wovon Sie sprechen“ und „Wiederholen Sie Dinge, auch wenn Sie sie schon einmal gesagt haben“. Die meisten unterbrechen nicht, um Fragen zu stellen, selbst wenn sie etwas nicht verstehen. Wenn man sich also ständig fragt, welche Begriffe man gerade verwendet und ob das Gegenüber das Konzept vielleicht gar nicht kennt, und dann passende Erläuterungen ergänzt, hat das enorme Wirkung. Diese Erfahrung mit Kommunikation lässt sich direkt auf Technical Communication übertragen. Wer sich bewusst darin übt, den Fluch des Wissens zu überwinden, verbessert das Verständnis anderer deutlich

  • Ich erinnere mich an einen 18-jährigen Gildenleiter aus früheren Raid-Zeiten, der Erwachsene über verschiedene Zeitzonen hinweg zusammengebracht und Beuteverteilung, Taktik und Zeitpläne reibungslos koordiniert hat. Da dachte ich nur: Dieser Mensch sollte sofort als Manager eingestellt werden
  • Wer Erfahrung mit der Leitung eines 40-Mann-Raids hat, bringt Projektmanagement-Fähigkeiten auf höchstem Niveau mit. Das ist buchstäblich, als würde man einen Haufen entlaufener Katzen effizient koordinieren

• Viele Projekt-Websites oder GitHub-READMEs sind so geschrieben, als wüsste jeder Leser sowieso schon alles. Wenn ich Doku lese, wünsche ich mir mehr Sorgfalt bei Fragen wie: Warum braucht man dieses Tool überhaupt? Welches Problem löst es? Wie unterscheidet es sich von ähnlichen Tools? Wird es heute noch aktiv genutzt? Bekommt man genug Material an die Hand, um Vor- und Nachteile selbst abzuwägen? Schon fünf Minuten Nachdenken darüber, was selbst ein Anfänger wohl wissen möchte, würden die Zugänglichkeit massiv verbessern. Es ist wirklich schade, wenn ein Projekt, in das Jahre Arbeit geflossen sind, immer wieder daran scheitert, dass Nutzer frustriert aufgeben, ohne dass die Autoren überhaupt merken, dass sie fast gewonnen waren. Und es ist wichtig, die Rolle verschiedener Dokumentationsarten zu verstehen. https://diataxis.fr/ ist dafür ein guter Ausgangspunkt

  • Im ROS-Bereich war ich ständig gestresst, weil READMEs so schlecht sind. Außer dem Projektnamen gibt es oft keinerlei Hinweis, sodass man nicht einmal den Einsatzzweck richtig erkennt. Das ist kein reines Open-Source-Problem; ich habe dasselbe auch im Job erlebt und komme mir vor wie die einzige Person, die aktiv Erklärungen in READMEs ergänzt. Die Zeit der Monorepos war für mich fast angenehmer
  • Ich verstehe, dass Entwickler ihre Tools mit viel Liebe und Arbeit bauen, aber allein bessere Dokumentation würde die Einstiegshürde stark senken. Und wenn dann auch noch die Doku anderer Komponenten im Stack schwer verständlich ist, wird die Lernkurve exponentiell steiler
  • Früher wurde auf HN sogar einmal ein Projekt gepostet, bei dem nicht einmal erklärt wurde, was es überhaupt ist

• Das Wichtigste beim Schreiben von Dokumentation ist, das Wissensniveau der Zielgruppe klar festzulegen. Ob man die Baseline hoch oder niedrig ansetzt, ist zweitrangig; wenn man sich aber zu weit von dieser Ausgangslinie entfernt, werden sich zwangsläufig einige Leser beschweren. In solchen Situationen kann man Ausreden suchen oder nach Lösungen streben. Tatsächlich lässt sich heute mit AI, Google, Büchern und Ähnlichem fast alles schnell nachschlagen. Wenn man wissen will, was „Shoobababoo“ ist oder warum man „quagmire“ verwendet, kann man danach suchen. Idealerweise sollte Dokumentation natürlich so weit wie möglich in sich geschlossen sein und ohne externe Quellen auskommen, aber die Welt ist nicht immer so entgegenkommend

  • Genau deshalb ist die gegenteilige Tendenz in vielen Setup-Guides problematisch, die bei „Doppelklicken Sie jetzt auf die exe-Datei und dann immer weiter auf Weiter“ anfangen. Die Festlegung der Baseline ist wirklich entscheidend
  • Ich schreibe hauptsächlich Dokumentation für interne sensible Systeme und setze manchmal direkt an den Anfang: „Dieser Leitfaden setzt voraus, dass Sie x, y und z bereits beherrschen. Wenn nicht, sollten Sie diese Aufgabe nicht durchführen.“ Der Zugriff ist zwar ohnehin eingeschränkt, aber für DR-Szenarien oder andere Ausnahmefälle könnte jemand damit arbeiten, der nicht eingearbeitet ist. Dann ist eine bewusst gesetzte Grenze im Sinn von „Wenn Sie das nicht verstehen, lassen Sie bitte die Finger davon“ manchmal sinnvoll

• Ein Prinzip, das ich in vielen Jahren Mentoring immer betont habe, lautet: Wissen teilt man am besten. Wenn man etwas weiß, sollte man es erklären. Wenn die andere Person es schon wusste, hat man ihr im schlimmsten Fall nur Sicherheit gegeben; wenn nicht, war es eine große Hilfe. Manchmal kommt der Vorwurf, das sei zu ausschweifend, aber wenn ich sage: „Das habe ich auch für neue Mitarbeitende, Kunden oder Manager mitgeschrieben, die das vielleicht lesen“, verstehen es die meisten. Dieses Prinzip gilt für Entwicklung, Reporting, Personalführung und eigentlich alles andere

  • Natürlich gibt es auch Menschen, die es extrem hassen, Dinge erklärt zu bekommen, die sie schon wissen. Wenn das Verhältnis von Signal zu Rauschen zu schlecht wird, kann das Kommunikation sogar eher behindern
  • Ich erlebe etwas Ähnliches dabei, meinem Sohn Billard beizubringen. Eine Kultur, in der man die Ellbogen nicht ausfährt und Tipps großzügig mit Teammitgliedern teilt, fördert Wachstum enorm. Im Mentoring ist es oft besser, nicht sofort die Antwort zu geben, sondern durch Fragen dazu zu führen, dass jemand selbst darauf kommt. Der echte Fortschritt entsteht dann, wenn es bei der Person selbst Klick macht
  • Wer allen ungefragt alles erklärt, läuft auch Gefahr, als „mansplaining“ wahrgenommen zu werden oder politisch als jemand, der sich als allwissend aufspielt. Im Unternehmen ist es manchmal sicherer, schlicht auf Fragen zu antworten, wenn sie gestellt werden

• Ich habe kürzlich versucht, mit Gitlab eine App auf DigitalOcean Kubernetes auszurollen, und musste dabei 3 oder 4 Third-Party-Tools verwenden, ohne dass erklärt wurde, was sie tun. Sogar Namen und Pfade für die Kommandozeile musste ich selbst herausfinden. Es wurde nicht erklärt, was der Maßstab ist und worauf man eigentlich achten soll. Obwohl ich mit Docker ziemlich vertraut bin, war die Dokumentation dieser Tools so unfreundlich, dass weniger davon fast besser gewesen wäre

• Der Hauptgrund, warum ich aufgehört habe, Bücher zu schreiben, und stattdessen eine Tutorial-Website gebaut habe, war die Möglichkeit, Tutorials mit interaktiven Werkzeugen wie dem <abbr>-Element für mehr Menschen zugänglich zu machen. Trotzdem frustriert es mich, dass Webinhalte heute oft immer noch auf dem Funktionsniveau eines Papierbuchs stehen. Es gibt Klicks, Hover-Zustände, einklappbare Bereiche, Videos, Nutzerreaktionen und vieles mehr, aber stattdessen bekommt man meist nur endlose Textwände. Selbst der OP verwendet Fußnoten, die einen beim Anklicken ganz ans Seitenende springen lassen, und das fühlt sich wie verschenktes Potenzial des Webs an

  • Ich arbeite gerade an einem Upgrade für meinen Blog. Wenn jemand Websites empfehlen kann, die solche interaktiven, gut gemachten Tutorials besonders gut umsetzen, wäre ich dankbar

• In Wahrheit bestehen viele Tutorials – weder für Nicht-Entwickler noch für Entwickler – einfach aus unnötig langen Texten und überspringen am Ende trotzdem genau die ein oder zwei entscheidenden Schritte. Der Hauptgrund ist wohl, dass es schwierig ist, so zu schreiben, wie man jemandem etwas tatsächlich erklären würde. Was nur im eigenen Kopf existiert und nicht ausgeschrieben wird, kann der Leser unmöglich wissen. Statt „Tutorial“ sollte man oft eher im Stil eines „Cookbook“ schreiben, damit es in der Praxis nützlicher ist und nicht mit der nächsten Version sofort unbrauchbar wird

  • Ironischerweise sind viele Online-Rezepte heute sogar noch voller überflüssigem Gerede als Blogs von Nicht-Entwicklern