Die Freude daran, Toy-Software zu bauen

• Das Bauen von Toy-Software ist eine Möglichkeit, die eigentliche Freude und Kreativität der Softwareentwicklung wiederzufinden
• In einer Zeit, in der durch AI und Industrialisierung die pure Freude an der Softwareentwicklung schwindet, kann das Entwickeln einfacher Spielzeugprogramme als persönliches Projekt zu praktischem Wissen und tieferem Verständnis führen
• Toy-Software folgt der 80:20-Regel: mit minimalem Code maximale Funktionalität erreichen; entscheidend ist, übermäßiges Design und den Zwang zur Perfektion zu vermeiden
• Die Erfahrung, ohne Abhängigkeit von AI-Tools wie LLM selbst anzuecken und etwas zu bauen, ist selbst die wesentliche Freude an Lernen und Wachstum

---

Warum man mehr Spielzeugprogramme bauen sollte

• Richard Feynmans berühmtes Zitat: „Was ich nicht bauen kann, verstehe ich nicht“ → die Erfahrung, selbst etwas zu erschaffen, führt zu tiefem Verständnis
• Anders als der Rat, man solle das Rad nicht neu erfinden, lehrt die Erfahrung, das Rad selbst zu bauen, oft mehr als Lesen oder theoretisches Lernen
• In letzter Zeit bedrohen AI und die Industrialisierung der Software die Freude und die Handwerkskunst des Entwickelns
• Das Bauen von Toy-Software stellt die einfache Freude wieder her, sich erneut in Computer zu vertiefen

Prinzipien von Spielzeugprogrammen: Keep it simple

• Toy-Software folgt dem 80:20-Prinzip: 80 % der Funktionalität mit 20 % des Aufwands erreichen
• Das Ziel ist nicht das Endprodukt, sondern Einfachheit und das direkte Umsetzen der grundlegenden Prinzipien
• Es wird davor gewarnt, over-engineering zu betreiben; betont wird ein Ansatz, bei dem nur der wirklich nötige Code geschrieben wird
• Empfohlen wird, nicht alle Codepfade von Anfang an zu implementieren, sondern die Implementierung bei Bedarf schrittweise zu erweitern
• Selbst Systeme, die klein wirken, erweisen sich in der Praxis oft als überraschend leicht umsetzbar

Zusätzliche Vorteile von Toy-Software

• Das in Toy-Projekten gewonnene Wissen hilft in der realen Arbeit oft stärker als erwartet beim Nachverfolgen von Problemen, Beheben von Bugs und Vermeiden von Fehlern
• Das direkte Erleben von Randbedingungen und Einschränkungen liefert Einsichten in das Wesen von Software und kann sogar zu innovativen Lösungen führen

Beispiele: Liste verschiedener Toy-Software-Projekte

Hier sind Arten von Toy-Projekten, die in den letzten 15 Jahren selbst umgesetzt wurden, nach Schwierigkeitsgrad und geschätztem Zeitaufwand geordnet. Jedes Projekt enthält eine kurze Beschreibung und zusätzliche Hinweise

