Schnell handeln und aufgeben

• Beim Wiederherstellen unvollständiger Mac-Spiele aus der Zeit um 1991 zeigte sich wiederholt eine Entwicklungsmethode, bei der Ideen schnell umgesetzt und bei mangelndem Spielspaß oder geringer Aussicht auf Fertigstellung entschlossen verworfen wurden
• Die damalige Liste enthielt 27 Titel, veröffentlicht wurden aber nur 5; der Rest war eher mit schnellen Prototypen vergleichbar, die über rund 18 Monate entstanden
• Dank einer gemeinsamen Shell für spritebasierte Spiele waren neue Experimente kostengünstig, und Funktionen wie Sound, Highscores und Speichern wurden auf später verschoben, sobald sich Potenzial zeigte
• Bei Experimenten wie kite-fighting, K-10 oder Thief of Baghdad wurde anhand von Spielgefühl bei der Steuerung, dem Ziel des Spiels und dem für einen Einzelentwickler bewältigbaren Umfang an Art und Implementierung entschieden, ob weitergemacht wird
• Auch verworfene Projekte waren keine Verschwendung; Code wie der Fisher–Yates-Shuffle, das Umschalten der Bildschirmfarbtiefe, Kollisionserkennung oder trigonometrische Lookup-Tabellen wurde in späteren Projekten wiederverwendet

---

Wiederherstellung alter Mac-Spielprojekte

• Beim Wiederherstellen von Spieldateien, die vor rund 35 Jahren erstellt wurden, von alten Festplatten erwiesen sich die kaum fertig gewordenen Experimentalarbeiten als interessanter als die tatsächlich veröffentlichten Titel
• Frühere Shareware-Spiele wurden als Disk-Images gebündelt und unter Soft Dorothy Software — Early Shareware Projects hochgeladen
  • Diese Disk-Images können per Drag-and-drop in 68K- oder PPC-Mac-Emulatoren wie Basilisk II, Sheepshaver oder MiniVMac verwendet werden
• Quellcode und Build-Werkzeuge rund um Glider 4.0, das 1991 von Casady & Greene veröffentlicht wurde, befinden sich im Disk-Image Casady & Greene Projects
• AirBikes wäre, wenn es fertig geworden wäre, ein futuristisches Rennspiel geworden, blieb tatsächlich aber unvollendet

Von 27 Titeln wurden nur 5 veröffentlicht

• In einem Dokument aus der Zeit um 1991 waren creator code, Name und Status der jeweiligen Spiele aufgeführt
  • Der creator code entsprach in der Macintosh-Zeit vor OS X ungefähr einem sehr groben bundle identifier und musste pro Anwendung eindeutig sein
• Die Liste umfasste 27 Titel, von denen 5 veröffentlicht wurden
  • Der Großteil des Rests waren schnelle Prototypen
  • Diese Projekte entstanden über einen Zeitraum von rund 18 Monaten
  • Zum Zeitpunkt der Listenerstellung wurde offenbar gleichzeitig an drei Titeln gearbeitet
• Auch ein Dienstprogramm namens UnMask wurde veröffentlicht, galt aber wegen seiner Entstehungszeit von etwa zehn Minuten als nicht wirklich relevant für diese Betrachtung

Schnelles Prototyping

• Durch nächtliches tägliches Coden entstanden viele Experimente, und eine gemeinsame Shell für spritebasierte Spiele senkte die Kosten für neue Prototypen
• In neue Spielskizzen floss vor allem Zeit für Sprites und Art in MacPaint; etwas Code war für spezielle Eingabemethoden, Spielmechaniken und Physik nötig
• Funktionen wie Sound, Highscores oder Savegames wurden nicht von Anfang an eingebaut, sondern nur später für Spiele, die es wert waren, weiterverfolgt zu werden
• Entscheidend war, schnell zu prüfen, ob eine Idee tatsächlich Spaß macht
  • Eine auf Papier gut klingende Idee kann sich deutlich von echtem Spielspaß unterscheiden
  • Schon wenn Steuerung und Physik in wenigen Tagen umgesetzt waren, ließ sich beurteilen, ob sich weiteres Arbeiten lohnte

