- Bei großen technischen Projekten sind alltägliche sichtbare Ergebnisse wichtig, um motiviert zu bleiben und bis zum Ende durchzuhalten
- Ich zerlege das Projekt nicht in große, vage Einheiten, sondern in kleine, sichtbare Schritte, und wähle Methoden, mit denen sich in jeder Phase echter Fortschritt überprüfen lässt
- In der Anfangsphase hilft eine enge Feedback-Schleife mit schnellen Demos sehr dabei, im Flow zu bleiben und sich selbst zu motivieren
- Es ist effektiv, zuerst die Funktionen zu entwickeln, die man selbst braucht, und sie durch tatsächliche Nutzung fortlaufend zu verbessern
- Statt Perfektion steht Fortschritt im Vordergrund; wiederholt kleine Erfolgserlebnisse zu sichern, führt dazu, lange Projekte auch wirklich abzuschließen
Am Ausgangspunkt
- Beim Start eines großen Projekts ist die größte Hürde oft die Entscheidung, wo man überhaupt anfängt
- Wenn man alle Komponenten auf einmal betrachtet, wirkt alles schnell zu vage und man verliert leicht das Interesse
- Wichtig ist, mit kleinen Einheiten zu beginnen, bei denen sich schnell Ergebnisse zeigen
- Jedes Teilprojekt sollte unabhängig sein und ein klares Zeichen der Fertigstellung liefern
- Mit mehr Erfahrung bekommt man ein besseres Gefühl für die ungefähre Form des Projekts und seine Subkomponenten
Frühe Ergebnisse erzeugen
- In der Anfangsarbeit gibt es oft wenig nach außen Sichtbares, sodass Fortschritt schwer erkennbar ist
- Dann ist es wichtig, automatisierte Tests (z. B. Unit-Tests) sinnvoll zu nutzen, um sichtbare Resultate zu bekommen
- Wenn man zum Beispiel einen Terminal-Parser baut, kann man das Parsergebnis für Eingabestrings direkt per Test prüfen
- Schon die wiederholte Erfahrung, dass Tests erfolgreich durchlaufen, vermittelt ein Gefühl von Fortschritt
- Durch diese kleinen Erfolge kann man fortlaufend objektive Belege für den Gesamtfortschritt sammeln
Schnell Demos bauen
- Das anfängliche Ziel ist nicht eine perfekte Subkomponente, sondern eine ausreichende Implementierung für eine Demo
- Komplexität, die langfristig nötig ist (z. B. Datenbanken, fortgeschrittene Datenstrukturen usw.), wird zunächst zurückgestellt; eine einfache Implementierung für schnelles Vorankommen hat Priorität
- „Perfektion kann zum Feind des Fortschritts werden“ bleibt dabei immer im Hinterkopf
- Ziel ist es, ein- oder zweimal pro Woche eine einfache Demo zu erstellen
- Selbst unvollständige Demos lassen sich direkt anschauen und liefern intuitives Feedback, was stark zur Motivation beiträgt
Für mich selbst entwickeln
- Besonders bei persönlichen Projekten ist es wichtig, zuerst die Funktionen umzusetzen, die man selbst braucht, und sie anschließend selbst zu übernehmen und zu nutzen
- Durch die eigene Nutzung spürt man Schwächen unmittelbar, verbessert gezielt die tatsächlich nötigen Funktionen und entwickelt das Projekt aus der Perspektive eines echten Nutzers weiter
- Zu Beginn werden Unbequemlichkeiten oder Bugs sichtbar, aber genau das zeigt klar, was als Nächstes zu tun ist
- Der Stolz, Software zu verwenden, die man selbst geschrieben hat, hilft dabei, das Projekt weiterzuführen
- Anfangs werden unnötige Funktionen (Scrolling, Mausauswahl, Tabs usw.) komplett weggelassen
Wie man das gesamte Projekt verpackt
- Das Gesamtproblem wird in kleine, sichtbare Teilprobleme zerlegt. Bei jedem muss sich ein konkretes Ergebnis überprüfen lassen
- Jedes kleine Problem wird nur bis zu einem für eine Demo ausreichenden Niveau gelöst, danach geht es zum nächsten weiter
- So schnell wie möglich wird eine funktionierende Demo gebaut, anschließend werden Funktionen iterativ ergänzt
- Vorrang haben Funktionen, die für die eigene Nutzung sinnvoll sind
- Bei Bedarf werden die einzelnen Komponenten wiederholt verbessert, und dieser Prozess läuft in Zyklen weiter
Fazit
- Mit diesem Ansatz lassen sich persönliche, Gruppen-, Arbeits- und Studienprojekte auf unterschiedliche Weise aus eigener Motivation heraus bis zum Ende führen
- Der Fokus liegt weniger auf Deployment oder Tooling, sondern darauf, welche Arbeitsweise dauerhaft Motivation aufrechterhalten kann
- Nicht für alle funktioniert dieselbe Methode, aber sichtbare Fortschritte sind die größte Kraft dabei, langfristige Projekte abzuschließen
- Wichtig ist, die eigenen Interessen und die eigene Art der Motivation zu verstehen und darauf abgestimmte Arbeitsprozesse aufzubauen
1 Kommentare
Hacker-News-Kommentare
Ich stimme allem im Artikel zu und würde noch einen Punkt ergänzen: die Bedeutung schneller Feedback-Loops.
Wenn man eine Änderung macht und das Ergebnis sofort sehen kann, ist das unglaublich motivierend.
Wenn man spielerisch am Code herumbastelt und die Auswirkungen beobachtet, verschwinden viele Probleme oder verwandeln sich in etwas, das sich leicht lösen lässt.
Bei riesigen Projekten gab es definitiv eine Korrelation zwischen der Einfachheit von Setup und Ausführung und der Menge an Projektproblemen (Bugs, verpasste Deadlines usw.).
Darin geht es um Feedback-Loops.
YouTube-Link
Ich überlege, für gefundene Bugs e2e-Tests einzusetzen, um sicherzugehen, dass sie wirklich behoben sind.
Wenn man etwas ausprobieren oder reparieren will und schon das Setup selbst Stunden dauert, verliert man die Motivation und schiebt es am Ende auf.
Deshalb mag ich Sprachen mit einem brauchbaren REPL wie Lisp.
Man bekommt sofortige Befriedigung, weil man die Ergebnisse direkt sehen kann.
In dem Moment, in dem man die Motivation verliert, verpufft das Projekt.
Deshalb ist es fast der wichtigste Faktor, die Entwicklung selbst zu einer angenehmen Erfahrung zu machen.
Ich glaube, Erfahrung kann einem dabei sogar im Weg stehen.
Ich habe oft erlebt, dass Senior Engineers tief eintauchen, um etwas Perfektes zu bauen, und wenn sie dann am Ende demoen wollen, ist das Ergebnis eher mäßig.
Die Implementierung mag gut sein, aber die Funktion oder das Produkt selbst ist völlig mittelmäßig.
Manchmal möchte ich einfach das Gehirn ausschalten und hemmungslos schlechten Code schreiben.
Früher habe ich viele Spaßprojekte gemacht und dabei sogar den gesamten Source Code in eine einzige Datei gestopft.
Ich habe mich nicht um Modularisierung gekümmert, aber es hat Spaß gemacht und funktioniert.
Heute ist es dagegen wirklich schwer geworden, auch nur ein Spaßprojekt fertigzustellen.
Ich glaube, das liegt an der Tendenz, nach der ersten Erfahrung alle möglichen unnötigen Zusatzfunktionen einbauen zu wollen.
Zum Beispiel, indem man an Coding-Challenges wie Advent of Code teilnimmt: Die frühen Aufgaben sind einfach, und erst später braucht man Optimierungen oder komplexe Algorithmen.
Oder mit etwas wie pico-8, wo langes Coden unter eingeschränkten Bedingungen gar nicht möglich ist.
Auch ein zeitlich begrenztes Umfeld wie ein Hackathon oder eine Game Jam kann helfen.
Leute mit wenig Erfahrung können die lästigen „Best Practices“ aus älteren Sprachen vergessen und frei experimentieren.
Die DB-Tabellen entwerfe ich selbst, und den Implementierungsteil überlasse ich dem LLM etwas freier.
Besonders eindrucksvoll fand ich, dass das Ziel früher Teilprojekte nicht darin besteht, eine „fertige Subkomponente“ zu bauen, sondern eine Subkomponente, die „gut genug“ ist, um zum nächsten Schritt überzugehen.
Mir ist klar geworden, dass man bei so einer Arbeitsweise irgendetwas „weglassen“ muss.
Andere meinten, sie würden in diesem Modus die Code-Modularisierung ignorieren, aber mir gibt gerade sauber gehaltener Code Zufriedenheit und Motivation.
Also werde ich stattdessen Dinge wie Algorithmen, Datenstrukturen und Performance „weglassen“.
Der Punkt ist letztlich, dass man ganz sicher irgendetwas überspringen muss, aber wenn genau das ein Faktor ist, der einen motiviert, sollte man es nicht weglassen.
Eine Demo bildet eine Zwischenstufe zwischen dem Entwickeln von Software (Programmierung) und ihrer schriftlichen Erklärung (Dokumentation).
Mit Demos kann ich meine Hypothesen darüber, was mein eigenes Projekt leisten soll, immer wieder überprüfen, und sie dienen als eine Art Feedback-Mechanismus.
Demos bleiben bestehen, sodass ich sofort sehen und beheben kann, wenn ich eine Funktion kaputt mache, und diesen iterativen Loop fortsetzen kann.
Ich arbeite bei meiner eigenen in Entwicklung befindlichen Game Engine auf diese Weise.
Beispiel-Demo-GitHub-Link
Ich wünschte, diese Arbeitsweise wäre gesunder Menschenverstand.
Er wirkt auf persönliche Projekte fokussiert.
Mich interessiert eher, wie man große technische Teamprojekte so angeht, dass alle auf ein Ziel hinarbeiten und die Dinge auch wirklich ordentlich zu Ende bringen.
In fast 15 Jahren Berufserfahrung habe ich kein einziges technisches Projekt gesehen, das ohne Budgetüberschreitung, Terminverzug, fehlende Funktionen oder Burnout ablief.
Falls es umgekehrt Beispiele gibt, wie man solche Großprojekte erfolgreich steuert, würde ich mich über weiterführende Links oder Empfehlungen freuen.
Budgetüberschreitungen kommen häufig vor, solange einem nicht wirklich das Geld ausgeht.
Meistens bedeutet das nur, dass sich jemand darüber beschwert, dass die Schätzung falsch war.
Dasselbe gilt für Terminverzug: Solange es keinen wirklich harten Abgabetermin gibt, ist das kein gravierendes Problem.
Eigentlich ist es besser, terminabhängige Ereignisse wie große Marketingkampagnen erst zu planen, wenn das Projekt fast fertig ist.
Auch fehlende Funktionen sind letztlich eine Frage der Erwartungen.
Das eigentliche Problem ist, wenn die Leute völlig ausgebrannt werden und im Burnout enden.
Zumindest das sollte man unbedingt vermeiden.
Ich persönlich habe im Lauf der Zeit immer mehr Sympathie für das Scaled Agile Framework entwickelt.
Ich nutze es als Framework, also als eine Art „Strohmann“, den man je nach Situation anpassen kann.
Dadurch wurde ich dazu angeregt, tiefer in die ursprünglichen Quellen einzutauchen und meine eigenen Schlüsse zu ziehen.
Ich habe gelernt, dass echter Erfolg damit beginnt, klar zu verstehen, warum man etwas baut.
Wenn das Ziel nicht klar ist, kann man weder Prioritäten setzen noch wissen, wo man anfangen soll.
Diese Klarheit hilft viel mehr dabei, zu entscheiden, was man wann bauen sollte, und ermöglicht es manchmal sogar, bewusst zu entscheiden, etwas gar nicht erst zu bauen.
Das Nächste, was wichtig ist, ist Empathie.
Man muss sich wirklich in den Kunden hineinversetzen, seine Probleme vollständig verstehen und eine Lösung anbieten.
Es geht nicht einfach darum, dem Kunden alles zu geben, was er verlangt, sondern seinen zentralen Schmerzpunkt präzise zu verstehen und etwas zu liefern, das echten Wert hat.
Der wahre Grund, warum die meisten Projekte scheitern, ist, dass das Team zu viel Zeit damit verbringt, das Falsche zu bauen.
Wenn man sich konsequent auf das konzentriert, was nötig ist, was Menschen wirklich wollen oder wofür sie zu zahlen bereit sind, würden sehr viel mehr Projekte erfolgreich abgeschlossen werden.
Es gibt wirklich viele Leute, die beim Blick auf ein großes Projekt in Analyse-Paralyse verfallen.
Wirklich schwer ist es, fertig zu werden.
Wenn man Software baut, die man selbst verwenden will, kann man seine eigenen Probleme lösen.
Dadurch, dass ich sie selbst benutze, kann ich auch Bugs in der Software entdecken.
Tatsächlich habe ich beim Bau und Einsatz meines eigenen Webservers mehrere Bugs gefunden.
Eine fokussierte, iterative Entwicklungskultur, die stets auf funktionierende Ergebnisse hinarbeitet.