Mehr „nutzlose“ Software schreiben
(ntietz.com)- Nutzlose Software ist ein spielerischer Weg, sich vom Druck praktischer Ergebnisse zu lösen und die Freude am Computing wiederzuentdecken; auch Hurl war ein Experiment, das als „Witz“ begann
- Techniker und Entwickler arbeiten oft lange in Umgebungen, in denen sie nützliche Ergebnisse liefern sollen, wodurch die Freude, die sie einst zum Programmieren gebracht hat, verblassen kann
- Bei Spielprojekten legt man Tests, Issue-Tracker und den Maßstab für „fertig“ selbst fest und kann jederzeit aufhören, sobald man genug gelernt hat oder der Spaß verschwunden ist
- Eine Chess-Engine, ein Key-Value-Store mit Teilen der Redis API, ein Wake-on-LAN-Dienstprogramm, eine Schachvisualisierung und eine Schachdatenbank waren Experimente, um GUI-, System-, Netzwerk- und Datenbank-Interna zu lernen
- Computer weniger ernst zu nehmen und etwas zu bauen, das „nutzlos wirkt“, ist ein praktikabler Weg, gleichzeitig zu lernen und Spaß zu haben
Die Freiheit des „Nutzlosen“
- Zu Hurl wurde die Frage gestellt: „Warum hast du das gebaut?“; die kurze Antwort lautete: für einen Witz
- Die längere Antwort ist, dass nutzlose Software dabei hilft, die Freude am Computing und am Erkunden zu erleben
- Menschen in technischen Berufen sind normalerweise daran gebunden, Nützliches zu bauen
- Software Engineers schreiben Code, der echte Probleme löst
- Informatiker erforschen Probleme, um neue und praktische Ergebnisse zu schaffen
- Technische Redakteure arbeiten mit realer Technik und realer Dokumentation
- Viele Menschen, die mit dem Programmieren angefangen haben, hatten dabei auf die eine oder andere Weise Spaß, und dieses Gefühl könnte auch bei der Berufswahl eine Rolle gespielt haben
- Wenn man den ganzen Tag nützliche Dinge tun muss, lässt das Interesse leicht nach
- Was man tun muss, ist mit Pflicht und Druck verbunden
- Jede Aktivität ist direkt mit der Arbeit selbst verknüpft
- Dabei geht das wichtige Element des Spiels leicht verloren
- Nutzlose Software ist ein Weg, sich von solchen Pflichten zu lösen
- Man kann selbst bestimmen, was man aus dem Projekt mitnehmen will
- Man kann jederzeit aufhören
- Wenn man keine Tests schreiben will, kann man sie weglassen
- Wenn man keinen Issue-Tracker nutzen will, kann man ihn verwerfen
- Wenn man das gelernt hat, was man lernen wollte, und der Spaß weg ist, kann man das Projekt beenden
Projekte, die aus Spiel entstanden sind
- Die schreckliche Chess-Engine mit UI war voller Bugs, wurde aber zum Anlass, GUI-Programmierung, Spieleprogrammierung und die Funktionsweise von Chess-Engines besser zu verstehen
- Der Key-Value-Store diente dazu, durch die Implementierung von Teilen der Redis API Systemprogrammierung und effizienteres Schreiben von Code zu lernen
- Das Wake-on-LAN-Dienstprogramm war ein Projekt, um zu verstehen, wie WOL funktioniert, und um Netzwerkprogrammierung in Rust zu lernen
- Die Visualisierung von Schachpartien machte es möglich, zu experimentieren, wie man mit Code Kunst schafft und ein Lieblingsspiel visualisiert
- In der Schachdatenbank wurde viel über Bitmaps und Datenbank-Interna gelernt
- Es wurde auch ein LLM-basiertes Tool gebaut, das erklärt, was Befehle tun
- Die serverseitige Implementierung des POP3-Protokolls blieb unvollendet, aber es machte Spaß, das Protokoll zu lernen und sich vorzustellen, wie eine POP3-basierte App aussehen könnte
- Beim Nachbauen von „Crafting Interpreters“ in Rust wurde viel über Interpreter und Compiler gelernt; das Ziel war nicht Vollendung, sondern Freude daran
- „Mazes for Programmers“ wurde in Rust etwa zur Hälfte umgesetzt und dann gestoppt, weil es zur Arbeit geworden war; weiterzumachen bestand kein Interesse
- Auch kleine Skripte wurden geschrieben, um mit Ideen und Konzepten zu spielen und zu experimentieren
- Hurl ist ebenfalls eine Form dieses Spiels; auch wenn es nicht nützlich ist, kann man beim Lernen und Bauen von etwas trotzdem Spaß haben
1 Kommentare
Hacker-News-Kommentare
Ich mag es, nutzlose Software zu bauen. Allein dieses Jahr habe ich das Uncolouring Book unter https://lines.potato.horse, MeatGPT unter https://meat-gpt.sonnet.io, die Medieval Content Farm unter https://tidings.potato.horse, You deserve butter unter https://butter.sonnet.io, Mrr unter https://mrr.sonnet.io und das physikalisch korrekte Mrr unter https://mrrr.sonnet.io gemacht.
Einige davon sind eigentlich eher aufwendig gestaltete Blogposts und wurden übertrieben ausgebaut, weil es einfacher war, sich spielerisch mit Code auszudrücken, als ein echtes Problem zu lösen. Eine längere Liste gibt es unter https://sonnet.io./projects
Mein 8-jähriges Kind macht jeden Tag Scratch, und ich helfe oft, wenn es Fragen gibt. Es hat ziemlich viel Spaß gemacht, einfach zum Spaß ein schräges Projekt zu bauen, sogar mit nutzlosen Animationen. Dadurch ist bei uns zu Hause jetzt „Hurry to love! Hurry to love!“ zum geflügelten Wort geworden
Tatsächlich hatte ich ziemlich viele davon vergessen
Stimme völlig zu. Ich war kürzlich auf einer Clownschule und habe dabei gemerkt, dass ich viel zu sehr darauf fixiert war, Projekte „richtig“ oder „gut“ zu machen.
Das Leben will gelebt werden, und wenn man Software zu sehr „korrekt“ machen will, presst man den Spaß heraus. Deshalb versuche ich in letzter Zeit, mit mehr Freude Code zu schreiben; dadurch schreibe ich auch viel mehr Code, und es fließt leichter. Vor Kurzem habe ich mir eine Binary-Serialization-Library im protobuf-Stil gebaut, um Ideen zur Schema-Evolution auszuprobieren, und jetzt baue ich eine CRDT-basierte Local-First-Datenbank. Gestern hat die erste Datensynchronisierung funktioniert, und ich war richtig begeistert. Ich habe über Jahre viel Code geschrieben, um Serious Problems zu lösen, und auch viel impulsiv entstandenen Code; ironischerweise ist der Code, auf den ich am stolzesten bin, der, den ich zum Spaß gebaut habe. Zu spaßigen Projekten kehre ich immer wieder zurück, um sie zu pflegen und zu verbessern, während ernste Projekte oft verwelkten und starben, sobald ich weg war.
Statt in einen Flow zu kommen und dem Prozess zu vertrauen, fangen Leute in Spielen an, Guides für den stärksten Charakter zu lesen, Werte zu maximieren und 100 % Completion anzustreben. Am Ende verschwinden die Erkundung und die Freude an zufälligen Begegnungen, die das Spiel eigentlich gut gemacht haben, und man verbringt seine Zeit damit, Werte zu maximieren, als würde man zufällig Würfel werfen. Bei anderen Aktivitäten ist es ähnlich: Während man irgendetwas maximieren will, sei es Reichtum oder Codequalität, verschwinden das Staunen und das „einfach mal machen“.
https://www.asc.ohio-state.edu/kilcup.1/262/feynman.html
Dann geriet ich ins Optimieren, und plötzlich wurde es zu einem Spiel mit genau einer richtigen Antwort; über Nacht war der ganze Spaß weg. Oft lernt man mehr, wenn man aus Übermut und Laune etwas miserabel baut. Der Gedanke „Wie schwer kann das schon sein?“ hat mich mehrmals in Tiefen geführt, denen ich kaum gewachsen war, aber beim Herauskommen habe ich immer enorm viel gelernt und auch Spaß gefunden
In jedem Handwerk gibt es etwas Kontraintuitives. Wenn man einfach mehr davon macht, wird man meistens irgendwann besser. Schreib miserable Kurzgeschichten, töpfere hässliche Schalen, male schiefe Landschaften.
Übungseffekt spielt sicher eine Rolle, aber es liegt auch stark daran, dass wir dazu neigen, Ideen selbst zu verwerfen, wenn wir das erwartbare Endprodukt nicht vollständig vor uns sehen. Besonders für analytische Menschen fühlt sich das wie eine kluge Entscheidung an, um Zeitverschwendung zu reduzieren, ist aber zugleich ein sicherer Weg, gar nichts zu schaffen. Viele „nutzlose“ Softwareprojekte blieben auch weiterhin nutzlos, aber bei manchen fand sich im Bauen ein größerer Nutzen. Am Ende läuft es auf so ein abgedroschenes „100 % der Schüsse, die du nicht nimmst, gehen daneben“ hinaus, aber ihr wisst, was gemeint ist.
Es geht dabei nicht nur darum, „nutzlose“ Software zu schreiben, sondern bei kleinen Projekten auch darum, sogenannte Best Practices zu vermeiden.
Ich habe einen Static-Site-Generator für einen Artikelkatalog gebaut; der Katalog ist simpel und ändert sich nicht oft. Nachdem ich überlegt hatte, welche Datenbank ich verwenden sollte, entschied ich mich am Ende, alles in ein statisches Array in der Codebasis zu packen. Eine Abhängigkeit weniger, über die ich nachdenken muss, und für meinen Zweck passt es perfekt.
Ich weiß nicht, ob das tatsächlich umgestellt wurde, aber seitdem ist das immer die erste Frage, die ich stelle, wenn jemand sagt: „Wir brauchen eine Datenbank.“
Da ich ohnehin alle Daten in den Speicher lade, um Graphalgorithmen auszuführen, wurde mir klar, dass es kaum Sinn ergibt, schreibgeschützte Daten in einer Datenbank zu speichern. Ich habe absolut nicht vor, Bellman-Ford in SQL zu implementieren.
Das habe ich beim Coden mit einem Freund gelernt, den ich für einen miserablen Coder hielt.
Wir verstanden uns gut und haben viele spaßige Projekte zusammen gemacht, aber er wirkte wirklich so, als wüsste er nicht, was er tat. Überall Copy/Paste, keine Architektur, kein Design, schlechte Namensgebung, und die Hälfte der Zeit war er sich nicht einmal sicher, was der Code tatsächlich machte. Aber er funktionierte. Irgendwann wurde mir klar, dass er mehr zustande brachte als ich. Er hing sich nicht an Kleinigkeiten auf und arbeitete viel mehr. Unit-Tests schrieb er nicht, aber er spielte mit dem Ergebnis wie ein Kind und testete es ständig manuell. Am Ende habe ich diese Denkweise übernommen. Ich fand keine Kontaktverwaltungssoftware, die das tat, was ich wollte, also wollte ich selbst eine bauen; statt eine ausgefeilte UI zu entwickeln, nahm ich einfach django-admin und war fertig. Dieses schreckliche Bündel von Formularen nutze ich jetzt seit zehn Jahren, und es erledigt seinen Job. Als es noch keine CLI für TOTP gab, baute ich eine in Python und dumpte die Seeds im Klartext in TOML. Bis ich Verschlüsselung hinzufügte, vergingen fünf Jahre; ein Symlink der Datei in einen Veracrypt-Container war ausreichend und bedeutete wenig Aufwand. Vor zwei Monaten wollte ich einen Timer, bei dem Sport ein Zeitbudget auffüllt und Videospiele es verbrauchen, also baute ich ihn (https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_...). Ich klebte einen von ChatGPT ausgespuckten Tailwind-Klumpen zusammen und steuerte ihn mit HTMX; das reichte. Als ich ihn Freunden zeigte, baten vier um Accounts, und einer fragte nach einem Testzugang für Ärzte in einem Suchtprogramm. Es gab nicht einmal ein Anmeldeformular, also habe ich sie hartcodiert. Ich wünschte, ich könnte meinem jüngeren Ich sagen, es solle aufhören, besessen davon zu sein, Dinge richtig zu machen oder nur an wichtigen Problemen zu arbeiten. Ich habe in meinem ganzen Leben ohnehin nie den Zustand „richtig“ erreicht.
Seit ich den von der IDE vergebenen Namen einfach beibehalte, bis bewiesen ist, dass das Projekt interessant ist, scheint meine Erfolgsquote gestiegen zu sein. Das wirkt wie dasselbe Grundprinzip.
Besonders beim Aufräumen von fremdem Code gibt es eine merkwürdige Logik. Man flucht und denkt: „Was hat sich diese Person bloß gedacht?“, aber gleichzeitig ist da auch die Tatsache, dass sie es überhaupt ins Rollen gebracht hat.
Aber er verdiente 100 Dollar pro Stunde in einem Land mit niedrigen Löhnen. Er kaufte Domains und Content, baute die Software neu, machte Dinge wie Suchmaschinenoptimierung und verkaufte das Ganze nach drei Monaten für das Zehnfache des Kaufpreises. Rund 7000 Dollar Gewinn für drei Monate Arbeit sind nicht schlecht, und wahrscheinlich war es nicht einmal seine Vollzeitbeschäftigung.
Meine Schlussfolgerung war jedoch: Erstens scheitert es ungefähr so oft, wie es gelingt, und man kann nicht vorhersagen, was davon passieren wird; da nachträgliches Reparieren schwieriger ist, als es von Anfang an nicht so zu machen, wirkt es wie eine Wette mit negativem Erwartungswert. Zweitens mag ich persönlich diese Arbeitsweise nicht. Drittens möchte ich deshalb keine Zeit mit Arbeiten verbringen, bei denen diese Methode plausibel passen könnte. Diese Erfahrung hat mich dazu gebracht, nach tieferen, größeren Projekten zu suchen, statt nach einer Folge kleiner, trivialer Aufgaben. Dafür fällt es mir heute viel leichter zu akzeptieren, dass andere Menschen andere Vorlieben haben können als ich. Ich denke weniger über die richtige Art nach, Software zu bauen, und mehr über die Art, die zu mir passt.
Trotzdem funktioniert er. Es ist anstrengend, aber produktiv, und ich lerne dabei viel. Ich weiß, wie man später aufräumt, verfeinert und etwas wartbar und erweiterbar macht; das werde ich tun, sobald tatsächlich etwas Funktionierendes existiert. Besonders wenn man etwas Neues ausprobiert, war dieser Ansatz auch früher schon ziemlich produktiv, daher unterstütze ich ihn voll und ganz.
Apple hat früher einmal meine App abgelehnt, weil sie nutzlos sei. Das App-Review-Team rief mich direkt an und sagte, diese App sei nutzlos und werde nicht für den Mac App Store zugelassen.
Rund 12 Jahre später wurde diese kleine, nutzlose App, KeyboardCleanTool, von Tausenden Menschen genutzt. Es ist eine winzige kostenlose App, die sämtliche Eingaben über Tastatur und Touch Bar blockiert, und die Leute haben sie auf Arten verwendet, die man sich kaum vorstellen würde: etwa um Kleinkinder nach Herzenslust auf der Tastatur herumhämmern zu lassen oder die Katze auf dem Laptop schlafen zu lassen. Was nützlich ist, ist wirklich subjektiv.
Nach ungefähr zehn weiteren Suchanläufen stieß ich in einem Artikel über gute Methoden zur Tastaturreinigung auf die Empfehlung dieser App, weil man damit die Tastatur sperren kann – erst da verstand ich es. Am Ende lud ich sie herunter, und für eine „nutzlose“ App war sie ziemlich nützlich.
Als ich klein war, hat meine Mutter beim Putzen einmal versehentlich unseren Mac IIsi eingeschaltet, und das konnte ich als Argument nutzen, sie davon zu überzeugen, dass wir den After-Dark-Bildschirmschoner brauchten. Kurz darauf flogen Toaster über den Bildschirm. Nostalgie.
Zum Reinigen mussten der MacBook-Bildschirm und die Monitore komplett schwarz sein, damit man Staub sieht, der beim Wischen Kratzer verursachen könnte, und auch das Trackpad musste deaktiviert sein. Die Tastenkombination zum Beenden des Reinigungsmodus musste schwer versehentlich auszulösen und leicht zu merken sein, also habe ich mich dafür entschieden, die Command-Taste mindestens achtmal schnell hintereinander zu drücken. Apples App-Review-Praxis ist einfach immer nervig. Ich verstehe nicht, warum sie stellvertretend für Nutzer entscheiden wollen, was nützlich ist. Ganz zu schweigen von betrügerischen Apps, die es durch den Review schaffen und monatelang im App Store bleiben.
Ich liebe es, ausdrucksstarke und vergnügliche Software zu nutzen. Es geht ums Lernen und Erkunden; das hat mich zum Programmieren gebracht und hält mich dabei.
Leider drängt sich die Notwendigkeit dazwischen. Unter der Drohung des Hungers muss man produktiv sein. Ich sorge mich um die Menschen, mit denen ich produziere, und fühle mich schuldig, wenn ich nicht produziere. Das saugt sogar die Motivation aus der eigenen Freizeit. Es ist erstaunlich, dass es so viele Menschen gibt, die die Stabilität und Freiheit haben, sich auszudrücken. Ich beneide die Leute, die zum Recurse Center gehen können, die zahllosen Blogposts mit vielen persönlichen Projekten und Abenteuergeschichten haben – und freue mich zugleich für sie. Die meisten werden hart gearbeitet haben, um in eine Position zu kommen, in der sie sich so ein Leben schaffen konnten. Ich möchte das auch. Aber um dahin zu kommen, scheint es, als müsste ich noch mehr Leben in Produktivität verbrennen. Wenn man genug Jahre als Opfergabe verbrennt, erlaubt einem das Glück vielleicht das Recht, sein Leben zu genießen. Schon komisch. Danach werde ich nutzlose Software noch mehr genießen.
Früher hatte ich das Gefühl, dass nützliche Software zu bauen das Kennzeichen eines fähigen Softwareentwicklers ist, und ich verbrachte keine Zeit mit Dingen, die nicht auf leicht erklärbare Weise offensichtlich nützlich waren.
Das ist eine sehr gute Methode, Software in lästige Arbeit zu verwandeln. Heute fühle ich mich wohl damit, nutzlose Dinge zu bauen, und es macht Spaß. Ich setze auch vorhandene Ideen auf neue Weise noch einmal um und kümmere mich nicht darum, ob es schon jemand gemacht hat. Wenn es nur zum Spaß ist, kann man es genauso machen wie eine Coverversion eines fremden Songs. Man lernt, hat Freude daran, und das ist an sich wertvoll. Manchmal findet man sogar Wege, etwas zu verbessern. Das habe ich gelernt, als ich anfing, Firmware zu schreiben. Der Druck, immer nützlich sein zu müssen, war zu groß, und ich musste meinen Stolz herunterschlucken und beiseitetreten. Ich stellte fest, dass es unglaublich viel Spaß macht, schlampigen Code zu schreiben, der dumme Dinge tut, und es wurde zu einer großartigen, druckarmen Art, mit Freude zu lernen und Ideen auszuprobieren. Außerdem werden nutzlose Dinge erstaunlich oft nützlich. All die nutzlosen Dinge, die ich in den letzten Jahren gebaut habe, haben zu unerwartet nützlichem Code, Einsichten oder Wissen geführt.
Vor langer Zeit habe ich eine Gruppe namens Houston Recreational Computer Programming Group geleitet. Sie drehte sich fast ausschließlich darum, nutzlose und spaßige Softwareprojekte zu zeigen, und es war sehr unterhaltsam.
Inzwischen bin ich umgezogen, und ich weiß nicht, ob die Stadt, in der ich jetzt lebe, groß genug ist, um so eine Gruppe zu gründen, oder ob ich die Energie hätte, sie noch einmal zu leiten. Was mir persönlich daran gefiel: Einmal im Monat musste ich ein kleines Projekt vorbereiten, das ich zeigen konnte, falls sonst niemand etwas mitbrachte. In etwa zwei Jahren kam das nur ein paar Mal vor, aber eines davon[1] ist ziemlich cool geworden, und ich bin stolz darauf. Ganz nutzlos ist es auch nicht. [1] https://github.com/smcameron/gaseous-giganticus
Ich habe gerade vor ein paar Minuten nutzlose Software fertiggestellt, daher kommt dieser Artikel genau zur richtigen Zeit.
CFR Brackets: https://susam.net/cfr.html
Demo: https://susam.net/cfr.html#3
Source: https://github.com/susam/cfr
Es ist eine winzige Zeichensprache, die nur fünf Befehle unterstützt: C (Farbe ändern), F (vorwärts bewegen), R (drehen), [ (Block starten) und ] (Block wiederholen). Die Befehle sind leicht von der Programmiersprache Logo inspiriert, der Minimalismus von P′′. Anders als diese beiden ist sie jedoch nicht Turing-vollständig. Ein praktischer Nutzen war nicht beabsichtigt; ich habe sie zum Spaß gebaut. Ich werde noch weiter damit herumspielen und versuchen, interessante Formen zu zeichnen, während ich den Eingabecode möglichst klein halte. „Ich glaube, es ist außerordentlich wichtig, den Spaß am Rechnen in der Informatik zu bewahren.“ — Alan J. Perlis