Die Freude und Kraft des Verstehens

 (binaryigor.com)
3 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Wer Software tiefgehend versteht, wird nicht von Tools getrieben, sondern kann Kontrolle und Ownership über die Systeme ausüben, für die er verantwortlich ist
  • Suche und LLMs liefern schnelle Antworten, aber die Gewohnheit, Lösungen zu kopieren, die man nicht erklären kann, kann die Fähigkeit zur Fehlerbehebung und die Kernkompetenz schwächen
  • Für einmalige Skripte oder interne UIs mit geringem Risiko kann Generieren und Copy-Paste vernünftig sein, aber Code, der lange gewartet werden soll, sollte mit Technologien, die man wirklich beherrscht, erstellt werden
  • Wenn Produktivität nur als Output wie Codezeilen oder Anzahl der PRs gemessen wird, lässt sie sich leicht verzerren; Outcome wie stabile Releases, Vereinfachung, Automatisierung und Tests liegt näher am langfristigen Wert
  • Moderne Software ist komplexer geworden — von Runtime, Netzwerk, Sicherheit und Datenbanken bis hin zu AI —, aber wer die Grundprinzipien lernt, kann neue Tools und Ansätze schneller verstehen

Die Kontrolle und Freude, die Verstehen gibt

  • Tiefes Verständnis ist eine praktische Voraussetzung, um Code und Systeme zu reparieren und zu verändern
  • Was man nicht versteht, lässt sich nur schwer anpassen oder ändern; am Ende schwächt das auch die Kontrolle und Ownership über den Code, für den man Verantwortung trägt
  • Verständnis macht einen nicht nur zum Herr der Tools, sondern gibt auch psychologisch Zufriedenheit
  • Dass Handlungen, die mehr Kontrolle über die eigene Umgebung ermöglichen, mit positiven Gefühlen verbunden sind, ist naheliegend

Menschliche Bequemlichkeit und Abhängigkeit von LLMs

  • Menschen neigen dazu, ihren Energieaufwand zu verringern und den Ertrag im Verhältnis zum Einsatz zu maximieren
  • Diese Bequemlichkeit motiviert dazu, langweilige und teure Arbeit zu automatisieren, kann aber beim Lernen und beim Erwerb von Können zur Schwäche werden
  • Dank Internet und LLMs kann man leicht Antworten auf ähnliche Probleme in der gewünschten Form bekommen, wodurch es leicht wird, den Verstehensprozess zu überspringen
  • Statt SQL selbst zu lernen, kann man dem LLM einfach Tabellen und gewünschte Daten beschreiben und nur das Ergebnis kopieren; kurzfristig ist das einfacher, aber die Fähigkeit, sauber damit umzugehen, wächst dadurch nicht
  • Selbst wenn ein LLM SQL schneller erzeugt, nimmt die früher durch direkte Wiederholung aufgebaute Fähigkeit zum Lesen und Verstehen ab, wenn man sie nicht nutzt
  • Im besten Fall sind LLMs und Suchmaschinen Kompetenzverstärker (force multiplier), aber dafür braucht man zuerst ein starkes Fundament
  • Kerntechniken und Wissen lassen sich nur schwer allein durch Suche, Prompting und manuelle Verifikation erhalten; man muss am Prozess des direkten Aufbaus und Erschaffens beteiligt sein
  • Man sollte sich der eigenen bequemen Natur regelmäßig widersetzen, Dokumentation und Quellcode lesen, die Gründe hinter Lösungen und die Trade-offs von Tools verstehen und Lösungen sowie Algorithmen selbst entwerfen