• Regex-Engine (Schwierigkeit 4/10, 5 Tage) : POSIX-artige reguläre Ausdrücke interpretieren und passende Strings identifizieren; vermittelt ein tiefes Verständnis der internen Funktionsweise von Regex
• x86-OS-Kernel (Schwierigkeit 7/10, 2 Monate) : enthält CLI, einfache Treiber und Memory Manager; zusätzliche Herausforderungen sind In-Memory-Dateisystem, ELF-Executables, GUI, Prozessisolation usw.
• GameBoy/NES-Emulator (Schwierigkeit 6/10, 3 Wochen) : Verständnis einfacher Befehlssätze und Hardware, Implementierung von PPU, PSG und ungewöhnlichen Cartridge-Formaten
• GameBoy-Advance-Spiel (Schwierigkeit 3/10, 2 Wochen) : einfaches spritebasiertes Spiel, aktive GBA-Entwickler-Community, Systemarchitektur gut allein verständlich
• 2D-Physik-Engine (Schwierigkeit 5/10, 1 Woche) : grundlegende Newton-Mechanik und einfache Kollisionsbehandlung; ausbaubar um komplexe Formen, Trägheit, Lösungsalgorithmen, Soft Bodies und zusammengesetzte Interaktionen
• Dynamischer Interpreter (Schwierigkeit 4/10, 1–2 Wochen) : Tree-Walking-Interpreter; eine eigene Sprache zu bauen bringt technische und kreative Freude
• Compiler der C-Familie (Schwierigkeit 8/10, 3 Monate) : einfaches Typsystem und Zielumgebung, Architektur für verschiedene Optimierungen und Unterstützung mehrerer Backends
• Texteditor (Schwierigkeit 5/10, 2–4 Wochen) : beginnt bei einfachem Datei-I/O, UI-Toolkits wie QT/GTK sind nutzbar, bevorzugt wird oft die Konsole; zusätzliche Features sind Unicode, Syntax-Highlighting, Multi-Buffer, LSP usw.
• Async-Runtime (Schwierigkeit 6/10, 1 Woche) : im Fall von Rust Verarbeitung von impl Future-Tasks und Umsetzung von Concurrency, plus I/O-Waking
• Hash Map (Schwierigkeit 4/10, 3–5 Tage) : interne Funktionsweise, Closed und Open Addressing, Robin-Hood-Regel, Performance und Verständnis dafür, wann sie sinnvoll einsetzbar ist
• Rasteriser / Texture Mapper (Schwierigkeit 6/10, 2 Wochen) : Aufbau der 3D-Grafik-Pipeline lernen; vertiefbar bis zu Vektormathematik, Z-Buffer, Texture Mapping und Shading-Algorithmen
• Signed-Distance-Field-Rendering (Schwierigkeit 5/10, 3 Tage) : mathematische Raumdarstellung, einfache Visualisierung, Verständnis für Shader und Vektormathematik
• Voxel-Engine (Schwierigkeit 5/10, 2 Wochen) : mit Erfahrung in 3D-Grafik oder Spieleentwicklung leicht verständlich; zusätzliche Herausforderungen sind Texturen, prozedurale Generierung, Netzwerk usw.
• Threaded Virtual Machine (Schwierigkeit 6/10, 1 Woche) : schneller Interpreter, optimierte Ausführung ohne architekturspezifische Codegenerierung, mit potenziell compilerähnlicher Performance
• GUI-Toolkit (Schwierigkeit 6/10, 2–3 Wochen) : nach Erfahrung mit grundlegenden UI-Werkzeugen lassen sich Layout-Engine, Text Shaping, Accessibility und weitere vertiefte Funktionen selbst umsetzen
• Simulator für Orbitalmechanik (Schwierigkeit 6/10, 1 Woche) : Newtons Gravitationsmodell einfach implementieren, erweiterbar um Interaktionen mehrerer Himmelskörper, Integrationsalgorithmen, Visualisierung oder sogar NASA-Daten
• Bitwise Challenge (Schwierigkeit 3/10, 2–3 Tage) : ein Spiel, das sich allein mit einem 64-Bit-Zustand reproduzieren lässt; trainiert kreatives Zustandsmanagement, genaue Regeln auf GitHub verfügbar
• ECS-Framework (Schwierigkeit 4/10, 1–2 Wochen) : Entity-Component-System-Struktur selbst implementieren, in das Typsystem der Sprache integrieren, auf hohe Performance und passende Einschränkungen zuschneiden
• CHIP-8-Emulator (Schwierigkeit 3/10, 3–6 Tage) : einfache virtuelle Maschine aus den 1970ern, schnell implementiert, erlaubt das Beobachten und Ausführen verschiedener Fan-Games
• Schach-Engine (Schwierigkeit 5/10, 2–5 Tage) : beginnt bei den Regeln und entwickelt sich schrittweise weiter; von der selbstgebauten Engine geschlagen zu werden, ist ein Moment im Wachstum eines Entwicklers
• POSIX-Shell (Schwierigkeit 4/10, 3–5 Tage) : Prinzipien und Grenzen einer POSIX-basierten Shell, tiefes Verständnis durch Umsetzung echter Shell-Sprachkompatibilität und das Erleben zahlreicher Tricks

Hinweise zum Einsatz von Werkzeugen wie LLM

• Auch moderne Werkzeuge wie LLM sind nützlich, aber wirkliches Lernen wird tiefer, wenn man selbst direkt erkundet
• Statt bestehende Lösungen anzusehen, kann man im Erkunden unbekannten Terrains und im Finden eigener Antworten ein tieferes Gefühl der Erfüllung finden
• Wer Toy-Projekte ohne LLM angeht, findet es anfangs vielleicht ungewohnt und anstrengend, spürt mit der Zeit jedoch eine eigene technische Freude und ein hohes Maß an Erfüllung