Kriterien, um Spaß schnell zu prüfen

• Ein kite-fighting-Spiel ließ sich in wenigen Tagen mit Flugsteuerung und Physik umsetzen und testen
  • Wenn allein das Steuern eines Drachens schon zu schwierig ist, wird das Spiel vermutlich nur wenige begeistern
  • Wenn bereits das Drachensteigen ohne Kampfelemente Spaß macht, ist Potenzial vorhanden
• Im Arcade-Spiel Joust machte bereits das reine Herumfliegen mit dem flap-Button Spaß, noch bevor Gegner auftauchten
  • Sowohl langsames Flattern als auch hektisches Knopfdrücken für schnellen Aufstieg prägten das Spielgefühl
• Auch ein Spiel mit Papierflugzeugen in einem chaotischen Haus, in dem Aufwinde aus Bodenschächten genutzt werden, machte schon eine Weile Spaß, bevor überhaupt klar war, dass man Räume durchqueren und Dingen wie Toast ausweichen sollte
• K-10 war ein weiteres Rennspiel, benannt nach dem Kansas Highway 10, kam aber nie über die Prototypenphase hinaus

Die Entscheidung: einstellen oder weitermachen

• Einige Spiele waren zwar in frühen Fassungen umgesetzt, aber es war unklar, was danach eigentlich passieren sollte
  • In der Liste stand bei manchen Spielen nüchtern <no point>
• Beim Plattformspiel Thief of Baghdad machte das Herumspringen auf einem fliegenden Teppich Spaß, doch das eigentliche Ziel des Spiels blieb unklar
• Als Einzelentwickler war es schwer, selbst vielversprechende Projekte weiterzuführen, wenn die Fertigstellung mehr als ein Jahr gedauert hätte
  • Ein spritebasiertes adventure im Stil von Dungeons and Dragons war attraktiv, aber der Arbeitsaufwand für Waffenanimationen des Spielers, Monster, Zaubereffekte und ein Kampfsystem war enorm
  • Sobald etwa Stoßen und Parieren mit dem Schwert umgesetzt sind, wächst der Art-Aufwand weiter durch Varianten wie Streitkolben, Bogen oder Umhang

Wieder hervorholen und Code wiederverwenden

• Zurückgestellte Spiele sind keine wirklich toten Projekte; wenn sich Quellcode, Ressourcen und Projektdateien finden lassen, können sie wieder aufgenommen werden
• Thief of Baghdad wurde rund 18 Monate später in einer Farbversion neu begonnen, erhielt den Namen Scheherazade und bekam allmählich auch ein klareres Ziel
  • Auch beim zweiten Versuch entstand am Ende nicht genug schwer erklärbarer Reiz, sodass das Projekt erneut eingestellt wurde
• Code aus zurückgestellten Projekten konnte in späteren Arbeiten wiederverwendet werden
  • Fisher–Yates shuffle algorithm
  • Code zum Ändern der Monitor-Farbtiefe auf frühen Macs
  • polygon-point-Kollisionscode
  • sine-Lookup-Tabellen für schnelle Trigonometrie
  • Routinen für dot product und cross product
• Solche Prototyping-Arbeiten wurden nicht als Verschwendung betrachtet

Iteratives Arbeiten auch bei Apple

• Im Verlauf der 1990er schien die Zeit der unabhängigen Mac-Spieleentwickler zu Ende zu gehen; als das Angebot kam, nach Kalifornien zu gehen und bei Apple zu arbeiten, wurde es angenommen
• Nach dem Einstieg bei Apple wurde es so verstanden, dass in der Freizeit keine Nicht-Apple-Projekte bearbeitet werden durften
  • Genau genommen war für Coding außerhalb der Arbeit eine schriftliche Genehmigung des Vorgesetzten nötig
  • Da Apple nicht im Spielegeschäft tätig war, wäre eine Genehmigung womöglich möglich gewesen, doch das Risiko einer Ablehnung wirkte abschreckend