Balance zwischen kurzfristiger Produktivität und langfristigem Verständnis

  • Man muss nicht jeden Code und jede Lösung vollständig verstehen; je nach Situation kann der Maßstab unterschiedlich sein
  • Einmalige Skripte mit geringer Bedeutung und geringem Risiko darf man ruhig kopieren oder generieren
  • Dasselbe kann auch für interne UIs oder Seiten gelten, die nur von zwei oder drei Personen genutzt werden
  • Code, den man über Monate oder Jahre besitzen, warten und weiterentwickeln wird, sollte in Sprachen und mit Technologien geschrieben werden, die man tiefgehend kennt
    • Man sollte jede Zeile, jedes Wort, jedes Zeichen und jede Konfigurationsoption verstehen können oder sich zumindest in diese Richtung bewegen
    • Wichtiger als jetzt sofort viel Output zu liefern, ist die Optimierung auf langfristiges Verständnis, Wartbarkeit und Produktivität
  • Bei unsicherem Erfolg, etwa bei einem MVP oder einer experimentellen Funktion in einem bestehenden Produkt, kann man die Maßstäbe für Qualität und Verständnis etwas senken
  • Solche Entscheidungen ähneln dem Eingehen von kognitiven Schulden
    • Jetzt kann man sich schneller bewegen
    • Wenn das Produkt oder die Funktion funktioniert oder Änderungen nötig werden, muss man später mehr zurückzahlen
  • Trotzdem sollte man es mindestens so weit verstehen und prüfen, dass man mit Überzeugung sagen kann: „Es funktioniert.“
  • In manchen Fällen kann es vernünftig sein, etwas zu generieren, zu validieren und es danach von Grund auf neu zu schreiben

Der Zinseszinseffekt von Technologie-Stack und Können

  • Für Programmiersprachen, Bibliotheken oder Tools, die man nur gelegentlich nutzt, muss man nicht übermäßig viel Zeit in tiefes Lernen und Können investieren
  • Wenn man das Ergebnis validieren kann, ist es manchmal auch in Ordnung, teilweise verstandene Dinge zu kopieren oder zu generieren
  • Wer aber die Phasen des Lernens und Sich-Durchbeißens überspringt, verringert selbst die Chance, diese Technologie wirklich zu beherrschen und produktiv damit zu arbeiten
  • Im zentralen Technologie-Stack, den man regelmäßig verwendet, kann Meisterschaft hunderte oder tausende Male zurückzahlen
  • Wissen und Fähigkeiten haben einen Zinseszinseffekt
    • Je mehr man weiß, desto schneller kann man selbst etwas bauen
    • Neues Wissen und neue Fähigkeiten lassen sich ebenfalls immer schneller erwerben
    • Mit wachsender Kompetenz kommen auch neue Lösungen und Ideen leichter in den Sinn

Auf Outcome statt auf Output ausgerichtete Produktivität

  • Die Art, Produktivität zu verstehen und zu messen, lässt sich grob in output-zentriert und outcome-zentriert einteilen
  • Output zu messen ist einfach und leicht in Zahlen zu fassen
    • produzierte Codezeilen
    • Anzahl geöffneter und gemergter PRs
    • Anzahl implementierter Features
    • Anzahl gefundener und behobener Bugs
    • Anzahl abgeschlossener Aufgaben
  • Output-zentrierte Kennzahlen lassen sich leicht manipulieren
    • Man kann unnötig wortreichen Code schreiben
    • Man kann viele kleine PRs erzeugen
    • Man kann Arbeit künstlich in kleine Teile zerlegen
    • Man kann nutzlose Features hinzufügen
  • Selbst steigende Zahlen garantieren nicht, dass man sich in die richtige Richtung bewegt
    • Mehr PRs sind nicht automatisch besser
    • Eine wachsende Codebasis ist nicht immer wünschenswert
    • Statt neue Features hinzuzufügen, kann es besser sein, ungenutzte Funktionen zu entfernen
  • Outcome-zentrierte Beispiele sind direkter mit langfristigem Wert verbunden
    • Ein neuer CI/CD-Prozess stabilisiert Releases in Produktion
    • Refactoring und Vereinfachung erleichtern Wartung und spätere Änderungen
    • Eine Neugestaltung der Integrationslösung beschleunigt das Onboarding neuer Partner und spart Rechenressourcen
    • Mehr Tests helfen, Bugs früh zu erkennen und Regressionen zu vermeiden
    • Metriken und Alerts helfen, potenzielle Probleme und Bugs proaktiv zu entdecken
    • Die Automatisierung langweiliger manueller Arbeit spart Zeit und verringert die Wahrscheinlichkeit kritischer Fehler
  • Langfristige Produktivität und Verständnis passen besser zu outcome-zentrierten Metriken; mehr Output ist nicht immer besser