• Wer mit dem Auto fährt, erlebt als Läufer kein „Runner’s High“ → tiefe Freude entsteht eher durch direkte Erfahrung statt Abkürzung

[tolluset]

Ich kann das gut nachvollziehen, dass man es einmal ohne LLM versuchen sollte. Wenn keine schnelle Entwicklung nötig ist, macht es wohl mehr Spaß und ist erfüllender, alles Schritt für Schritt selbst zu verstehen und zu bauen.

[nezz1204]

Es ging also um ein Toy-Projekt. Nur anhand des Titels dachte ich, es gehe darum, Software für Spielzeuge zu entwickeln. Haha.

[GN⁺]

Hacker-News-Kommentare

• Ich frage mich, wer LLMs wie eine Suchmaschine verwendet. Früher habe ich bei Google nach Dingen wie „pros cons mysql mongodb“ gesucht und dann offizielle Dokus, Foren, Blogs und sogar Stack Overflow gelesen, was viel Zeit gekostet hat. Die Zeit fürs Lesen und Lernen war aber immer willkommen. Heute gebe ich einem LLM etwas konkretere Prompts wie „Vor- und Nachteile von mysql vs mongodb zum Speichern von Fotos, bitte mit Referenzlinks“ ein. So kann ich die Kernaussagen schnell erfassen, und es ist gut, dass gleich Links dabei sind, sodass man sich nicht auf Halluzinationen verlassen muss. Manchmal stelle ich auch konkrete Anfragen wie „Entwirf ein data schema für das Speichern von Foto-Metadaten in postgres, ich möchte X in eine andere Tabelle auslagern“, aber das nutze ich nur, wenn ich genau weiß, welches Ergebnis herauskommen soll. Eigentlich verwende ich es nur, wenn mir Tipparbeit zu schade ist oder ich kurz die genaue Typbezeichnung vergessen habe (int vs integer usw.)

  • Wenn man ein LLM als Engine für technische Anfragen nutzt, liefert es oft auf den ersten Blick plausible, aber an entscheidenden Stellen falsche Informationen. Wenn man das ungeprüft glaubt und den Antworten folgt, kann man unnötig Stunden oder sogar Tage verlieren. Selbst wenn man Referenzlinks verlangt, ist es etwa fifty-fifty, ob dort tatsächlich die relevanten Informationen stehen oder nur etwas thematisch Unpassendes. Eine Sache kann es aber ganz klar gut: Rückwärtssuche im Stil von "tip-of-my-tongue". Wenn man also ein Konzept beschreibt, schlägt es passende Suchbegriffe vor — und das funktioniert erstaunlich konsistent und zufriedenstellend
  • Schon bald werden Unternehmen vermutlich viel Geld an LLM-Anbieter zahlen, damit ihre Produkte in Vergleichen besser dargestellt werden. LLMs können die Ergebnisse anders framen und gewichten, sodass es 'organisch' wirkt. Sie müssen dazu nur wahre, belegte Informationen zeigen und lediglich den Kontext anders betonen
  • Ich nutze LLMs ebenfalls zum Suchen. Es fühlt sich ein bisschen an wie die frühen 2010er, als Google-Suchen unglaublich mächtig waren. Die Zeit, in der man einfach alles finden konnte. Natürlich hielt diese Phase nicht lange an, und heute ist Googeln im Grunde nur noch Schmerz und Frustration. Ich habe viele Beschwerden über die Veränderungen durch Google und Marketer, aber aktuelle LLMs wirken im Moment sehr effizient darin, Online-Informationen an die Oberfläche zu holen. Auch die Referenzlinks sind meist ziemlich präzise. Wahrscheinlich werden irgendwann wieder dieselben Kräfte einsetzen, also sehe ich das als ein kurzes Zeitfenster, bevor auch das wieder verschwindet
  • Ich gehöre auch zu den Leuten, die LLMs wie Suchmaschinen verwenden. AI IDEs benutze ich noch nicht. Kürzlich wollte ich in einem Live-Tech-Interview antworten, indem ich mit meinem gewählten LLM so etwas wie Googeln betrieben habe, und der Interviewer meinte, ich sei der erste Bewerber, den er so mit AI arbeiten sehe. Ich dachte, die meisten Entwickler würden AI noch eher fürs Suchen als mit AI IDEs verwenden. Sind Fälle wie wir vielleicht doch selten?
  • Ich verwende LLMs sogar in der Entwicklung wie eine Suchmaschine. Zum Beispiel so: „Analysiere das von mir geklonte Repo in /src/foo und erkläre, wie barFeature implementiert wurde. Schau dir jetzt das Projekt /src/baz an und erkläre, warum sich der Ansatz aus foo nur schwer auf baz übertragen lässt.“ Ich lasse mir nichts völlig Neues bauen, sondern übersetze Bestehendes in meine eigenen Ideen und nutze das dann. Wirklich neue und herausfordernde Entwicklung code ich lieber selbst, weil darin der eigentliche Spaß liegt