• Auch in Arbeitsprojekten außerhalb von Spielen wurde die Methode des schnellen Prototypings beibehalten
  • Andere Kollegen iterierten ihre Entwürfe auf dem Whiteboard und planten sorgfältig, bevor sie Code schrieben
  • Bevorzugt wurde dagegen ein Ansatz, bei dem man sofort einstieg, kompilierte und iterativ weiterarbeitete
• Immer wieder wurde schnell Code zusammengesetzt, um Engpässe früh zu finden, und bei Bedarf ein Projekt fast von Grund auf neu begonnen
  • Selbst wenn ein Projekt zwei- oder dreimal neu gestartet wurde, war oft ungefähr zu dem Zeitpunkt ein ausreichend guter Stand erreicht, an dem vorsichtiger planende Kollegen ihren Code überhaupt erstmals zum Laufen brachten
• Die letzte Code-Revision bestand meist aus Vereinfachung; der Code wurde von Anfang an so behandelt, dass große Änderungen jederzeit möglich waren, wodurch sich auch ein Gefühl dafür entwickelte, wie er organisiert werden sollte
• Es gab auch die Erfahrung, einem Kollegen, der einen Bloom Filter empfahl, antworten zu können, dass er bereits verworfen worden war, weil die realen Datenmengen zu klein für nennenswerte Performance-Vorteile waren und nur die Komplexität der Codebasis erhöht hätten

Always Be Iterating

• Gegen Ende der Karriere entstand das Gefühl, bei Apple ein beitragender Mitarbeiter und Kollege gewesen zu sein
• Anders als in den Nächten des einsamen Codens waren die Ingenieure, mit denen zusammengearbeitet wurde, der beste Teil der Zeit bei Apple
  • Unter ihnen waren auch Programmierer, die um Größenordnungen besser waren
• Das eigene Gefühl war, zu den schnellsten Programmierern zu gehören, eher der Typ Mensch, der für eine Demo im Wochenmeeting gleich zwei Prototyp-Versionen bauen konnte
• Der Satz, der den Töchtern immer wieder gesagt wurde, lautete A.B.I.
  • „Always“
  • „Be“
  • „Iterating“
  • also „Always Be Iterating“
• Die Projekte, Quelltexte und Werkzeuge der nie veröffentlichten Spiele wurden als Disk-Images geordnet und auf GitHub veröffentlicht
  • Soft Dorothy Software: Unfinished Tales (Vol. 1)
  • Soft Dorothy Software: Unfinished Tales (Vol. 2)
• Auch Volume 3 ist geplant, aber da jedes Projekt erst in einen „release“-fähigen Zustand gebracht werden muss, gibt es keinen zugesagten Veröffentlichungstermin

[GN⁺]

Meinungen auf Hacker News