Komplexer werdende Software und Grundprinzipien

  • Das Grundtheorem der Softwaretechnik lässt sich so zusammenfassen: „Jedes Problem der Informatik kann durch eine weitere Indirektionsebene gelöst werden — außer dem Problem zu vieler Indirektionsebenen.“
  • Moderne Softwareentwicklung ist wegen vieler Schichten und Bestandteile sehr komplex
    • Runtime und Plattformen: Browser, Server, Cloud, Mobile, Desktop, Embedded
    • Netzwerk: HTTP, DNS, TLS, TCP, UDP, IP, WebSockets, WebRTC sowie Protokolle von Datenbanken und Message Brokern
    • Sicherheit, Authentifizierung, Autorisierung
    • Betriebssysteme
    • Virtualisierung, Containerisierung, Kubernetes-artige Orchestrierung
    • Datenbanken: SQL, NoSQL, lokal, remote, verteilt
    • Höhere Programmiersprachen und Pipelines aus Compiler, Interpreter und Transpiler
    • Bibliotheken, Frameworks, Package Manager
    • APIs und externe Services
    • CI/CD, TDD, BDD, GitOps, IaC, DDD, EDA, Event Sourcing, CQRS, SSR, CSR, Clean Architecture, Hexagonal Architecture, Modular Monolith, Microservices, Microfrontends
    • LLMs und AI
  • Es gibt aber auch Gründe, warum man mit dieser Komplexität umgehen kann
    • Viele Systeme sind überdesignt und können deutlich vereinfacht werden
    • In einer bestimmten Phase muss man meist nur einen kleinen Teil der Softwarelandschaft wirklich fachlich beherrschen
    • Für den Rest reicht oft ein Überblick
    • Wer die allgemeinen Muster und Prinzipien hinter den Tools lernt, gewinnt einen Hebel für das Lernen neuer Tools, Ansätze und Technologien

Umfang und Wirkung von Grundprinzipien

  • Grundprinzipien sind die grundlegenden und relativ stabilen Regeln, Beschränkungen und Mechanismen, die unter den Tools, Bibliotheken, Frameworks, Protokollen und Bausteinen der Softwareentwicklung liegen
  • Der Kernbereich umfasst mehrere Felder
    • Computerarchitektur und Hardware: CPU-Aufbau, Befehlsausführung, Speicherhierarchie, Register, Cache, Speichergeräte
    • Maschinencode, Assembly und Hochsprachen: warum Assembler, Compiler und Interpreter nötig sind und welche Trade-offs verschiedene Sprachtypen haben
    • Betriebssysteme: Prozesse, Threads, Scheduling, Locks, Synchronisation, virtueller Speicher, Dateisysteme, IPC, System Calls, I/O
    • Algorithmen, Datenstrukturen und Komplexitätsanalyse
    • Netzwerk: Kommunikation zwischen Computern, Zuverlässigkeit, Durchsatz, Latenz, Schichtenmodell
    • Datenbanken und Datensysteme: ACID, Transaktionen, Isolationslevel, Indizes, Speicherverfahren, Relationen, Datenmodellierung
    • Softwaredesign und -architektur: Modularität, Umgang mit Abhängigkeiten und Verantwortlichkeiten, Information Hiding, Kapselung, Schichten, Client-Server, Events, Kopplung und Kohäsion
    • Zustand und Datenfluss: Identität, Single Source of Truth, Konfliktauflösung, Cache und Memoization, Zustandsinvalidierung, Zustandsmaschinen, Konsistenz und Synchronisation
    • Verteilte Systeme: CAP-Theorem, Replikation, Latenz, Partitionen, Konsens, Service Discovery, Eventual Consistency
    • Nebenläufigkeit und Parallelität: Locks, Synchronisation, Parallelisierbarkeit, Race Conditions, Deadlocks
  • Es ist weder nötig noch immer möglich, in allen Bereichen Meisterschaft zu erlangen, aber man sollte anstreben, von jedem Bereich etwas zu verstehen und in einigen ausgewählten besonders stark zu werden
  • Wer sich auf Grundprinzipien konzentriert, entwickelt mit der Zeit die Meta-Fähigkeit einer universellen Intuition
  • Wer tief versteht, wie Computing und Computer allein oder im Cluster funktionieren, wird deutlich weniger von den ständig wechselnden Details neuer Tools und Frameworks hin- und hergetrieben
  • Auf diesem Niveau wird auch das Lernen neu gehypter Tools viel einfacher