• Einer der besten Karriereschritte, die ich gemacht habe, war ein persönliches Projekt während einer sechsmonatigen Pause zwischen zwei Jobs. Ich hatte ursprünglich viele Projekte starten wollen, aber weil es keine Beschränkungen gab, wurde der Umfang immer größer, und am Ende wurde oft nichts fertig. Deshalb habe ich beschlossen, pro Projekt nur eine Woche zu investieren. Ich habe also nur so viel gebaut, wie in einer Woche machbar war. Aus dem Nichts heraus in einer Woche in einer neuen Sprache, einem neuen Framework oder einem unbekannten Bereich etwas Brauchbares zu bauen, war ein enormer Confidence-Boost. Es hat mich auch wieder daran erinnert, warum ich Programmieren ursprünglich mochte. Wenn man zwischen zwei Jobs ein paar Monate Zeit hat, wird man wahrscheinlich mehr darüber staunen, wie viel man schon weiß, wenn man einfach Toy-Projekte baut, statt sich auf Silicon-Valley-Interviews vorzubereiten

  • Mit AI-Tools ist man bei solchen persönlichen Toy-Projekten extrem im Vorteil. Ich mache hauptsächlich Backend, kann aber auch Frontend. Nur hat CSS früher so viel Zeit gefressen, dass ich persönliche Projekte oft nicht zu Ende gebracht habe. Jetzt kann ich einer AI einfach sagen: „Mach es hübsch“, und ich bekomme etwas, das zu 85 % fertig ist. Dann bleiben nur noch Bugfixes und kleinere Anpassungen, und ich kann es schnell abschließen. Entwicklung, die sich früher wie Schlamm angefühlt hat, ist dadurch heute viel leichter geworden, und deshalb baue ich häufiger persönliche Projekte
  • In letzter Zeit bin ich eher dazu übergegangen, Bibliotheken, die ich verwende, selbst zu reparieren, wenn sich genug Frust angesammelt hat. Wenn ich unvollständige Onboarding-Dokumentation, kaputte SDLC-Prozesse oder schwere Performance-Probleme entdecke, verbringe ich gern den ganzen Tag mit Fixes. Anders als bei kollaborativen Projekten, bei denen andere warten, verliert man sich bei persönlichen Toy-Projekten leicht in Sidequests und Kleinkram. Bei Zusammenarbeit gibt es immer den Druck, dass jemand auf einen wartet
  • Mich würde interessieren, wie du dir sechs Monate Auszeit leisten und danach den nächsten Job finden konntest. Ich hätte auch gern mal sechs Monate frei, aber ich habe Angst, dass ich danach vielleicht nichts finde und die Pause dann unfreiwillig länger wird
  • Als ich jünger war, habe ich mit classic ASP + SQL Server aufgesetzt, HTML/CSS/JS gemacht und alles leicht deployed. Damals musste man nur Dateien per FTP hochladen. Heute würde ich gern modernere Wege ausprobieren, aber bei persönlichen Projekten verliere ich mich jedes Mal in Deployment- und Entwicklungsprozess-/Lifecycle-Fragen. Mich würde interessieren, wie du Hosting und Deployment für Toy-Projekte auswählst
  • Auch bei mir sind solche persönlichen Projekte durch AI deutlich schneller geworden, weil sie Boilerplate und Test-Automatisierungscode generiert

