Hallo 👋
Bist du hier, weil dich jemand auf diesen Beitrag verwiesen hat, als Reaktion darauf, dass du eine Idee vorgeschlagen hast, wie Exercism verbessert werden könnte?
Bevor unser Team Zeit in die Prüfung deiner Idee investiert, hofft es, dass du das hier liest und dir überlegst, ob es deine Idee vielleicht schon einmal gab und welche Fallstricke sie mit sich bringen könnte.
Wenn du diese Überlegungen und möglichen Fallstricke in deinen Vorschlag einbeziehst und dir Gedanken machst, warum deine Idee nicht schon längst umgesetzt wurde, bekommst du wahrscheinlich schneller eine positivere Antwort.
Was bedeutet „Chesterton's Fence"?
Chesterton's Fence ist eine Idee, die von einem Zitat aus dem 1929 erschienenen Buch The Thing des Schriftstellers G.K. Chesterton inspiriert ist.
Bekannt wurde sie, weil John F. Kennedy sie zitierte.
Das ist das Originalzitat:
In einem solchen Fall gibt es irgendeine Einrichtung oder ein Gesetz; sagen wir der Einfachheit halber, einen Zaun oder ein Tor, das quer über eine Straße errichtet wurde.
Der modernere Typ von Reformer geht fröhlich darauf zu und sagt: „Ich sehe den Nutzen nicht; reißen wir es ab."
Worauf der intelligentere Typ von Reformer gut daran täte zu antworten: „Wenn du den Nutzen nicht siehst, werde ich es ganz sicher nicht abreißen lassen. Geh weg und denk nach. Wenn du dann zurückkommen und mir sagen kannst, dass du den Nutzen siehst, erlaube ich dir vielleicht, es zu zerstören."
Die Idee hinter Chesterton's Fence ist: Wenn du nicht verstehst, warum etwas da ist, verstehst du wahrscheinlich auch nicht, warum es entfernt werden sollte.
Genauso: Wenn du nicht verstehst, warum etwas nicht da ist, verstehst du wahrscheinlich nicht, warum es weggelassen wurde.
Eine einfache Regel zum Merken: „Entferne keinen Zaun, bevor du weißt, warum er überhaupt errichtet wurde."
Was hat das mit Exercism zu tun?
Bei Exercism haben wir das Glück, dass ständig viele Menschen unserer Community beitreten und ihre Gedanken und Ideen posten.
Viele dieser Ideen sind neu, innovativ, spannend und bringen unser Denken voran.
Wenn du also eine Idee oder einen Vorschlag hast, freuen wir uns darüber!
Häufiger posten Leute aber Ideen, die schon viele Male diskutiert wurden.
Auf solche Ideen zu antworten und unsere Entscheidungen immer wieder neu zu begründen oder zu rechtfertigen, kann für unser Team extrem kräftezehrend sein.
Dieser Artikel soll helfen, diese Zeit und Energie zu schützen.
Exercism wurde von Tausenden sehr talentierter Menschen entworfen, konstruiert und gebaut.
Es ist ein sehr bewusst gestaltetes Produkt: Dinge sind da, weil sie dort sein sollten, und Dinge fehlen oft, weil sie bewusst weggelassen wurden.
Fast alles bei Exercism wurde viele Male diskutiert, debattiert und neu umgesetzt.
Bevor du deine Idee postest, frag dich also bitte, ob wir sie nicht vielleicht schon in Betracht gezogen haben und warum wir manches anders gemacht haben könnten, als du es vorschlägst.
Und denk daran: Je offensichtlicher deine Idee erscheint, desto wahrscheinlicher wurde sie schon viele Male diskutiert und debattiert. Wenn du sie also vorstellst, stelle sie gleich mit den möglichen Einschränkungen und Fallstricken vor.
Wenn du das Bedürfnis hast zu sagen „warum nicht einfach ...", dann fällt sie fast sicher in diese Kategorie.
Hab niemals Angst davor, etwas zu posten, aber denk bitte vorher gründlich nach!
Hast du ein Beispiel?
Ein häufiger Frust ist, dass Lernende Code bei Mentoren einreichen, der die Tests nicht besteht.
Ein ebenso häufiger Vorschlag lautet: „Warum führen wir die Tests nicht einfach automatisch in der Kommandozeile aus, bevor jemand seinen Code einreicht?"
Das klingt nach einer großartigen Idee: Die Kommandozeile ruft einfach einen Befehl auf, der die Tests ausführt, und lässt die lernende Person nicht einreichen, wenn die Tests fehlschlagen.
Was heißt es also zunächst einmal, „einfach einen Befehl aufzurufen, der die Tests ausführt"?
Es heißt, für jede der 52 Sprachen auf Exercism ein Skript zu schreiben, das die Tests ausführen und das Ergebnis prüfen kann.
Das ist etwas Aufwand, aber machbar.
Es heißt aber auch, dieses Skript so zu schreiben, dass es auf Windows, MacOSX und Linux läuft, und zwar in jeder möglichen Version und Konfiguration. Das ist eine Menge Arbeit, um nicht zu sagen unbegrenzt viel.
„Warum muss es denn jede Konfiguration sein?", fragst du vielleicht?
Nun, weil du damit jemanden aktiv daran hinderst, Exercism zu nutzen, wenn er dieses Skript nicht ausführen kann.
Das bedeutet auch, dass es niemals fehlschlagen darf.
Wenn das Skript aus irgendeinem Grund nicht läuft, ist die lernende Person komplett blockiert.
Ein Fehler in einem dieser 52*3*n Skripte heißt, dass eine lernende Person den Track auf diesem Betriebssystem nicht mehr nutzen kann.
Wie willst du das testen?
Kannst du nicht.
Aber, sagst du, du könntest einfach eine Option --skip-tests hinzufügen.
Das ist ein guter Vorschlag, aber er führt uns zurück zu unserem Ausgangspunkt: Leute können die Tests überspringen, wann immer sie wollen.
Nur sind wir jetzt in einer Situation, in der es etwas unwahrscheinlicher ist, dass fehlerhafte Tests eingereicht werden, sodass Mentoren das auch seltener erwarten. Das heißt, es ist umso verstörender und verwirrender, wenn die Tests doch fehlschlagen.
„Aber das würden die Leute im Allgemeinen nicht tun", könntest du einwenden. Stimmt, bei manchen Sprachen, bei denen die Tests 0,5 Sekunden brauchen.
Aber bei Sprachen, bei denen die Tests 20 Sekunden dauern, ist es für Lernende unglaublich frustrierend, zum Einreichen noch einmal 20 Sekunden warten zu müssen, und deshalb würde das Überspringen der abschließenden Tests zur Normalität werden.
Unabhängig davon, wo dieses Gespräch endet, ist klar, dass hier viel mehr Komplexität im Spiel ist, als es zunächst scheint. Es gibt technische Herausforderungen zu bedenken, Workflow-Probleme zu bedenken und die Erkenntnis, dass Tracks sich so stark unterscheiden, dass etwas, das für den einen schnell und einfach ist, für den anderen mühsam ist.
Statt also den Vorschlag zu machen „warum führen wir die Tests nicht vor dem Einreichen aus", stellen wir lieber eine Frage: „Warum posten Leute Lösungen, die die Tests nicht bestehen?"
Und dann wird es interessant.
Die allgemeine Antwort ist: weil sie feststecken oder verwirrt sind.
Und weil sie Hilfe brauchen.
Das heißt, dass das Einreichen fehlerhafter Tests für Mentoren ein sehr wichtiger Hinweis darauf ist, dass diese lernende Person Hilfe braucht.
Ja, das ist frustrierend, weil Mentoren nicht sofort wissen, ob der Code „korrekt" ist oder nicht. Sie können den Code aber herunterladen und ausführen, um es zu überprüfen (was die meisten Mentoren bei nicht trivialen Lösungen tun), und wissen dann mit 100 % Sicherheit, ob er korrekt ist oder nicht.
Und die Lernenden, die feststecken und Hilfe brauchen, stecken am Ende nicht tiefer fest und brauchen nicht noch mehr Hilfe, sondern landen bei einem Mentor, der Korrekturen schneller sieht und vorschlagen kann.
Anmerkung: Wir lösen das inzwischen, indem wir die Tests serverseitig ausführen. Das ist ein großes und teures Unterfangen, aber die Mühe lohnt sich für ein besseres Erlebnis für die Lernenden und spart unseren Mentoren vor allem Zeit und Energie.
Sonst noch etwas?
Drei Dinge:
-
Dieser Artikel zu Second Order Thinking ist lesenswert. Das Zitat „Entferne keinen Zaun, bevor du weißt, warum er überhaupt errichtet wurde" stammt aus diesem Beitrag.
- G.K. Chestertons The Thing gibt es hier: https://archive.org/details/G.K.ChestertonTheThing.
- Deine Idee könnte wirklich neu und großartig sein. Hab keine Angst und schäm dich nicht, sie vorzuschlagen!