• Seit ich etwa 1989 mit dem Programmieren angefangen habe, habe ich mindestens ein gutes Dutzend, vielleicht sogar an die hundert Projekte liegen lassen, die meisten davon Spiele. Die meisten waren für den Mac Plus oder den Mac LC gedacht, und viele hatten ähnliche Mechaniken oder Art Styles wie die im Artikel erwähnten
  Die wenigen Projekte, die ich veröffentlicht habe oder an denen ich beteiligt war, fühlen sich an wie ein Schatten meiner selbst. Mit meinem Lebenslauf und meiner Karriere ist es genauso. Wie Fingerabdrücke eines ganzen Wesens, das das Traumleben lebte, das nie Wirklichkeit wurde, weil es früh keine Chance gab, Erfolge aufzubauen. Deshalb glaube ich, dass ein Grundeinkommen das menschliche Potenzial um das 10- oder 100-Fache steigern könnte: weg von der Dienstleistungsökonomie, hin zu Handlungsfähigkeit und Selbstverwirklichung, sodass jeder ein Resteinkommen aufbauen kann. Und Pararena habe ich wirklich sehr viel gespielt

  • Ich sehe das anders, und dazu gekommen bin ich, weil während der Pandemie um mich und meine Freunde herum so etwas wie eine grundeinkommensähnliche Situation entstand. Menschen, die nicht mehr arbeiten mussten, wurden ziemlich schnell depressiv, verglichen mit denen, die weiterarbeiteten, und das hat meine Sicht auf ein Grundeinkommen verändert
    In deinem Umfeld war es vielleicht anders, oder dein Land hat so einen Ansatz vielleicht nicht verfolgt. Ich frage mich, worin der Unterschied liegt zwischen der Arbeit an vielen Spielen und der Konzentration darauf, eines fertigzustellen. Würde ein Grundeinkommen genug abgeschlossene Projekte hervorbringen, und zwar nicht nur kurzfristig, sondern dauerhaft solche Dinge ermöglichen? In manchen Lebensphasen, etwa wenn man Eltern wird oder in der Kindheit, ergibt ein Grundeinkommen Sinn, aber in einer Phase der Selbstfindung halte ich Verantwortung für hilfreich
  • Ein Grundeinkommen wird nicht funktionieren. In unserem Land ist es fast schon umgesetzt. Man kann 600 Euro im Monat und diverse Sozialleistungen bekommen, ohne zu arbeiten, und das Ergebnis sind das höchste öffentliche Defizit in der EU, Steuersätze auf Weltniveau, weitverbreitete Kriminalität, Schwierigkeiten, wegen dieser Steuern mit Arbeit Geld zu verdienen, und eine massive Abwanderung gebildeter Menschen ins Ausland
  • Wenn schon der Mindestlohn nicht gut funktioniert hat, weiß ich nicht, welche Kennzahlen einen glauben lassen sollen, dass ein ähnliches System funktioniert, bei dem Menschen fürs Nichtarbeiten Geld bekommen
    Diese Denkweise ist wirklich schwer nachzuvollziehen. Ein magisches Grundeinkommen wäre im Grunde der Mindestlohn für die nicht arbeitende Masse; wie soll das nachhaltig oder gut sein?
  • Wir leben unterschiedliche Leben. Ich war nur an Projekten beteiligt, bei denen man das Produkt besser weggeworfen hätte. Es waren keine Spiele, aber so war der Zustand, in dem sie veröffentlicht wurden
    Theoretisch hätte es die Option gegeben, sie ordentlich fertigzustellen, aber wenn man das versucht hätte, wäre die Organisation pleitegegangen, also war es eben nur eine theoretische Option. Wenn ich mir den Zustand der Software ansehe, die ich beruflich nutze und privat notgedrungen auch, scheint es, als würden alle um mich herum so ein Leben führen. Zum Glück haben die Nutzer keine Wahl, sie müssen den Mist kaufen oder gar nichts kaufen. Wir können sicher Mist verkaufen
  • Unfertige Dinge nennt man einfach Forschung. Ich habe mehrere Unreal-Engine-4/5-Projekte und werde sie nie fertigstellen, aber unter Aspekten wie dem Testen von Spielmechaniken, Rigging und Animation, Shader-Entwicklung und dem Erstellen von 3D-Assets war es interessant