• Toy-Software zu entwickeln ist wie an Fahrrädern, Autos oder Booten zu schrauben. Es macht Spaß. Aber das Fahrrad für den Arbeitsweg zu reparieren, ist stressig. Es ist schön, Toy-Software zu bauen, aber sobald ich sie irgendwann wirklich nutzen will, finde ich alle Bugs und habe keine Zeit, sie zu beheben — das ist das Dilemma

  • Ich entwickle lieber nur Software für meinen eigenen Gebrauch. Genauso ist es beim Auto befriedigend, es günstig und lange zu fahren
  • Ich habe früher einmal meinen eigenen Mailserver betrieben, heute nicht mehr. Nicht weil ich es nicht könnte, sondern weil ich das inzwischen lieber Profis überlasse
  • Ich habe kürzlich eine eigene Rechnungs-App gebaut. Es hat Spaß gemacht, die benötigten Funktionen eine nach der anderen hinzuzufügen. Sie deckte sogar alles ab, wofür man bei bestehenden Bezahlservices ein Monatsabo braucht. Aber in dem Moment, als ich tatsächlich Rechnungen verschicken musste, wurde mir klar, wie viele offene Themen meine eigene App noch hatte — Styling, Adresseneingabe und so weiter. Am Ende muss man wohl ein Gleichgewicht zwischen dem Spaß am Fahrradfahren und der Praxistauglichkeit des Pendlerfahrrads finden. Mit der Zeit können sich Spaß und Nutzen vielleicht annähern
  • Ich habe auch unglaublich viele Dinge, die ich gern zu „fertiger Software“ machen würde, aber mir fehlen Zeit und Energie. Es gibt außerdem sehr viel langweilige und repetitive Arbeit. Andererseits ist es auch Arbeit, „AI-Ergebnisse“ zu verwalten und auszusortieren. Es ist noch ein frühes Experiment, daher weiß ich nicht, ob ich diese Meinung in ein paar Monaten noch genauso vertreten werde
  • Genau deshalb macht es so viel Spaß, eine eigene Homepage zu bauen. Man kann sie wirklich als persönlichen Spielplatz nutzen

• Ich bin überrascht, wie viele negative Meinungen es zu LLMs gibt. LLMs servieren einem Informationen auf dem Silbertablett. Wenn man ein neues Projekt beginnt, weiß man natürlich nicht von Anfang an alles. Man versucht sein Bestes, scheitert, lernt danach, versteht, warum es nicht funktioniert hat, und passt seinen Ansatz an — genau das ist echtes Lernen. Wenn man schon alles zu wissen glaubt und nur Tutorials nachbaut, erlebt man die Grenzen einzelner Methoden und ihre echten Vor- und Nachteile gar nicht. Wenn man zum Beispiel versucht, mit regulären Ausdrücken einen Parser zu bauen, merkt man selbst, dass rekursive Ausdrücke nicht gehen, und man lernt ganz konkret etwas über komplexere Strukturen oder Probleme der Zeitkomplexität. Wenn man einen optimierenden Compiler selbst implementiert und an allen möglichen Optimierungs-Tricks verzweifelt, versteht man, warum echte Compiler so entworfen sind. Wenn man selbst eine Layout-Engine schreibt, erlebt man sogar die Mühe, schon ein Konzept wie width sauber zu behandeln. Es gibt kaum etwas Wertvolleres als Lernen durch Trial-and-Error. Nur weil LLMs Fehler verhindern können, sollte man nicht auch die wichtigen Lerngelegenheiten verpassen

  • Viele sagen, ohne LLMs falle man zurück, aber ich glaube eher, dass es langfristig ein großer Vorteil sein könnte, sie weniger zu nutzen

• Ich habe selbst über Jahre hinweg an Wochenenden und nachts zahllose seltsame Projekte gemacht, um Computergrafik zu lernen. Kein Cent daran verdient, aber dadurch meinen Traumjob bekommen. Beispielarbeiten:

  • Tiny ray-tracer
  • 2D rigid-body simulator
  • Character animation system
  • Animation curve visualizer
  • Motion capture playback in the web Der eigentliche Zweck all dieser Codeberge war immer nur eines: Wissen zu erwerben