Die Freude und Wirksamkeit des Verstehens

  • Wie Leonardo da Vinci sagte: „Die edelste Freude ist die Freude des Verstehens.“
  • In der Softwareentwicklung bringt Verstehen nicht nur Freude, sondern auch praktische Wirksamkeit und Macht
  • Das Feld des Software Engineering ist sehr breit, aber wer sich auf Grundprinzipien konzentriert, erweitert den Bereich, den er beherrschen kann
  • Eine Haltung, die die eigenen kognitiven Grenzen immer weiter verschiebt, führt regelmäßig zu mehr Freude und größerer Wirksamkeit

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Lobste.rs-Kommentare

  • Mir gefiel die allgemeine Tonlage dieses Blogposts sehr.
    In letzter Zeit sehe ich überall viel zu oft Beiträge nach dem Motto „Ich habe ein Tool gebaut, obwohl ich nicht einmal weiß, was intern passiert“, und ich bin diese Haltung leid, als wäre das etwas, worauf man stolz sein sollte.

    • Stimmt. Tiefes Verständnis schafft den wirklichen Vorsprung und führt zu neuen Ideen und Einsichten.
      Außerdem macht schon der Prozess selbst großen Spaß.

  • Es war ein interessanter Beitrag, und ich glaube, dieser Trend, Menschen dazu zu drängen, Ergebnisse zu produzieren, die sie nicht verstehen, ist bis zu einem gewissen Grad beabsichtigt.
    Aus Sicht der AI-Labs gibt es dafür auch klare wirtschaftliche Gründe. Nur wenn Menschen von ihren Produkten abhängig werden, können sie anfangen, ihre Bewertung zu rechtfertigen, und eine Möglichkeit dazu ist, die Fähigkeiten der Nutzer zu schwächen.
    Zufällig habe ich heute einen ähnlichen Text geschrieben, der dieselbe zentrale Prämisse teilt: die Freude daran, etwas wirklich zu lernen und zu meistern: https://hgrsd.nl/blog/simplicity-agency-and-mastery/

    • Danke fürs Teilen. Der Punkt zu Handlungsfähigkeit und dem Schneeballeffekt gefiel mir besonders gut.
      Man darf seine Handlungsfähigkeit niemals aufgeben, und je mehr man weiß und kann, desto mehr wird man wissen und können. Daraus entsteht ein positiver Kreislauf. Wirklich eine schöne und ermutigende Feedback-Schleife.

  • Ich war froh, dass dieser Beitrag nicht mit dem furchterregenden Tag vibecoding versehen war. Eigentlich wird so etwas seit Jahrzehnten in kürzeren und meist grummeligeren Versionen gesagt.
    Software ist erschreckend komplex, daher gibt es viele kognitive Abkürzungen, und ab einem gewissen Punkt sind sie zum Überleben sogar nötig. Aber Menschen neigen dazu, fauler zu werden, als es gut für sie ist, statt dann vorsichtig zu sein, wenn Vorsicht geboten wäre. Computer kommen mit strikter Modularisierung gut klar, Menschen eher nicht.
    Mir gefiel, dass dieser Text Verständnis nicht einfach als „Pflicht“ darstellt, sondern betont, wie spannend es ist zu verstehen, wie etwas funktioniert. Vielleicht gibt es Menschen, die es nicht genießen, die Welt zu verstehen, aber für meine Persönlichkeit ist das so zentral, dass mir die Vorstellung davon fast rein theoretisch vorkommt. Wenn einem diese Freude fehlt, sollte man vielleicht noch einmal darüber nachdenken, bevor man eine Karriere in der Softwareentwicklung beginnt.

    • Dieser Beitrag hat das Tag vibecoding.
      Inzwischen bekommt fast jeder Beitrag vibecoding als Tag, daher wäre es vielleicht sinnvoller, die Idee umzudrehen und ein Tag non-vibecoding einzuführen. Dann würde man nur Beiträge so markieren, die nicht Vibe Coding sind oder die Vorteile von Vibe Coding behandeln, und alles andere bliebe unmarkiert. Leider scheint das der neue Standard zu werden.
      Es ist ein guter Beitrag, der auch emotional mit mir „vibet“.

  • Ich lerne wirklich gern, und der Text behandelt Situationen, in denen man „etwas erzeugt, das man nur teilweise versteht und dann mehr Zeit investieren muss, um es zu begreifen“. Persönlich stört mich diese Art von kognitiver Schuld nicht besonders.
    Wenn es ein Problembereich ist, der mich interessiert, bin ich bereit, die Zeit zu investieren, diese Schuld abzutragen und Verständnis zu gewinnen. Am Ende fühlt es sich einfach wie ein anderer Weg zum selben Verständnis an.
    Es erinnert mich auch an das Lean-Startup-Konzept. Wenn man etwas Sichtbares hat, kann man damit anfangen, etwas Konkretes zu untersuchen, statt auf einen leeren Bildschirm zu starren und zu raten, was wichtig ist. Nicht zu wissen, wo man anfangen soll, ist schlimmer, und AI kann helfen, schnell in Gang zu kommen.
    Was für mich noch nicht ganz geklärt ist, ist die Frage, wie weniger erfahrene Juniors ein Gespür für schlechte Gerüche entwickeln und die Intuition aufbauen, ihnen zu widersprechen. Meine Art, AI zu nutzen, ist sehr iterativ, und ich behandle sie eher wie einen sokratischen Dialog, um Verbesserungen zu erzielen. Das unterscheidet sich stark von der Welt des One-Shot-Vibe-Codings, die mit heutigen Tools möglich ist.

    • Zu dem Punkt „wie weniger erfahrene Juniors ein Gespür für schlechte Gerüche entwickeln und die Intuition aufbauen, ihnen zu widersprechen“: Ich habe enge Freunde und Familienmitglieder, die Ende letzten Jahres gerade erst in die Branche eingestiegen sind.
      Realistisch gesehen ist es meiner Meinung nach nicht sehr viel anders als früher. Erfahrenere Leute werden Hinweise geben und widersprechen, und in den meisten Tech-Unternehmen gibt es auch Peer Review. Juniors sind also nicht völlig auf sich allein gestellt. Im Gegenteil, sie haben genug Zeit, Fehler zu machen und sich anzupassen.

  • Mir gefiel, dass ziemlich viele grundlegende Themen aufgezählt wurden.
    Leser neigen leicht dazu, so etwas als rhetorische Mittel wie Gish gallop oder parading of horribles zu sehen, aber ich denke, in jedem Moment unseres Lebens wirken tatsächlich Dutzende grundlegender Theorien gleichzeitig zusammen.
    Auch Computer werden nicht nach einer einheitlichen großen Theorie programmiert, sondern ähneln eher einem overlapping set-inclusion diagram, in dem viele kleine Theorien miteinander verbunden sind.

  • Ich habe den Beitrag mit großer Freude aufmerksam gelesen und ihn auch mit einigen Freunden geteilt.
    Weil es immer schwieriger wird, langsamer zu machen, habe ich auch https://writing.tidefield.dev/hello-world-again/#honing-my-focus geschrieben, mit dem Vorsatz, mich im neuen Jahr öffentlich dem Lernen der Grundlagen zu widmen.
    Ich freue mich, dass die Richtung dieselbe ist: „Nach 2026 werde ich grundlegende Dinge lernen, die nicht bloß ein schnell vergehender Trend sind …“