• Viele Firmen, bei denen ich gearbeitet habe, funktionieren genau so. Ingenieure bauen ein glänzendes neues Feature, es wird veröffentlicht, alle sind glücklich. Ein paar Monate später stapeln sich die Bugs
  Die ursprünglichen Entwickler sind längst in einem anderen Team. Offiziell heißt das „Silos aufbrechen“, in Wirklichkeit ist es eher „alle austauschbar machen“. Die Ingenieure, die das Projekt übernehmen, müssen es warten und Bugs beheben, bis wieder ein anderes Team übernimmt. Furchtbar

  • Das ist die Hölle, die wir uns selbst geschaffen haben, indem das Minimum Viable Product weithin als richtige Art der Produktentwicklung akzeptiert wurde. Wir beurteilen die Umsetzbarkeit anhand einer Feature-Liste, nicht danach, ob der dumme Kram solide oder wartbar ist
    Außerdem ist „minimal funktionsfähig“ nur einen Schritt von „nicht funktionsfähig“ entfernt. Jedes Projekt wird zu Ikarus und testet, wie nah es an die Sonne fliegen kann, bevor die Flügel schmelzen
  • Ich mache oft den Witz, dass jede Stellenausschreibung eines Startups nach Series A im Grunde nach Viscera Cleanup Detail[1] klingt, um hinter den „Helden“ aus der Phase vor dem Product-Market Fit aufzuräumen
    [1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...
  • Ich war der ursprüngliche Autor eines Features, das das Unternehmen definierte, und nachdem mir gesagt wurde, man müsse „Silos aufbrechen“, wurde ich herausgenommen und habe dann jahrelang zugesehen, wie meine Arbeit kaputtging. Stimme also völlig zu
    Die Leute, die es übernahmen, waren nicht qualifiziert genug, Entscheidungen zu treffen, meine größere Vision wurde verdrängt, und es war schwer zu ertragen, die Inkompetenz bei der Verwaltung dieses Features mitanzusehen. Bis heute ärgere ich mich jedes Mal, wenn wieder ein dummer Bug auftaucht. Besonders, weil ich davor gewarnt hatte, als noch genug Zeit gewesen wäre, gegenzusteuern. Trotzdem habe ich eine wichtige Lektion gelernt, und beim nächsten Mal kann ich sicher sagen: Auch wenn ich wie ein sturköpfiger Mensch wirke, werde ich nicht zurückweichen, sondern kämpfen
  • Das stimmt völlig, aber ich glaube nicht, dass das der Punkt ist, auf den der ursprüngliche Artikel hinauswill, oder die Absicht des Textes. Der Artikel empfiehlt eher, viele Dinge auszuprobieren, ein Gefühl dafür zu bekommen, ob sie technisch möglich sind und für Kunden interessant wirken, und sie dann voranzutreiben
    Das passt gut für Indie-Entwickler und lässt sich bis zu einem gewissen Grad auch auf große Unternehmen übertragen. Diese Philosophie eignet sich gut, um Features oder Produkte zu identifizieren, in die sich sinnvoll Zeit investieren lässt. Man könnte die von dir beschriebene Situation sogar als direkte Folge davon sehen, dass man dem im Original vorgeschlagenen Ansatz nicht gefolgt ist
  • Was du beschreibst, scheint nicht viel mit diesem Artikel zu tun zu haben

• Ich beschäftige mich derzeit wieder mit Retro-Entwicklung. Ich schreibe Software für den 68K-Macintosh, auf dem ich ursprünglich Programmieren gelernt habe.
  Ich habe viele alte Bücher, Beiträge aus comp.sys.mac.programmer und Quellcode wie Soft Dorothy und GliderPro durchforstet. Alten Code mit frischem Blick zu sehen, ist eine seltsame Erfahrung. Man erkennt auch Gründe dafür, warum alte Macs so oft abgestürzt sind, die über die einfache Erklärung „es gab keinen Speicherschutz“ hinausgehen. Wie der Autor sagt, mag ich auch 1-Bit-Art, und ich pflege eine Liste von Twitter-Accounts, die 1-Bit-Art posten. Wenn jemand fehlt, sagt mir gern Bescheid: https://twitter.com/i/lists/1578111923324944397
  Das Gute am Programmieren für eingeschränkte Systeme ist, dass sie die Optionen begrenzen. Es ist eine willkommene Pause von der modernen Erfahrung, in der man mit der passenden Library praktisch alles umsetzen kann. Manchmal stelle ich mir eine Welt vor, in der die Rechenleistung eingefroren ist und Software für gut verstandene Systeme einfach immer besser wird. Alte Systeme wie der Mac 68K waren von der Geschwindigkeit der Hardwareentwicklung geradezu schwindelerregend betroffen. Wenn neue Prozessoren wie der 68020 oder 80386 erschienen, hatte man höchstens ein paar Jahre Zeit, etwas zu bauen, das ihr Potenzial wirklich nutzte. War man zu spät, musste man schon mit neuer Software für die nächste Hardwaregeneration konkurrieren.

  • Wenn ich meinen Code mit über 30 Jahren Abstand wieder ansehe, möchte ich ihn refaktorieren und typische Kleinarbeiten wie das Reagieren auf Fenster-Events vereinfachen.
    Ich würde auch gern Wrapper-Funktionen für den Umgang mit Handles und Ähnlichem schreiben. Trotzdem ist es, wie gesagt, erstaunlich, wie einfach die Toolbox im Vergleich zu modernen Betriebssystemen war. Wieder Retro-Entwicklung zu machen, fühlt sich wirklich spannend an.
  • Ich mache 1-Bit-Art für die eingeschränkte Plattform Playdate. Sie ist nicht ganz so eingeschränkt wie ein Macintosh Plus. Auf Twitter bin ich @gingerbeardman, und Beispiele gibt es hier: https://blog.gingerbeardman.com/2024/07/14/shibuya-pixel-art...
  • Wegen der geditherten Bilder auf 68k-Macs mag ich 1-Bit-Art. Einige Fotos, die ich als Computer-Wallpaper habe, habe ich ebenfalls gedithert.

• Der ganze Blog ist großartig. Es gibt dort viel Interessantes zum Stöbern.
  Es ist in Ordnung, etwas wegzuwerfen; auch aus aufgegebenen Projekten kann man lernen und Teile davon wiederverwenden. Der Durchbruch für mich kam, als ich beschloss, etwas so klein zu machen, dass ich es fertigstellen konnte. Das half mir, die Fähigkeit des Fertigstellens zu entwickeln, und das ist eine eigene Fähigkeit, die schwer zu lernen ist. Denn sie tritt erst am Ende eines sehr langen und mühsamen Prozesses auf, und so weit kommt man fast nie. Alle meine Freunde, die Videospiele entwickeln, fangen damit an, zuerst ihre eigene Engine zu schreiben, und sind ausgebrannt, sobald sie beim Level-Editor ankommen. Man lernt dabei viel über Tooling, was ironischerweise dem ähnelt, was man ohnehin schon konnte, aber das eigentliche Spiel entsteht nicht. Es ist, als würde man Steinmetzkunst lernen, indem man eine Kathedrale baut; man wird das Ende nicht sehen. Man sollte so klein anfangen, dass man nicht scheitern kann, und sich dann zu immer größeren Projekten hocharbeiten.

  • „Alle meine Freunde, die Videospiele entwickeln, fangen damit an, zuerst ihre eigene Engine zu schreiben“ habe ich selbst ein paar Mal erlebt. Selbst wenn man sich entscheidet, vorhandene Tools zu nutzen, kann man leicht in endlos tiefe Tümpel der Komplexität geraten.
    Ich arbeite gerade an einem Unity-Projekt und hatte Mühe damit, herauszufinden, wie man am besten ein Gebäudesystem im RTS-Stil baut. Statt wie sonst direkt hineinzuspringen, habe ich beschlossen, das Spielkonzept so zu ändern, dass Spieler gar keine Gebäude platzieren müssen. Beim Experimentieren stellte sich heraus, dass das für das, was ich bauen wollte, sogar die bessere User Experience war. Anfangs habe ich es mir noch damit schöngeredet, „in der nächsten Iteration das Gebäudesystem hinzuzufügen“, aber inzwischen werde ich das wahrscheinlich nicht tun.
    Weglassen ist fast immer besser. Einen kleinen Ausgangspunkt wirklich fertigzustellen, ist wie Nitromethan für die nächste Iteration. Erst wenn man 100 % erreicht, wird die nächste Runde deutlich besser. Wenn man bei 80 % stehen bleibt, bleibt nur das Gefühl, den Felsbrocken wieder den Hügel hinaufschieben zu müssen.
  • Ich glaube, ich habe noch kein einziges persönliches Projekt fertiggestellt. Zumindest für mich ist das die am schwersten zu entwickelnde Fähigkeit.
  • Mich darauf zu konzentrieren, persönliche Projekte so weit zu reduzieren, dass ich sie tatsächlich fertigstellen kann, könnte genau das sein, was ich gerade brauche.
  • Ich bin vor Kurzem von der Frontend-Entwicklung in Richtung Accessibility gewechselt. Vor ein paar Jahren habe ich mehrere statische Sites, Templates und Designprojekte gebaut, sie aber aus verschiedenen Gründen schließlich liegen lassen.
    Nachdem ich in Accessibility gearbeitet habe, habe ich viele davon wieder hervorgeholt und barrierefrei neu umgesetzt. Einige nutzten sehr alte Bootstrap-Versionen, also habe ich sie dabei auch auf aktuelles Bootstrap aktualisiert. Allein durch das barrierefreie Überarbeiten alter Designs habe ich wirklich viel gelernt. Ich habe das Gefühl, eine deutlich bessere Perspektive darauf bekommen zu haben, worauf man bei der Bewertung von Websites und Anwendungen achten sollte. Es hat mir auch gezeigt, wie wenig barrierefrei die Dinge waren, die ich selbst gebaut hatte.
  • Die Fähigkeit, Angefangenes fertigzustellen, scheint in Produktivitätsdiskussionen zu fehlen. Ich frage mich, ob es Blogposts oder Artikel gibt, die das ausführlicher erklären.

• Johns Spiele waren für mich als Kind, als ich auf dem Mac erstmals Programmieren lernte, eine Inspiration. Ich habe viel Glider gespielt und noch mehr Pararena. Dieses hallende Start-Sample sitzt mir immer noch im Kopf.
  Wahrscheinlich habe ich noch viel mehr Zeit damit verbracht, mit ResEdit in den Resource Forks dieser Spiele herumzustöbern. Ich habe nicht viel fertigbekommen, aber ein paar kleine Shareware-Spiele habe ich abgeschlossen und bei AOL hochgeladen. Ein paar Monate später war ich wirklich überrascht, als ein Scheck aus dem fernen Kalifornien in meinem Briefkasten lag.
  Die frühe Mac-Ära war wirklich eine besondere Zeit, und es fühlte sich so an, als könnten einzelne Entwickler mit genug Kreativität und Zeit etwas bauen und in die Welt bringen. Danke, dass du diesen Text geschrieben und mich auf eine Reise in die Erinnerungen geschickt hast; ich hoffe, du genießt den Ruhestand.

  • Vielleicht hast du meine anderen Texte oder das README meines Disk-Image-Archivs gelesen. Diese Zeit war besonders.
    War sie besonders, weil für uns als frühe Computernutzer und frühe Entwickler alles neu war? Oder lag damals etwas anderes in der Luft? Es freut mich, dass dir meine kleinen Spiele gefallen haben. Ich frage mich, ob dieser Scheck aus Kalifornien vielleicht der Anstoß war, der dich in deine heutige Karriere – was auch immer sie ist – gelenkt hat.

• Wenn das Ziel dieses Textes ist, das Wegwerfen von Projekten zu normalisieren, bin ich mir nicht sicher, ob das eine gute Idee ist. Alles andere beiseite: Es kann eine enorme Zeitverschwendung sein, und allein mit „man hat ja trotzdem etwas gelernt“ lässt sich das nicht rechtfertigen. Sollte man nicht auch beim Fertigstellen lernen?

  • In einer hervorragenden Episode von Smarter Every Day arbeitet Destin mit einer Glaswerkstatt daran, einen zerbrochenen Prinz-Ruprecht-Tropfen in einen Resin-Block einzuschließen.
    Da das noch niemand gemacht hatte, finden sie den Weg während der Arbeit heraus und machen dabei ziemlich viele Fehler. Einer der Punkte, die das Video betont: Wenn so etwas passiert, hält das Team nicht einfach an und versucht dasselbe noch einmal. Sie machen weiter, ruinieren es vollständig und nutzen es als Gelegenheit, nach Herzenslust mit dem Material zu experimentieren.
    Er spricht ausführlich darüber, wie großartig das ist. Wenn man auf dem Weg zu einem fertigen, polierten Produkt ist, kann man solche Versuche nicht frei machen; hier nutzt man also eine unvergleichliche Gelegenheit, mehr über das Verhalten des Materials zu lernen. Etwas, das ohnehin schon Müll ist, noch weiter kaputtzumachen, ist schwer — deshalb ist es auch fraglich, ob man überhaupt noch ein Risiko eingeht.
    Ich halte die Beobachtung für richtig, dass eine Denkweise, die Lernen und Experimentieren höher bewertet als bloßen Erfolg, einer der besten Wege ist, in dem, was man tut, wirklich hervorragend zu werden.
  • Er hat tatsächlich auch Dinge fertiggestellt. Der Kern ist, Analyseparalyse zu vermeiden und statt endlos weiter nachzudenken „einfach erst mal zu machen“. Das ist ein Bias zur Handlung und zugleich eine Ablehnung von Sunk Costs.
  • Das ist eine Fehllektüre des Textes. Es geht eher um Entdeckung durch schnelles iteratives Prototyping, einschließlich des schnellen frühen Auffindens fataler Schwächen.
  • Ich finde den Titel nicht besonders gut. Die Lehre ist eher: „Arbeite an allem, was dir einfällt, aber veröffentliche nichts, bevor es bereit ist. Manche Projekte werden vielleicht nie bereit sein, und das ist okay. In 30 Jahren kannst du sie aus Nostalgie auf GitHub stellen.“
    ChatGPT fasst es zusammen als: „Baue schnell und veröffentliche niemals. Bis du veröffentlichst.“
  • Ich halte es für gesund, dass Projekte sterben. Es schafft Zeit, andere Projekte zu beginnen, statt festzustecken.
    Manchmal hält man an einem Projekt fest, das nirgendwohin führt, und denkt, wenn man sich nur genug anstrengt, wird es schon irgendwohin gehen — aber es macht keinen Spaß mehr und man lernt auch nichts Neues. Man treibt sich selbst mit dem Gedanken „Ich muss es fertigstellen, ich muss es fertigstellen“ an, und wenn man dann fragt „Warum?“, liegt es meistens an der Angst, etwas nicht fertigzubekommen, oder vielleicht an der Angst, nicht zwischen einer schwierigen Phase und der Phase eines gescheiterten Projekts unterscheiden zu können. Wie auch immer: Ich habe viel zu oft Erleichterung gespürt, wenn etwas gescheitert ist. Es wird zur Chance, neu anzufangen.

• Einige der Pixel-Art-Bilder in den Screenshots sind wirklich großartig.

• Persönlich habe ich viel mehr gelernt und verdient, indem ich kleine Dinge veröffentlicht und sie dann iteriert oder verworfen habe.

• Mir gefällt dieser Ansatz und ich finde ihn interessant, aber auf Organisationsebene wirkt er schwieriger. Viele Dinge, die wir über Projekte und Technologien herausfinden, betreffen die Machbarkeit in der Größenordnung, in der das echte Projekt läuft, und zeigen sich in kleinen Experimenten nicht unbedingt.
  Manchmal ist es auch kein technisches Problem, sondern eher eine Frage wie: „Können wir den meisten Entwicklern hier verständlich machen, auf diese Weise zu arbeiten?“ Das heißt nicht, dass man solche Versuche nicht öfter machen sollte. Es gibt Dinge, die man lernen kann, indem man kleine Projekte ausprobiert. Nur garantiert das nicht, dass es auch in großem Maßstab funktioniert.

• Mein Problem ist einfach die Zeit. Wenn ich von der Arbeit nach Hause komme, ist das Letzte, worauf ich Lust habe, mich vor den Computer zu setzen.
  Auch die zwei freien Tage pro Woche muss ich mit Hausarbeit füllen, also will ich immer noch nicht vor einem Bildschirm sitzen.

  • Ich bin Junior und suche gerade ein Praktikum und danach eine Stelle.
    Ich beneide Leute, die das so machen können wie du. Die Branche fühlt sich im Moment wie ein Kult an, der nur Menschen sucht, die Technik und Programmieren zu ihrem ganzen Leben machen. Es ist nicht so, dass ich die Anforderungen an sich hasse; ich habe Arbeitsethos und will gut sein, aber die Erwartungen wirken höher denn je.
    Ich hoffe darauf, irgendwann genug Jobsicherheit zu haben, um Hobbys zu haben, bei denen ich nicht auf einen Bildschirm starren muss. Ich möchte demnächst Metallbearbeitung ausprobieren.