• Ich finde, der hier vermittelte Geist der „Freude am Programmieren“ ist genau das, was wir brauchen. Im Zeitalter von AI-Agent-Coding sogar noch mehr. Allerdings wirken die vom Autor angesetzten Zeiten für Toy-Projekte auf mich deutlich zu kurz. Ich bin zwar vielleicht nicht repräsentativ, aber ich glaube, dass die meisten Dinge auf dieser Liste nicht in ein paar Tagen erledigt sind, wenn man nur jeweils 2–3 Stunden pro Tag arbeitet. Schon die Recherche vor dem Start dauert oft ziemlich lange. Als Beispiel: Ich habe vor Kurzem meinen Pelican-Blog durch meinen eigenen statischen Site-Generator Odin ersetzt, und selbst mit nur 2–3 Stunden pro Tag hat das zwei Wochen gedauert. Dabei war das noch eines der einfacheren Projekte auf der Liste

  • Dein Projekt geht schon über ein „Toy“-Projekt hinaus. Du bist selbst ein echter Kunde und erwartest, dass es nach dem Deployment zuverlässig funktioniert. Genau diese Erwartung ist die Grenze zwischen Toy und echtem Tool. Man kann auch in einer Stunde einen Texteditor bauen — vielleicht einen, der nur Eingaben verarbeitet, extrem simpel ist und nicht einmal einen Beenden-Button hat. Aber als „Toy“-Texteditor reicht das trotzdem
  • Wenn man „X Tage“ als 24*X Stunden interpretiert, wirkt diese Liste plausibler
  • Einer der Vorteile von Toy-Projekten ist, dass sie keine Deadlines haben. Deshalb kann man sie ganz entspannt und langsam angehen. Ich selbst feile seit der Corona-Zeit immer noch an einer PEG-basierten Turing-vollständigen Sprache
  • Wie schnell man damit ist, hängt stark davon ab, wie viele 3rd-party-Bibliotheken man verwendet, was man selbst löst und wie konsequent man sich wirklich nur auf das Kernstück konzentriert. Im GitHub des Autors (https://github.com/ssloy?tab=repositories) kann man viel darüber lernen, wie man den Umfang klein hält. Außerdem versteht der Autor die Problem-Domäne ohnehin schon sehr tief, deshalb kann er so „tight“ coden. Bei einem neuen Thema ist so eine Umsetzung viel schwieriger

• Ich stimme dem Rat „Verwende LLMs nicht für solche Projekte“ grundsätzlich zu, finde aber, man sollte ihn nicht zu extrem auslegen. Es ist interessant, dass sich Ratschläge dazu, wie man Hilfe von AI annehmen sollte, so anders anfühlen als Hilfe von Menschen. Wenn unter dem Blog stünde: „Wenn ihr einen Freund habt, der gut programmieren kann, bittet ihn auf keinen Fall um Hilfe“, wäre das seltsam. Ein erfahrener Freund versteht den Kontext und hilft einem so, dass man selbst auf die Lösung kommt. Kaum jemand bittet AI wirklich darum, „nicht das Problem für mich zu lösen, sondern mich wie ein erfahrener Freund anzuleiten“. Natürlich klappt das heute vielleicht noch nicht oder nur unvollkommen, aber in ein oder zwei Jahren könnte so eine Art der Anleitung ganz selbstverständlich sein. Deshalb wäre es gut, sich anzugewöhnen, klar zu sagen, welche Art von Hilfe man möchte. Man muss nicht mit der fixen Idee herangehen, dass LLMs einem immer nur falsche Antworten geben

  • Ich habe klar das Gefühl, dass AI noch kein erfahrener Entwickler ist
  • Ich nutze LLMs tatsächlich am häufigsten wie einen erfahrenen Freund. Damit das verlässlich funktioniert, muss man den Prompt oder die Frage selbst möglichst unvoreingenommen formulieren. In letzter Zeit scheinen Claude und ChatGPT mir aber zu sehr nach dem Mund zu reden
  • (Autor) Ehrlich gesagt würde ich eigentlich sogar empfehlen, auch erfahrene Freunde nicht um Hilfe zu bitten. Lieber erst dann kurz thematisch passende Literatur lesen, wenn man wirklich feststeckt. Ich glaube sehr stark, dass die Erfahrung, selbst viele Wege auszuprobieren, gegen Wände zu laufen und sich dann durchzubeißen, essenziell für Kreativität und Problemlösefähigkeit ist. Diese Phase der Verwirrung ist notwendig. Aber natürlich muss das jeder selbst entscheiden
  • Ich stelle LLMs tatsächlich Fragen, als wären sie ein Lehrer. Ich bitte sie nicht darum, wie ein Praktikant zu antworten

• Dank Claude-basiertem vibe coding habe ich nach langer Zeit wieder ein unterhaltsames Side-Projekt angefangen. Nachdem ich die Tools und den Prozess gelernt hatte, habe ich in wenigen Wochen schnell verschiedene Apps gebaut: ein Kalender-/Wetter-Dashboard für die Familie, eine Bluesky-Lese-App (blendet bereits gesehene Posts aus), ein gamifiziertes PM-Dashboard für die Firma, eine Chrome-Erweiterung, die Reddit-Posts nach einer bestimmten Zeit ausblendet, und eine Ersatz-App für ein nicht mehr gepflegtes WordPress-Plugin. Anfangs habe ich Claude vieles überlassen, etwa UI-Verbesserungen, aber inzwischen habe ich gelernt, auch mit 90 % Fertigstellung zufrieden zu sein und lieber neue App-Funktionen zu bauen, statt immer weiter zu verfeinern

  • Es irritiert mich, dass Claude nach einem Bugfix manchmal nicht sofort das aktualisierte Ergebnis zeigt. Einmal musste ich sechsmal darum bitten, dass nach einer einzelnen Änderung die neue Ausgabe angezeigt wird. Hat jemand ähnliche Erfahrungen?

• Diese Liste ist wirklich beeindruckend. Viele der Projekte, die dem Autor leicht erscheinen, wären für mich deutlich schwieriger. Trotzdem motiviert mich das stark, meine eigenen Toy-Projekte wieder anzupacken. Bei der Schlussfolgerung zum Lernen mit LLMs sehe ich aber mehr Nuancen. Es hängt komplett davon ab, wie man sie einsetzt. Eine Anfrage wie „Implementiere dieses Problem einfach für mich“ ist fürs Lernen fatal, aber „Erkläre mir die Struktur von ELF auf höchster Abstraktionsebene und konzentriere dich auf das Warum“ kann ein enormer Lernbeschleuniger sein. Dass man nicht mehr jede Recherche selbst macht, kann ein Nachteil sein, aber wenn man wirklich intellektuell ernsthaft an die Sache herangeht, ist es ein riesiger Vorteil, jederzeit sokratische Frage-Antwort-Hilfe bekommen zu können

  • (Autor) Genau das meinte ich im Haupttext mit „einer bestimmten Art des Lernens“. Wenn man zum Beispiel die Struktur von ELF-Binaries lernen will, kann man das nicht allein durch Raten herausfinden. Man muss die Historie und die Entscheidungsprozesse kennen, also Spezifikationen, Dokumentation oder auch LLMs als Referenzmaterial nutzen. Grundsätzlich ist aber „constructive learning“, also das Lernen durchs Selbstbauen, entscheidend. Gerade der stolpernde Prozess, selbst ein Binärformat zu entwerfen, führt dazu, dass man die Gründe und Probleme echter Formate wie ELF und den gesamten Designraum versteht. Für genau dieses entdeckende Lernen würde ich keine LLM-Hilfe empfehlen. „Wenn man mir nur einen Laptop, einen Texteditor und einen Compiler gäbe und mich zehn Jahre damit allein ließe — wie weit könnte ich kommen? Wo bräuchte ich konkrete Informationen, um nicht weiterzukommen?“

• Die hier vorgestellten Projekte sind wirklich gute Ideen, aber mich interessiert keines davon auch nur im Geringsten. In solchen Momenten frage ich mich, ob ich Programmieren jemals wirklich gemocht habe

  • Bei mir ist es genau umgekehrt. Die meisten Projekte auf der Liste fand ich spannend; vieles davon sind Themen, die ich selbst gern ausprobieren würde oder schon ausprobiert habe. Ehrlich gesagt habe ich mir diese Frage bis vor Kurzem auch gestellt. Dann kam mein Baby zur Welt, ich war in Elternzeit und habe ein „einfaches“ Coding-Projekt wirklich nur zum Spaß angefangen. Ich habe beschlossen, alle Abhängigkeiten wegzulassen und alles selbst von Grund auf zu bauen, und dadurch wurde es viel komplexer als gedacht. Aber gerade deshalb habe ich mich plötzlich auf jede einzelne Stunde Coding gefreut. Auf einmal hat Programmieren wieder unglaublich viel Spaß gemacht. Vielleicht bist du einfach ausgebrannt