[{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/","section":"","summary":"","title":"","type":"page"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/berufsethik/","section":"Tags","summary":"","title":"Berufsethik","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/clean-code/","section":"Tags","summary":"","title":"Clean Code","type":"tags"},{"content":" Was sind technische Schulden # In meinem vorherigen Artikel zum Thema Technische Schulden gehe detailliert darauf ein, was technische Schulden sind, wie sie entstehen, wie man sie erkennt und wie man sie verhindern bzw. verantwortungsvoll damit umgehen kann.\nEinstieg - Das Erbe der anderen # Der erste Tag mit einer neuen Codebase ist immer ein bisschen wie das Auspacken einer Erbschaft. Man weiß nicht genau, was einen erwartet, doch man hofft auf sauberen Code und gute Dokumentation. Doch was man manchmal vorfindet ist das genaue Gegenteil.\nNun zu einem realen Vorfall, wie ich ihn in meiner Zeit als Freiberuflicher Entwickler erlebt habe.\nDie erste Aufgabe klang simpel: einen bestehenden Bug fixen.\nNachdem ich etwa vier Stunden gebraucht hatte, um das Projekt zu finden, denn es lag nicht auf dem firmeninternen Gitlab Server, sondern auf dem Rechner des ehemaligen Kollegen, öffnete ich die Datei, die ich für \u0026ldquo;zuständig\u0026rdquo; hielt.\nWas ich vorfand waren dreitausend Zeilen Code, kein Kommentar, keine Struktur, die diesen Namen verdient hätte.\nStattdessen Methoden, die sich über Hunderte von Zeilen erstreckten und alles auf einmal taten: Datenbankzugriffe, Businesslogik, UI-Rendering, irgendwo dazwischen ein paar Magic Numbers, die niemand mehr erklären konnte.\nDer eigentliche Bug war schnell behoben, doch ihn zu lokalisieren hat zwei Tage gedauert.\nNachlässigkeit war der ausschlaggebende Punkt und nicht technische Komplexität. Wegen einer Haltung, die ich später in diesem Projekt immer wieder antreffen würde: Versionierung? Beiwerk. Formatierung? Beiwerk. Dokumentation? Beiwerk.\nWas dabei übersehen wurde? Meine Zeit ist kein Beiwerk.\nTechnische Schulden neu definiert # Der Begriff stammt von Ward Cunningham, einem der Mitautoren des Agilen Manifests. Er prägte ihn in den frühen 1990ern und meinte damit ursprünglich etwas Pragmatisches: Manchmal ist es sinnvoll, eine nicht-optimale Lösung zu wählen, um schnell voranzukommen. So wie man einen Kredit aufnimmt, um heute investieren zu können und den man morgen zurückzahlt.\nDer entscheidende Teil dieses Bildes wird heute gerne vergessen:\nSchulden müssen zurückgezahlt werden. Mit Zinsen.\nWer einen Kredit aufnimmt und ihn ignoriert, hat in erster Linie ein Charakterproblem und erst dann entsteht auch ein Finanzproblem.\nDasselbe gilt für Code. Technische Schulden, die bewusst aufgenommen und dokumentiert werden, um später getilgt zu werden, sind ein legitimes Werkzeug und manchmal sogar unverzichtbar.\nTechnische Schulden, die aus Bequemlichkeit entstehen, still wachsen und still weitergereicht werden, sind etwas ganz anderes.\nUnd sie wachsen immer, das ist das Heimtückische an ihnen.\nJede neue Funktion, die auf einem schlechten Fundament aufbaut, macht das Fundament instabiler. Jede Abkürzung, die heute genommen wird, verengt den Korridor für morgen. Was als kleine Unordnung beginnt, wird zum Monolith, den niemand mehr anfassen will – weil niemand mehr versteht, was passiert, wenn man es tut. Der Zinseszins schlägt zu: Die Schulden wachsen nicht linear. Sie wachsen exponentiell.\nAber es gibt noch eine Dimension, die in dieser Finanzbuchhaltung fehlt. In der realen Welt zahlt derjenige die Zinsen, der den Kredit aufgenommen hat. Bei technischen Schulden zahlen oft andere: der Kollege, der den Code drei Jahre später debuggt. Die Entwicklerin, die eine neue Funktion einbauen soll und erst mal Wochen damit verbringt zu verstehen, was überhaupt da ist. Das Unternehmen, das Kunden verliert, weil ein System unter seiner eigenen Last zusammenbricht.\nTechnische Schulden sind keine abstrakte Metrik in einem Qualitätsbericht. Sie sind konkrete Lebenszeit – die von anderen Menschen. Zeit, die sie nicht wiederbekommen.\nDie drei Verantwortlichkeiten # Die, die nach dir kommen # Stell dir vor, du ziehst in eine neue Wohnung. Der Vormieter hat die Wände mit Löchern übersät, Kabel lose verlegt, einen Wasserschaden hinter dem Schrank versteckt und beim Auszug einfach zugemacht. Du weißt nicht, was hinter den Wänden steckt, bis es tropft.\nGenau so fühlt es sich manchmal an, fremden Code zu erben.\nDas Schlimmste daran ist nicht die Arbeit, es ist die Erkenntnis, dass jemand das gewusst hat. Dass jemand diese Entscheidungen getroffen, diese Abkürzungen genommen, diese Verwahrlosung hinterlassen hat – und dann gegangen ist. Ohne ein Wort, ohne einen Kommentar, ohne den Mut, sich zu seinem eigenen Code zu bekennen.\nHinter jedem chaotischen Repository steckt ein Mensch, der einen anderen Menschen um dessen Zeit gebracht hat. Nicht mit Absicht, vielleicht. Aber Fahrlässigkeit ist keine Entschuldigung – sie ist eine Entscheidung, die man nicht bewusst getroffen hat.\nDer Kollege, der heute deinen Murks debuggt, hat Familie, Hobbys, und allgemein Dinge, die er lieber täte, als in dreitausend Zeilen ungekennzeichnetem Code nach einer Race Condition zu suchen, die du vor drei Jahren eingebaut hast, weil du keine Zeit hattest, es richtig zu machen. Diese Stunden bekommt er nicht wieder zurück, die Energie, die er in das Verstehen steckt, was eigentlich da ist, fehlt ihm für das, was sein sollte: neue Dinge bauen, Probleme lösen, wachsen, Innovation vorantreiben.\nSchlechter Code ist oft kein technisches Problem, sondern allzu häufig eine Geringschätzung der Zeit anderer.\nDie, die deine Software benutzen # Der Nutzer sieht keinen Code. Er sieht ein Formular, das sich nicht abschicken lässt. Eine App, die abstürzt. Daten, die verloren gehen. Eine Fehlermeldung, die er nicht versteht und die niemand vorgesehen hat zu erklären.\nWas er nicht sieht: dass sein Ärger, sein Datenverlust, seine Frustration die direkte Konsequenz einer Entscheidung ist, die jemand in einem Büro getroffen hat – still, unsichtbar, für ihn folgenlos. Sicherheitslücken entstehen nicht aus dem Nichts. Sie entstehen, wenn jemand entscheidet, dass Validierung heute keine Priorität hat. Datenverlust passiert nicht einfach. Er wird vorbereitet – durch Systeme, die niemand mehr versteht, und die deshalb niemand mehr zuverlässig warten kann.\nDer Nutzer zahlt die Rechnung, ohne es zu wissen und ohne gefragt worden zu sein.\nDas Unternehmen # Hier wird es nüchterner – aber nicht weniger ernst.\nTechnische Schulden sind ein wirtschaftliches Risiko, das in den meisten Roadmaps nicht auftaucht. Jede neue Funktion, die auf maroden Fundamenten gebaut wird, kostet mehr als geplant – weil ein Teil des Aufwands immer darin besteht, das Bestehende nicht zum Einsturz zu bringen. Wartung wird teurer. Onboarding neuer Entwickler dauert länger. Experimente, die Wettbewerber in zwei Wochen umsetzen, dauern sechs Monate – weil das System keinen Spielraum mehr hat.\nUnternehmen, die Qualität systematisch als verzichtbar behandeln, kaufen sich kurzfristig Geschwindigkeit und bezahlen sie langfristig mit Handlungsunfähigkeit.\nDas unbequeme Geständnis # Es wäre einfach, hier aufzuhören und zu behaupten:\nWer schlechten Code schreibt, ist ein schlechter Mensch. Fertig.\nGanz so leicht ist es aber nicht immer, denn die Wahrheit ist oft kompliziert und unbequem.\nTechnische Schulden entstehen nicht immer aus Faulheit oder Gleichgültigkeit, manchmal entstehen sie aus echtem Druck. Zum Beispiel aus Deadlines, die nicht verhandelbar waren, aus Ressourcen, die nicht vorhanden waren oder aus dem Wissen, dass eine unvollkommene Lösung, die heute läuft, besser ist als eine perfekte, die in drei Monaten fertig wird, dann aber vielleicht zu spät kommt.\nPerfekter Code ist eine Illusion. Wer das Gegenteil behauptet, hat entweder noch nie unter echtem Druck gearbeitet oder lügt.\nDer entscheidende Unterschied liegt nicht darin, ob Schulden entstehen oder nicht, er liegt darin, wie sie entstehen und mit ihnen umgegangen wird.\nEs gibt technische Schulden, die man bewusst aufnimmt. Man bespricht es im Team, dokumentiert die Entscheidung, hält fest, warum diese Abkürzung heute sinnvoll ist und was es braucht, sie später zu tilgen. Das ist kein Versagen – das ist Pragmatismus mit Verantwortungsbewusstsein. Ein Kredit, den man kennt und plant zurückzuzahlen.\nUnd dann gibt es die andere Art. Die stillen Schulden. Die, die entstehen, weil jemand gehofft hat, dass es schon niemand merken wird. Die, die nicht dokumentiert werden, weil Dokumentation ja \u0026ldquo;Beiwerk\u0026rdquo; ist. Die, die still in den nächsten Sprint wandern, und den übernächsten, bis sie so tief im System vergraben sind, dass niemand mehr weiß, was sie eigentlich sind – nur noch, dass man sie besser nicht anfasst.\nDer Unterschied zwischen diesen beiden Arten ist ein moralischer, kein technischer.\nWir nehmen diese Schuld auf, weil wir jetzt liefern müssen – und wir werden sie tilgen ist eine Aussage, die Respekt verdient.\nWird schon niemand merken ist keine Entscheidung. Es ist eine Kapitulation.\nManagement und die Kultur der Eile # Es gibt eine bequeme Ausrede, die sich in Entwicklerkreisen hartnäckig hält: Das Management ist schuld. Die Roadmap lässt keinen Raum für Refactoring, die Deadlines sind unrealistisch oder der Druck kommt von oben und wir unten sind die Leidtragenden.\nWie an fast jeder Geschichte ist auch an dieser etwas Wahres dran.\nOrganisationen, die Qualität systematisch als verzichtbar behandeln, schaffen Strukturen, in denen technische Schulden keine Ausnahme sind, sondern der Standard. Wenn Geschwindigkeit das einzige Maß für Erfolg ist, wenn jedes Sprint-Review nur nach abgeschlossenen Tickets fragt und nie nach dem Zustand des Fundaments, dann sendet das eine klare Botschaft: Nur Geschwindigkeit zählt, alles andere ist egal. So eine Kultur schafft langfristig kein festes Fundament für Fortschritt.\nAber diese Geschichte hat einen gefährlichen blinden Fleck: Sie macht Entwickler zu passiven Opfern, doch das sind sie nicht, zumindest nicht zwangsläufig.\nDie unbequeme Wahrheit ist, wer schweigt, macht mit.\nWenn schlechte Entscheidungen nicht benannt werden, wachsen sie ungestört weiter. Wenn technische Schulden in keinem Meeting auftauchen, weil niemand sie auf die Agenda setzt, existieren sie für das Management schlicht nicht. Wenn Entwickler unter sich bleiben mit dem Wissen, dass ein System marode ist und dieses Wissen nie nach oben tragen, dann tragen sie Mitverantwortung für das, was daraus wird.\nDas Management kann keine informierten Entscheidungen über Dinge treffen, von denen es nichts weiß. Das ist keine Entschuldigung für schlechte Führung, aber es ist eine Erklärung dafür, warum Schweigen keine neutrale Haltung ist.\nDie Kultur der Eile entsteht selten durch eine einzige Entscheidung, oft entsteht sie durch hundert kleine Momente, in denen jemand gedacht hat: Ich sage es nächstes Mal. Das ist nicht mein Kampf. Es wird schon gutgehen. Und jedes Mal, wenn jemand so denkt, geht ein kleines Bisschen Information verloren.\nDie Stimme erheben – Verantwortung annehmen # Verantwortung ist nichts Abstraktes, es zeigt sich in sehr konkreten Dingen.\nCode-Reviews sind eine der wenigen Stellen im Entwicklungsprozess, an denen Qualität kollektiv verhandelt wird. Wer ein Review durchklickt, weil er keine Zeit hat oder keinen Konflikt will, verzichtet auf diese Chance. Wer ehrliches Feedback gibt – konstruktiv, respektvoll, aber klar – investiert in das Fundament, auf dem alle weiterarbeiten müssen. Das zeigt, dass Code-Reviews nicht als reiner Formalismus behandelt werden dürfen.\nSchulden sichtbar machen ist keine Schwäche oder unnötiges nörgeln, sondern Professionalität. Ein Arzt, der einen Befund verschweigt, um den Patienten nicht zu beunruhigen, handelt nicht fürsorglich, sondern fahrlässig. Dasselbe gilt für Entwickler, die wissen, dass ein System instabil ist und dieses Wissen für sich behalten. Technische Schulden gehören dokumentiert, benannt, in Backlogs aufgenommen, aber definitv nicht versteckt.\nEntwickler müssen auch lernen \u0026ldquo;Nein\u0026rdquo; zu sagen. Das ist nicht bequem aber sehr wichtig. Nicht immer ist ein Nein möglich und nicht jeden Kampf kann man gewinnen, aber wer nie Nein sagt, wer jedem Druck wortlos nachgibt und jede unrealistische Deadline kommentarlos akzeptiert, der hat aufgehört, Verantwortung zu tragen.\nUnd besonders an alle, die gerade am Anfang stehen: Ihr lernt gerade nicht nur Programmieren. Ihr lernt, wie ihr arbeiten wollt, welche Standards ihr setzt, welche Kompromisse ihr eingeht und welche nicht. Ihr habt die Chance, Gewohnheiten zu entwickeln, die euch und alle, die nach euch kommen, prägen werden.\nAlso erhebt eure Stimme, wenn ihr Mängel erkennt und steht zu euren Entscheidungen, auch wenn es mal unbequem wird.\nDer Weckruf (Schluss) # Jede Zeile Code, die du schreibst, ist eine Entscheidung.\nEs ist sowohl eine technische, als auch eine moralische.\nDu entscheidest, wie viel dir die Zeit derjenigen wert ist, die nach dir kommen.\nDu entscheidest, ob du ein Fundament baust oder eine Falle.\nDu entscheidest, ob du Verantwortung trägst oder weiterschiebst.\nDas klingt abstrakt und schwer, aber tatsächlich kann man mit kleinen Entscheidungen viel Bewirken.\nHinterlässt du eine Methode mit zweihundert Zeilen, obwohl du weißt, dass sie zu lang ist und sagst, du hattest keine Zeit?\nLässt du einen Kommentar weg, weil er dir gerade trivial erscheint und vergisst, dass er für jemand anderen alles bedeuten könnte?\nBegräbst du eine technische Schuld still, anstatt sie zu benennen, weil es so bequemer ist?\nWenn du diese oder ähnliche Fragen klar mit Nein beantworten kannst, bist nicht Teil des Problems, sondern Teil der Lösung.\nNimm dir zehn Minuten Zeit, um etwas zu erklären, das du gerade verstanden hast, sag im Review, was du wirklich denkst, steh in einem Meeting auf und sag: Das geht so nicht, ich schlage vor wir machen das so\u0026hellip;\nDu weißt jetzt, was technische Schulden sind, wer sie bezahlt, wie sie entstehen und warum Schweigen keine neutrale Haltung ist. Du weißt, dass perfekter Code eine Illusion ist, aber bewusste, dokumentierte, ehrliche Arbeit keine.\nWas du nun daraus machst, liegt ganz bei dir.\nUnd denk immer daran: Irgendwo sitzt gerade jemand an deinem Code und fragt sich, wer das hinterlassen hat und warum.\nAlso schreibe deinen Code so, dass du guten Gewissens und mit Stolz sagen kannst: Das habe ich programmiert.\nZum Schluss möchte ich noch John Woods zitieren, der es etwas provokanter Ausdrückt, jedoch das gleiche meint:\nAlways code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.\nJohn Woods\nVorschaubild # freepik\n","date":"14 April 2026","externalUrl":null,"permalink":"/posts/tech-debt-ethics/","section":"Posts","summary":"Technische Schulden sind mehr als eine Metrik. Sie sind gestohlene Lebenszeit von Kollegen, Nutzern und Nachfolgern. Eine unbequeme Auseinandersetzung mit Verantwortung in der Softwareentwicklung.","title":"Die moralische Dimension technischer Schulden","type":"posts"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/categories/philosophie/","section":"Categories","summary":"","title":"Philosophie","type":"categories"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/categories/praxis/","section":"Categories","summary":"","title":"Praxis","type":"categories"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/refactoring/","section":"Tags","summary":"","title":"Refactoring","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/categories/softwareentwicklung/","section":"Categories","summary":"","title":"Softwareentwicklung","type":"categories"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/softwarequalit%C3%A4t/","section":"Tags","summary":"","title":"Softwarequalität","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/teamkultur/","section":"Tags","summary":"","title":"Teamkultur","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/technische-schulden/","section":"Tags","summary":"","title":"Technische Schulden","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/authors/tristan/","section":"Authors","summary":"","title":"Tristan","type":"authors"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/verantwortung/","section":"Tags","summary":"","title":"Verantwortung","type":"tags"},{"content":"","date":"31 März 2026","externalUrl":null,"permalink":"/tags/agile/","section":"Tags","summary":"","title":"Agile","type":"tags"},{"content":"","date":"31 März 2026","externalUrl":null,"permalink":"/tags/code-reviews/","section":"Tags","summary":"","title":"Code Reviews","type":"tags"},{"content":"","date":"31 März 2026","externalUrl":null,"permalink":"/tags/dokumentation/","section":"Tags","summary":"","title":"Dokumentation","type":"tags"},{"content":" Einleitung # Jeder Entwickler kennt die Situation: Die Deadline rückt näher, der Chef sitzt einem im Nacken, der Kunde nörgelt, weil er auf sein Feature warten muss und die schöne, saubere Lösung würde zu lange dauern. Die scheinbar logische Konsequenz: Man macht es schnell und unsauber (engl. quick and dirty). Im \u0026ldquo;besten\u0026rdquo; Fall hinterlässt man noch einen TODO-Kommentar und verschiebt das saubere Lösen auf einen anderen Tag.\nDas ist der Moment, wo technische Schulden entstehen und sie entstehen in nahezu jedem Projekt. Das perfide an ihnen, sie sind oft stille Begleiter, sie wachsen im Hintergrund, bis sie zu einem realen Problem werden.\nIm folgenden Artikel möchte ich untersuchen, wie genau sie entstehen, woran man sie erkennt und vielleicht am wichtigsten, wie man sie kontrolliert.\nWas sind technische Schulden # Der Begriff wurde von Ward Cunningham geprägt, einem der Mitautoren des Agilen Manifests. Die Analogie, die er gewählt hat, ist bis heute treffend: Technische Schulden funktionieren wie ein Kredit. Technische Schulden sind die Kosten, die entstehen, wenn ein Entwickler eine schnelle Lösung einer sauberen vorzieht.\nWer heute einen Kredit aufnimmt, bekommt sofort Geld, zahlt jedoch morgen mehr zurück, da Zinsen oben drauf kommen. Genauso liefert man mit einer unsauberen Lösung heute schnell ein Feature, erkauft sich damit aber zukünftigen Mehraufwand. Code wird schwerer verständlich, Änderungen riskanter oder fast unmöglich und neue Features dauern länger, weil man sich erst ganz vorsichtig durch alten, fragilen Code kämpfen muss. Das ist im Falle der technischen Schulden das Equivalent zu den Zinsen bei einem Kredit.\nWas man hier allerdings nicht vergessen darf: Technische Schulden sind nicht automatisch ein Fehler, denn manchmal ist es eine bewusste, rationale Entscheidung – quasi ein Kompromiss, den man eingeht, weil der Markt nicht wartet oder die Produktion still steht.\nEs wird erst zum Problem, wenn die Schulden nicht oder zu spät zurückgezahlt werden.\nWie werden sie verursacht # Im Folgenden möchte ich einige der häufigsten Ursachen für technische Schulden beschreiben. Ich erhebe kein Anspruch auf Vollständigkeit, aber es sind die aus meiner Sicht wichtigsten und gefährlichsten.\nZeitlicher Druck # Jeder Entwickler kennt das: Chef, Kunde oder externe Deadlines zwingen dazu, Abstriche bei der Codequalität zu machen. Features müssen halbfertig veröffentlicht werden, Dokumentation wird gestrichen und Tests – um die kümmert man sich später. Zeitlicher Druck ist wohl die häufigste Ursache für technische Schulden und gleichzeitig die am schwersten zu vermeidende.\nMangel an Bewusstsein für die Konsequenzen # Manchmal entstehen technische Schulden schlicht, weil sich niemand bewusst ist, welche Langzeitfolgen eine schnelle Entscheidung haben kann. Ein Entwickler löst ein Problem pragmatisch, ohne zu ahnen, dass genau diese Stelle in sechs Monaten das Herzstück eines neuen Features sein wird. Fehlende Erfahrung oder mangelndes Systemverständnis spielen hier oft eine Rolle.\nMangel an Tests # Ohne automatisierte Tests weiß niemand mit Sicherheit, ob eine Änderung am Code woanders etwas kaputt macht. Daraus ergibt sich, dass Entwickler sich nicht mehr trauen, alten Code anzufassen und er wird zur Blackbox. Technische Schulden, die durch fehlende Tests entstehen, sind sehr tückisch, weil sie kaum sichtbar sind, bis es zu spät ist.\nMangelhafte oder fehlende Dokumentation # Ein Sprichwort in der Softwareentwicklung besagt: Code wird viel öfter gelesen als geschrieben. Wenn niemand dokumentiert, warum eine Entscheidung so getroffen wurde, verliert sich dieses Wissen unweigerlich – spätestens wenn der ursprüngliche Entwickler das Team verlässt. Was übrig bleibt, ist Code, den niemand mehr richtig versteht und den niemand bearbeiten will.\nSchlechte Kommunikation # Silodenken, unklare Anforderungen, zu seltene Abstimmungen oder das klassische \u0026ldquo;das hatte ich mir anders vorgestellt\u0026rdquo; sind im Arbeitsalltag fast nicht zu vermeiden. Wenn Entwickler, Designer und Product Manager nicht klar miteinander kommunizieren, entstehen Missverständnisse. Doppelt implementierte Funktionen, inkonsistente Architekturentscheidungen oder Features, die an den eigentlichen Anforderungen vorbeigehen, sind typische Folgen.\nVerzögertes Refactoring # Refactoring ist wie Küche putzen nach dem Kochen oder Aufräumen nach einer Party: Man schiebt es vor sich her, weil es anstrengend ist und \u0026ldquo;ja auch noch später gemacht werden kann\u0026rdquo;. Doch je länger man wartet, desto verwurzelter wird schlechter Code im System und desto aufwändiger wird es, ihn zu bereinigen. Was heute vielleicht nur eine Stunde dauern würde, dauert in einem Jahr eventuell eine Woche.\nNicht Einhaltung von Entwicklungsrichtlinien # In den meisten Teams gibt es Coding Standards, Architekturprinzipien oder Konventionen – manchmal ungeschrieben, manchmal explizit dokumentiert. Werden diese ignoriert oder umgangen, entsteht inkonsistenter Code, der schwer zu lesen und zu warten ist. Besonders kritisch wird es, wenn neue Teammitglieder diese Abkürzungen als Standard übernehmen.\nDas Fehlen von Entwicklungsrichtlinien # Ohne klare Entwicklungsrichtlinien entwickelt jeder Entwickler seinen eigenen Stil und das Ergebnis ist inkonsistenter Code, der schwer zu lesen und definitiv noch schwerer zu warten ist. Coding Standards, Architekturprinzipien und Konventionen sind essentiell, da sie dafür sorgen, dass sich jeder im Team im Code zurechtfindet und nicht nur derjenige, der ihn geschrieben hat.\nBesonders kritisch wird es, wenn Teammitglieder diesen inkonsistenten Zustand als Normal ansehen, in ihren Alltag übernehmen und weiterführen. Es braucht Richtlinien als Korrektiv, sonst häufen sich technische Schulden still und in großer Menge an.\nUnwissenheit # Nicht jede technische Schuld entsteht durch Faulheit oder Zeitdruck. Manchmal weiß ein Entwickler einfach nicht, dass es eine bessere Lösung gibt. Ob nun wegen fehlender Erfahrung, mangelnder Weiterbildung oder weil sich die Technologie weiterentwickelt hat, während der Code stehen blieb - es ist menschlich und doch eine mögliche Ursache für technische Schulden.\nWie erkennt man sie # Technische Schulden sind heimtückisch, sie schleichen sich still und heimlich ein. Oft merkt man erst, dass sie überhaupt da sind, wenn sie bereits zum echten Problem geworden sind. Es gibt allerdings einige sehr typische Warnsignale, auf die man achten sollte.\nSteigende Entwicklungsgeschwindigkeit\u0026hellip; nach unten # Neue Features, die früher in zwei Tagen fertig waren, brauchen plötzlich eine Woche. Das liegt nicht am schlechter werden des Teams, sondern an den Altlasten, die sie mit sich tragen. Wird das Team spürbar langsamer, ohne dass die Komplexität der Anforderungen gestiegen ist, ist das ein typisches Zeichen.\nAngst vor Änderungen # \u0026ldquo;Fass das bloß nicht an, dann geht irgendwas kaputt\u0026rdquo;, \u0026ldquo;Hier musst du besonders vorsichtig sein, niemand weiß so genau, warum der Code überhaupt funktioniert\u0026rdquo;. Diese Sätze sind deutliche Warnsignale. Wenn Entwickler bestimmte Teile des Codes meiden wie ein Minenfeld und regelrecht Angst haben sie zu verändern, stecken dort fast immer technische Schulden dahinter.\nHäufige und wiederkehrende Bugs # Bugs, die immer wieder auftauchen, oft an denselben Stellen, deuten stark auf strukturelle Probleme hin. Man muss die Ursachen angehen, statt die Symptome zu bekämpfen. Der eigentliche Code ist fragil oder unverständlich und kann deshalb nicht wirklich repariert werden.\nNiemand versteht den Code mehr # Wenn ein Entwickler einen Abschnitt öffnet und erstmal zehn Minuten braucht, um zu verstehen was da passiert oder schlimmer, wenn niemand im Team mehr erklären kann, warum etwas so gebaut wurde, sind das fast sicher technische Schulden.\nEinarbeitung neuer Entwickler dauert ungewöhnlich lang # Ein gesundes Projekt lässt sich in überschaubarer Zeit verstehen. Wenn neue Teammitglieder Wochen oder Monate brauchen, um produktiv zu werden, ist das oft ein Zeichen, dass der Code zu komplex, zu schlecht dokumentiert oder inkonsistent geworden ist.\nWie kann man sie verhindern # Technische Schulden vollständig zu vermeiden ist unrealistisch und wie wir gesehen haben, manchmal auch gar nicht sinnvoll. Das Ziel ist nicht null Schulden, sondern die Schulden bewusst aufnehmen und sie zeitnah und kontrolliert wieder zurückzuzahlen. Hier sind die wichtigsten Maßnahmen dafür.\nKlare Entwicklungsrichtlinien etablieren # Ein Team braucht eine gemeinsame Basis: Coding Standards, Codeversionierung (Git), Architekturprinzipien, Konventionen für Benennung und Struktur. Das muss kein dickes Handbuch sein, aber es muss die wichtigsten Punkte enthalten, allen bekannt sein und aktiv gelebt werden.\nAutomatisierte Tests von Anfang an # Ein Testkonzept muss von Anfang existieren und Tests dürfen nicht bis zum Schluss aufgeschoben werden, denn sie sind eine Investition in die Zukunft. Wer von Beginn an testet, kann später ohne Angst refactoren, weil sofort klar wird, dass etwas bricht und wo. Der beste Zeitpunkt für Tests ist immer jetzt.\nRegelmäßiges Refactoring einplanen # Refactoring muss zum normalen Entwicklungsalltag gehören und darf nicht auf unbestimmte Zeit verschoben werden. Kleine, regelmäßige Aufräumarbeiten verhindern, dass sich Schulden überhaupt erst gefährlich anhäufen.\nCode Reviews # Vier Augen sehen mehr als zwei, sagt man und es ist tatsächlich so, denn man sieht seine eigenen Fehler oft nicht. Regelmäßige Code Reviews helfen dabei, schlechte Lösungen früh zu erkennen, bevor sie sich im System festsetzen. Gleichzeitig fördern sie den Wissensaustausch im Team, was ein unterschätzter Nebeneffekt ist.\nDokumentation als Teil der Arbeit verstehen # Dokumentation darf nicht als ein notwendiges Übel angesehen werden, sondern muss Teil der eigentlichen Arbeit sein. Wer während der Entwicklung fünf Minuten investiert um zu erklären, warum eine (schlechtere) Entscheidung so getroffen wurde, spart seinem Team in der Zukunft Zeit und Kopfzerbrechen.\nTechnische Schulden sichtbar machen # Was nicht sichtbar ist, wird nicht priorisiert oder \u0026ldquo;aus den Augen aus dem Sinn\u0026rdquo;. Technische Schulden sollten aktiv erfasst werden, sei es als Einträge im Backlog oder zum Beispiel als (TODO-) Tags im Code. Nur wenn das Team und das Management sehen, was sich angesammelt hat, können richtige Entscheidungen getroffen werden, wann und wie die Schulden zurückgezahlt werden.\nZeitdruck bewusst managen # Das ist leichter gesagt als getan und dennoch extrem wichtig. Wenn Deadlines auf Kosten der Qualität gehen, muss man diese Entscheidung bewusst treffen und die Konsequenzen sollten klar sein. Wer einen Kompromiss eingeht, muss ihn dokumentieren und sicherstellen, dass die Schulden auch zeitnah bezahlt werden.\nFazit # Technische Schulden sind (oft) kein Zeichen von schlechtem Entwicklerhandwerk, sondern in fast jedem Softwareprojekt vertreten. Manchmal entstehen sie durch Druck von außen, manchmal durch fehlende Strukturen, manchmal schlicht durch Unwissenheit.\nGefährlich werden sie dann, wenn man sie ignoriert.\nDer erste und meiner Meinung nach wichtigste Schritt ist Bewusstsein. Technische Schulden wahrnehmen, sie benennen und als das behandeln, was sie sind, eine bewusste Entscheidung mit Konsequenzen. Wer das tut, kann sie kontrollieren, aktiv abbauen und verhindern, dass sie das Projekt eines Tages lahmlegen.\nSauberer Code muss immer das Ziel sein, denn mit ihm steht und fällt der langfristige Erfolg eines Projekts.\nVorschaubild # freepik\n","date":"31 März 2026","externalUrl":null,"permalink":"/posts/tech-debts/","section":"Posts","summary":"Technische Schulden sind der stille Begleiter fast jedes Softwareprojekts. In diesem Artikel untersuche ich, wie sie entstehen, woran man sie erkennt und wie man sie kontrolliert, bevor sie zum echten Problem werden.","title":"Technische Schulden","type":"posts"},{"content":"","date":"31 März 2026","externalUrl":null,"permalink":"/tags/testing/","section":"Tags","summary":"","title":"Testing","type":"tags"},{"content":" Einleitung # Die folgenden drei Tickets kommen mir in ähnlicher Form fast täglich unter. Was auf den ersten Blick wie ein Problem des zuständigen Entwicklers wirkt, hat weitreichendere Folgen. Folgen für den Nutzer, der das Ticket erstellt hat und für das Projekt bzw. die Firma als Ganzes. Am Ende zeige ich dir noch, wie ein gutes Ticket aussieht und gebe dir ein Template mit auf den Weg, das du verwenden kannst.\nTicket 1 # Hilfe, nichts geht mehr!!! Ticket 2 # So ein Mist, das Programm macht nicht was es soll!!11elf1! Ticket 3 # Titel: Problem mit der Anwendung\nBeschreibung:\nHallo zusammen,\nich arbeite jetzt schon seit mehreren Wochen mit der Anwendung und muss sagen, dass ich anfangs wirklich begeistert war. Die Oberfläche sieht gut aus und das Konzept dahinter finde ich auch super. Wirklich tolle Arbeit bisher!\nAllerdings ist mir in letzter Zeit aufgefallen, dass es da ein Problem gibt. Ich weiß nicht genau, wie ich es beschreiben soll, aber es funktioniert einfach nicht so, wie es sollte. Ich habe das auch schon meinem Kollegen gezeigt und der \u0026gt; meinte auch, dass das komisch ist.\nDas Ganze ist schon ziemlich ärgerlich, weil ich dadurch in meiner Arbeit aufgehalten werde. Ich habe es mehrmals versucht, aber es klappt einfach nicht. Manchmal geht es, manchmal nicht. Gestern hat es noch funktioniert, glaube ich, aber \u0026gt; heute auf jeden ll nicht mehr.\nKönnt ihr euch das mal anschauen? Das wäre echt super, weil ich das wirklich dringend brauche für mein Projekt. Ich hoffe, das lässt sich schnell fixen!\nVielen Dank schonmal!\nWas ist an diesen Tickets schlecht # Gehen wir die drei Tickets systematisch durch und schauen uns an, was nicht so gut ist.\nDie ersten beiden sind emotionale Ausbrüche ohne Substanz – nachvollziehbar im Moment der Frustration, aber als Arbeitsgrundlage unbrauchbar.\nDas dritte Ticket täuscht durch seine Länge über die fehlenden Inhalte hinweg: Zwischen Smalltalk und Höflichkeitsfloskeln verstecken sich keine verwertbaren Informationen. Keine Schritte zur Reproduktion, keine Fehlermeldungen, keine Systemangaben, also nichts, womit ein Entwickler arbeiten könnte.\nWas haben diese drei Tickets gemeinsam? Sie zwingen den Bearbeiter zum Rätselraten.\nDas Fehlen konkreter Details zieht sich durch alle drei Beispiele:\nWas genau funktioniert nicht?\nUnter welchen Bedingungen tritt das Problem auf?\nWelche Fehlermeldung erscheint?\nDiese Fragen bleiben unbeantwortet.\nUnd genau hier beginnen die Folgen, die weit über die Frustration des zuständigen Entwicklers hinausgehen.\nFolgen für den Entwickler # Wollen wir uns zunächst den negativen Folgen für den Entwickler widmen, der ein solches Ticket bearbeitet.\nZeitverschwendung durch Detektivarbeit # Statt sich direkt der Lösung des Problems zu widmen, muss der Entwickler erst einmal herausfinden, was überhaupt das Problem ist. Das bedeutet: Rückfragen stellen, auf Antworten warten, den Kontext wechseln zwischen verschiedenen Aufgaben, und im schlimmsten Fall selbst auf die Suche nach dem Fehler gehen ohne zu wissen, wonach genau gesucht werden soll. Was in 30 Minuten erledigt sein könnte, zieht sich über Tage hin – nicht wegen der Komplexität des Problems, sondern wegen fehlender Informationen.\nFrustration und sinkende Motivation # Wer täglich mit unvollständigen oder emotionalen Tickets konfrontiert wird, verliert die Freude an der Arbeit. Die ständige Notwendigkeit, grundlegende Informationen mühsam zusammenzutragen, frustriert. Besonders demotivierend wirkt es, wenn man spürt, dass sich der Ticketersteller keine fünf Minuten Zeit genommen hat, während der Entwickler nun Stunden investieren muss. Diese Frustration summiert sich und kann langfristig zu Resignation führen – man arbeitet dann nur noch das Nötigste ab, statt mit Engagement an Lösungen zu arbeiten.\nQualitätsverlust bei der Problemlösung # Ohne vollständige Informationen steigt das Risiko von Fehleinschätzungen. Der Entwickler muss raten, welcher Fall gemeint ist, arbeitet möglicherweise am falschen Problem oder übersieht wichtige Randbedingungen.\nDas Ergebnis kann vieles sein, sehr oft ist es aber für die Entwickler unbefriedigend. So bekämpfen Fixes oft nur Symptome statt Ursachen, neue Bugs entstehen durch unvollständiges Verständnis der Situation oder Lösungen gehen am eigentlichen Problem vorbei.\nDie Qualität der Arbeit leidet nicht aus Unfähigkeit, sondern aus mangelnder Informationsgrundlage, welche wiederum aus ungenauer Kommunikation resultiert.\nFolgen für den Nutzer # Auch der Nutzer selbst leidet unter schlechten Tickets und das oft mehr als ihm selbst bewusst ist.\nZeitverschwendung durch unnötige Rückfragen # Ein unvollständiges Ticket löst fast immer eine Rückfragekette aus.\nDer Entwickler fragt nach, der Nutzer antwortet, stellt fest, dass er eine wichtige Information vergessen hat, antwortet erneut und das Ganze kann sich über Tage hinziehen. Die Ironie dabei ist, dass der Nutzer, die Zeit, die er beim Schreiben des Tickets gespart hat, mehrfach durch asynchrone Kommunikation zurück zahlt.\nEin sorgfältig formuliertes Ticket wäre in Summe deutlich schneller gewesen.\nFrustration durch Missverständnisse # Wenn Kontext fehlt, muss der Entwickler Annahmen treffen und diese Annahmen sind nicht immer richtig. Das Ergebnis ist oft eine Lösung, die am eigentlichen Problem vorbeigeht, ein Nutzer, der nochmals ein Ticket erstellen muss und auf beiden Seiten das Gefühl, nicht verstanden zu werden.\nMissverständnisse durch unklare Kommunikation sind vermeidbar und trotzdem einer der häufigsten Gründe für Unzufriedenheit auf beiden Seiten.\nSchlechteres Produkt # Wer ein Problem nicht klar beschreibt, riskiert, dass es nicht korrekt behoben wird. Reproduzierbare Schritte, Fehlermeldungen und Systemangaben sind keine bürokratischen Hürden, sondern die Grundlage dafür, dass ein Fix tatsächlich das Problem trifft und nicht nur ein Symptom beseitigt.\nLetztlich bekommt der Nutzer ein Produkt, das schlechter ist, als es sein müsste und das nur weil Informationen fehlten und nicht weil niemand helfen wollte.\nFolgen für das Projekt oder die Firma # Auf individueller Ebene sind es Kommunikationsprobleme, die zu Frustration führen können. Auf Projekt- oder Firmenebene hat das wirtschaftliche Folgen.\nHohe Kosten durch Zeitverschwendung # Entwicklerzeit ist teuer. Jede Stunde, die ein Entwickler damit verbringt, fehlende Informationen zu rekonstruieren, Rückfragen zu stellen oder am falschen Problem zu arbeiten, ist eine Stunde, die nicht in produktive Arbeit fließt. Denn er ist nicht nur länger als nötig mit diesem Ticket beschäftigt, sondern andere Aufgaben bleiben ebenfalls liegen.\nMultipliziert man diesen Effekt über ein Team und mehrere Monate, entstehen erhebliche versteckte Kosten, die in keiner Aufwandsschätzung auftauchen, weil sie als unvermeidlicher Overhead abgebucht werden, obwohl sie vermeidbar wären.\nVerlust von Entwicklern # Gute Entwickler haben Optionen und wer dauerhaft in einem Umfeld arbeitet, in dem schlechte Kommunikation die Norm ist und Frustration der tägliche Begleiter, sucht sich früher oder später etwas Besseres. Der Verlust erfahrener Entwickler ist für Projekte und Firmen eine der teuersten Konsequenzen schlechter Prozesse, auch wenn der Zusammenhang zwischen der Qualität von Tickets und der Fluktuation im Team selten direkt gezogen wird.\nEs ist oft nicht der einzige Grund für einen Firmenwechsel, kann das Fass aber zum Überlaufen bringen.\nSo sieht ein gutes Ticket aus # Zum Abschluss, als Gegenstück zu den drei Beispielen vom Anfang, zunächst ein Template als Ausgangspunkt, gefolgt von einem konkreten Beispiel, das zeigt, wie es in der Praxis aussehen kann.\nTemplate # **Titel:** Kurze, präzise Zusammenfassung des Problems **Umgebung:** - Betriebssystem / Browser / Version: - Betroffene Version der Anwendung: **Schritte zur Reproduktion:** 1. ... 2. ... 3. ... **Erwartetes Verhalten:** Was sollte passieren? **Tatsächliches Verhalten:** Was passiert stattdessen? **Fehlermeldung / Screenshots:** (Falls vorhanden) **Zusätzlicher Kontext:** Tritt das Problem immer auf oder nur unter bestimmten Bedingungen? Ausgefülltes Beispiel # Titel: Speichern-Schaltfläche im Formular „Neuer Auftrag\u0026quot; reagiert nicht\nUmgebung:\nWindows 11, Chrome 123 Anwendungsversion: 2.4.1 Schritte zur Reproduktion:\nEinloggen als normaler Nutzer (kein Admin) Navigieren zu „Aufträge\u0026quot; -\u0026gt; „Neuer Auftrag\u0026quot; Formular vollständig ausfüllen Auf „Speichern\u0026quot; klicken Erwartetes Verhalten: Der Auftrag wird gespeichert und die Ansicht wechselt zur Auftragsübersicht.\nTatsächliches Verhalten: Die Schaltfläche reagiert nicht. Es erscheint keine Fehlermeldung. Die Seite bleibt unverändert.\nFehlermeldung: In der Browser-Konsole erscheint: Uncaught TypeError: Cannot read properties of undefined (reading 'id')\nZusätzlicher Kontext: Das Problem tritt reproduzierbar auf. Mit einem Admin-Account funktioniert das Speichern. Das Problem besteht seit Version 2.4.0.\nFazit # Gute Tickets sind keine Frage von Talent oder technischem Wissen, sie sind eine Frage von Respekt und Verantwortung.\nRespekt gegenüber der Zeit des Entwicklers, der das Problem lösen soll, und Respekt gegenüber dem Team, das an einem gemeinsamen Produkt arbeitet.\nUnd letztlich auch Verantwortung gegenüber sich selbst und der Firma, für die man arbeitet.\nDas Template aus diesem Artikel ist ein Anfang und muss nicht blind befolgt werden. Es soll vielmehr als Einstieg dienen und eine Idee vermitteln, worauf es Entwicklern ankommt und was ihnen hilft ihre Aufgabe schnell und zufriedenstellend zu erledigen.\nEin gutes Ticket kostet fünf Minuten, ein schlechtes Ticket hingegen kostet alle Beteiligten ein Vielfaches davon.\nVorschaubild # Erstellt mit Flux-2\n","date":"18 März 2026","externalUrl":null,"permalink":"/posts/bad-tickets/","section":"Posts","summary":"Schlechte Tickets frustrieren nicht nur Entwickler. Sie kosten Zeit, Geld und im schlimmsten Fall gute Mitarbeiter. Dieser Artikel zeigt, warum gute Tickets so wichtig sind und gibt ein Template mit auf den Weg.","title":"Schlechte Tickets – ein Problem für alle","type":"posts"},{"content":"","date":"11 März 2026","externalUrl":null,"permalink":"/tags/dynamic-dispatch/","section":"Tags","summary":"","title":"Dynamic Dispatch","type":"tags"},{"content":"","date":"11 März 2026","externalUrl":null,"permalink":"/tags/generics/","section":"Tags","summary":"","title":"Generics","type":"tags"},{"content":"","date":"11 März 2026","externalUrl":null,"permalink":"/tags/monomorphisierung/","section":"Tags","summary":"","title":"Monomorphisierung","type":"tags"},{"content":"","date":"11 März 2026","externalUrl":null,"permalink":"/categories/rust/","section":"Categories","summary":"","title":"Rust","type":"categories"},{"content":"","date":"11 März 2026","externalUrl":null,"permalink":"/tags/rust/","section":"Tags","summary":"","title":"Rust","type":"tags"},{"content":"","date":"11 März 2026","externalUrl":null,"permalink":"/series/rusty-bytes/","section":"Series","summary":"","title":"Rusty Bytes","type":"series"},{"content":" Was sind Traits? # Traits sind Rusts Version von Interfaces. Ein Trait definiert eine Schnittstelle, eine Menge von Methoden, die ein Typ implementieren muss, außer es gibt eine Standardimplementierung. Wer schon mit Interfaces aus C#, Java oder Kotlin gearbeitet hat, kennt das Konzept.\ntrait Greet { fn hello(\u0026amp;self) -\u0026gt; String; } struct German; struct English; impl Greet for German { fn hello(\u0026amp;self) -\u0026gt; String { String::from(\u0026#34;Hallo!\u0026#34;) } } impl Greet for English { fn hello(\u0026amp;self) -\u0026gt; String { String::from(\u0026#34;Hello!\u0026#34;) } } Traits können auch eine Standardimplementierung mitbringen, die ein Typ überschreiben kann aber nicht muss:\ntrait Greet { fn hello(\u0026amp;self) -\u0026gt; String { String::from(\u0026#34;Hi!\u0026#34;) } } So weit, so bekannt.\nInteressant wird es, wenn man Traits als Parameter verwendet, denn da beginnt die eigentliche Frage: Was passiert dann zur Compile-Zeit und welche Auswirkungen hat es auf die Laufzeit?\nMonomorphisierung – Polymorphismus zur Compile-Zeit # Wenn eine Funktion einen generischen Typ mit Trait-Bound erwartet, erzeugt der Rust-Compiler für jeden konkreten Typ, mit dem die Funktion aufgerufen wird, eine eigene spezialisierte Version. Das nennt sich Monomorphisierung.\nfn greet\u0026lt;T: Greet\u0026gt;(g: \u0026amp;T) { println!(\u0026#34;{}\u0026#34;, g.hello()); } Der Compiler sieht, dass greet mit German und English aufgerufen wird, und erzeugt intern je eine Funktion für Englisch und eine für Deutsch:\nfn greet_german(g: \u0026amp;German) { println!(\u0026#34;{}\u0026#34;, g.hello()); } fn greet_english(g: \u0026amp;English) { println!(\u0026#34;{}\u0026#34;, g.hello()); } Das ist gleichbedeutend mit dem impl Trait-Syntax, der etwas lesbarer ist:\nfn greet(g: \u0026amp;impl Greet) { println!(\u0026#34;{}\u0026#34;, g.hello()); } Vorteil:\nZur Laufzeit gibt es keinen Overhead. Der Compiler kennt den konkreten Typ, kann ihn inline optimieren und direkt den richtigen Funktionsaufruf einsetzen.\nNachteil:\nDie Binärgröße wächst, denn für jeden Typ, mit dem die Funktion genutzt wird, landet eine eigene Kopie im kompilierten Code.\nDynamic Dispatch – Polymorphismus zur Laufzeit # Manchmal ist der konkrete Typ erst zur Laufzeit bekannt, so zum Beispiel wenn verschiedene Typen in einer Liste gesammelt werden sollen.\nHier kommt dyn Trait ins Spiel.\nfn greet(g: \u0026amp;dyn Greet) { println!(\u0026#34;{}\u0026#34;, g.hello()); } Statt einer spezialisierten Funktion pro Typ erzeugt der Compiler ein Trait Object. Das ist ein sogenannter Fat Pointer, der aus zwei Teilen besteht, einem Zeiger auf die Daten und einem Zeiger auf eine vtable.\nDie vtable wiederum ist eine Tabelle mit Funktionszeigern für alle Methoden des Traits, wo zur Laufzeit die richtige Implementierung nachgeschlagen und aufgerufen wird.\nlet greeters: Vec\u0026lt;Box\u0026lt;dyn Greet\u0026gt;\u0026gt; = vec![ Box::new(German), Box::new(English), ]; for g in \u0026amp;greeters { println!(\u0026#34;{}\u0026#34;, g.hello()); } Das wäre mit Monomorphisierung nicht möglich, da der Compiler den Typ jedes Eintrags zur Compile-Zeit kennen müsste.\nVorteil:\nFlexibel, kleinere Binärgröße, heterogene Collections möglich.\nNachteil:\nLaufzeit-Overhead durch den vtable-Lookup, keine Inlining-Optimierungen möglich.\nWann was? # impl Trait / Generics dyn Trait Auflösung Compile-Zeit Laufzeit Performance Höher Etwas geringer Binärgröße Wächst pro Typ Konstant Heterogene Collections ✗ ✓ Typinformation Vollständig bekannt Zur Compile-Zeit nicht bekannt Als Faustregel gilt:\nimpl Trait ist der Standard dyn Trait kommt zum Einsatz wenn der Typ erst zur Laufzeit bekannt ist oder eine heterogene Collection benötigt wird. Fazit # Traits sind mehr als nur Interfaces. Die Entscheidung zwischen Monomorphisierung und Dynamic Dispatch ist eine Entscheidung zwischen Compile-Zeit-Garantien und Laufzeit-Flexibilität.\nIm Vergleich zu Java oder C#, wo jeder Methodenaufruf über eine virtuelle Tabelle aufgelöst wird, gibt Rust einem die Wahl – und macht sie sichtbar.\nDas ist typisch Rust. Explizit, kontrolliert und ohne versteckten Overhead, aber mit einer etwas steileren Lernkurve.\nVorschaubild # Erstellt mit ChatGPT.\n","date":"11 März 2026","externalUrl":null,"permalink":"/posts/rusty-bytes/traits/","section":"Posts","summary":"Traits sind mehr als nur Interfaces und wenn du verstehst, was der Compiler daraus macht, schreibst du bewusster und bekommst performanteren Code.","title":"Rusty Bytes #1 - Traits, Monomorphisierung und Dynamic Dispatch","type":"posts"},{"content":"","date":"11 März 2026","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"11 März 2026","externalUrl":null,"permalink":"/tags/traits/","section":"Tags","summary":"","title":"Traits","type":"tags"},{"content":"","date":"4 März 2026","externalUrl":null,"permalink":"/tags/browser/","section":"Tags","summary":"","title":"Browser","type":"tags"},{"content":"","date":"4 März 2026","externalUrl":null,"permalink":"/tags/kernel/","section":"Tags","summary":"","title":"Kernel","type":"tags"},{"content":"","date":"4 März 2026","externalUrl":null,"permalink":"/tags/ladybird/","section":"Tags","summary":"","title":"Ladybird","type":"tags"},{"content":"","date":"4 März 2026","externalUrl":null,"permalink":"/categories/linux/","section":"Categories","summary":"","title":"Linux","type":"categories"},{"content":"","date":"4 März 2026","externalUrl":null,"permalink":"/tags/linux/","section":"Tags","summary":"","title":"Linux","type":"tags"},{"content":"","date":"4 März 2026","externalUrl":null,"permalink":"/categories/open-source/","section":"Categories","summary":"","title":"Open Source","type":"categories"},{"content":"","date":"4 März 2026","externalUrl":null,"permalink":"/tags/open-source/","section":"Tags","summary":"","title":"Open Source","type":"tags"},{"content":"","date":"4 März 2026","externalUrl":null,"permalink":"/series/quelltext/","section":"Series","summary":"","title":"Quelltext","type":"series"},{"content":" Quelltext #3 # Auch diese Woche möchte ich dir wieder von Projekten und Neuigkeiten berichten, die mich erstaunt, bewegt und verwundert haben.\nLinux Kernel # Zum Linux Kernel gibt es gleich zwei spannende Neuigkeiten.\nExtended LTS # Die Kernel Versionen 6.18, 6.12 und 6.6 bekommen nun offiziell verlängerten Support 1.\nVersion Supportende (jetzt) Supportende (bisher) Released 6.18 Dezember 2028 Dezember 2027 2025-11-30 6.12 Dezember 2028 Dezember 2026 2024-11-17 6.6 Dezember 2027 Dezember 2026 2023-10-29 Version 7.0 # Mit dem Release von Linux 6.19 am 8. Februar hat Linus Torvalds eine große Ankündigung gemacht: Die nächste Kernel Version wird Linux 7.0 heißen.2\nTorvalds betont ausdrücklich, dass es kein großes \u0026ldquo;Breaking Change\u0026rdquo; Release ist, sondern wie immer „solid progress\u0026quot;.\nDas Merge-Window für 7.0 öffnete am 9. Februar, der erste Release Candidate erschien am 22. Februar. Die finale Veröffentlichung wird für Mitte April erwartet.\nRust-Support im Kernel gilt nun als stabil und ist nicht mehr als experimentell markiert.\nFür Gamer interessant: Der neue TIP Time Slice Extension-Mechanismus erlaubt es Anwendungen, kurzzeitig mehr CPU-Zeit anzufordern, was sich positiv auf 1%-Low-FPS auswirken könnte.\nAußerdem kommen ein Live Update Orchestrator für unterbrechungsfreie Kernel-Upgrades unter laufenden VMs, Direct I/O für Btrfs bei Blockgrößen über der Page Size, autonomes Self-Healing für XFS sowie Unterstützung für ML-DSA Post-Quantum-Signaturen.\nMeine Meinung # Längere Unterstützung von Kernel Versionen ist vor allem für Serverbetreibende interessant, da ein Kernel-Update immer ein gewisses Risiko birgt.\nEine neue Kernel Version ist immer spannend. Und wenn auch keine großen \u0026ldquo;Breaking Changes\u0026rdquo; kommen, so bin ich doch sehr gespannt auf den neuen TIP Time Slice Extension-Mechanismus. Außerdem freut mich das langfristige Commitment zu Rust, da es meiner Meinung nach wieder frischen Wind in die Linux-Entwicklung bringt.\nPop!_OS Upgrade 24.04 LTS # Pop!_OS bekommt das sehr lang ersehnte Upgrade von der Version 22.04 auf die Version 24.043. Die Entwickler von System76 hatten sich entschieden, das Upgrade nach hinten zu verschieben, um sich auf die Entwicklung der neuen Desktopumgebung konzentrieren zu können.\nDie neue Version kommt nun auch offiziell mit dem COSMIC Desktop als Standard.\nMeine Meinung # Auch wenn ich mittlerweile glücklich bei EndeavourOS bin, habe ich Pop!_OS lange Zeit verwendet und nutze es noch heute auf einem älteren Laptop. Daher freue ich mich sehr, dass dieses Upgrade nun endlich kommt, gerade weil es in der Community in letzter Zeit immer Unmut darüber gab, dass System76 das Upgrade so lange herausgezögert hat.\nLadybird Browser wechselt zu Rust # Das Ladybird-Projekt, das mit großem Ehrgeiz einen unabhängigen Browser-Engine von Grund auf neu schreibt, hat einen bemerkenswerten Kurswechsel vollzogen:\nNach dem gescheiterten Versuch mit Swift setzt Gründer Andreas Kling nun auf Rust als Nachfolger für C++.4 Kling kündigt aber auch an, dass der Wechsel sukzessive durchgeführt wird und somit noch eine Weile in C++ und Rust parallel entwickelt wird.\nSwift hatte Probleme mit der C++-Interoperabilität und begrenztem Platform-Support außerhalb des Apple-Ökosystems. Rust bringt beides mit und hat dazu ein reifes Ökosystem sowie viele bestehende Contributor, die die Sprache bereits kennen.\nMeine Meinung # Die schnellen Wechsel von C++ auf Swift und dann zu Rust hinterlassen bei mir einen etwas unangenehmen Beigeschmack, der Unbeständigkeit. Andererseits ist Ladybird noch ein junges Projekt und da gehören Fehlentscheidungen und schnelle Änderungen noch dazu. Den Wechsel zu Swift konnte ich allerdings von Anfang an nicht ganz nachvollziehen.\nAls passionierter Rust-Entwickler freue ich mich natürlich über die Wahl von Rust als Programmiersprache, da ich mich zum einen selbst als Contributor beteiligen kann aber auch, weil es dem Rust-Universum noch mehr Vielfalt schenkt. Da Rust seine Wurzeln bei Mozilla hat, ist es meiner Meinung nach eine naheliegende Wahl für einen Browser.\nRust # State of Rust Survey 2025 # Die Ergebnisse der diesjährigen Umfrage sind da: 7.156 Antworten und damit etwas weniger als im Vorjahr 5.\nInhaltlich gibt es wenig Überraschung. Langsame Compile-Zeiten und hoher Speicherverbrauch bleiben die meistgenannten Kritikpunkte.\nPositiv fiel auf, dass lang ersehnte Features wie Let Chains und Async Closures gut ankommen.\nGanz oben auf der Wunschliste stehen: Generic Const Expressions und verbesserte Trait-Methoden.\nDebugging Survey 2026 # Direkt aus den Ergebnissen der State of Rust Survey heraus hat das Compiler Team nachgehakt. 6 Debugging taucht regelmäßig als eines der größten Ärgernisse auf.\nVon inkonsistenter Unterstützung über verschiedene Debugger (GDB, LLDB, CDB) und Betriebssysteme bis hin zu fehlendem First-Class-Support für Async-Code.\nDie Umfrage läuft bis 13. März, wer also Rust aktiv nutzt und einen Einfluß auf dessen Zukunft nehmen möchte, sollte teilnehmen.\nMeine Meinung # Rust zieht sich durch diese Ausgabe des Quelltext wie ein rostroter Faden.\nEs freut mich zu sehen, dass Rust in so vielen Projekten ein fester Bestandteil geworden ist und die Rust Foundation regelmäßige Umfragen veranstaltet und daraus auch echte Konsequenzen zieht. Das schafft meiner Meinung nach Vertrauen und sichert Rust eine hoffentlich lange Zukunft.\nVorschaubild # Erstellt mit ChatGPT\nCommit von Greg Kroah-Hartman\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLinus Torvalds Ankündigung der neuen Kernel Version\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nAnkündigung des Upgrades im System76 Blog\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nLadybird Blog Artikel zum Umstieg auf Rust\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRust Blog: State of Rust Survey\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nRust Blog: Debugging Survey\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"4 März 2026","externalUrl":null,"permalink":"/posts/source/linux-ladybird-rust/","section":"Posts","summary":"Eine neue Ära für den Linux Kernel, ein lang ersehntes Upgrade für Pop!_OS, ein Browser der seine Sprache wechselt – und Rust zieht sich durch alles wie ein rostroter Faden.","title":"Quelltext #3 - Linux, Ladybird und Rust","type":"posts"},{"content":"","date":"4 März 2026","externalUrl":null,"permalink":"/tags/softwareentwicklung/","section":"Tags","summary":"","title":"Softwareentwicklung","type":"tags"},{"content":"","date":"2 März 2026","externalUrl":null,"permalink":"/categories/empfehlung/","section":"Categories","summary":"","title":"Empfehlung","type":"categories"},{"content":"","date":"2 März 2026","externalUrl":null,"permalink":"/series/empfehlungen/","section":"Series","summary":"","title":"Empfehlungen","type":"series"},{"content":" Quick Facts # Name Rustlings Typ Interaktives Terminal-Lernprogramm Sprache Englisch Preis Kostenlos, Open Source (MIT) Übungen ~100 Zeitaufwand ca. 10–15 Stunden gesamt Voraussetzungen Grundlegende Programmierkenntnisse Link rustlings.rust-lang.org Worum geht es # Rustlings ist eine Sammlung kleiner Übungsaufgaben, die direkt im Terminal läuft.\nDas Konzept ist einfach. Du bekommst Übungsdateien, die entweder nicht kompilieren oder einen Test nicht bestehen. Deine Aufgabe ist es, den Fehler zu finden und zu beheben. Rustlings beobachtet dabei die Datei und gibt dir Feedback, sobald du speicherst.\nDas Programm ist ein offizielles Rust-Foundation-Projekt und eng mit dem offiziellen Rust-Buch verbunden. Das Buch erklärt die Konzepte und Rustlings gibt dir die Möglichkeit sie direkt zu üben.\nFür wen ist es geeignet # Reine Anfänger ohne Vorerfahrung werden vermutlich schnell überfordert sein. Nicht wegen der Aufgaben selbst, sondern weil Konzepte wie Ownership oder das Typsystem vorausgesetzt werden, ohne sie vollständig herzuleiten.\nRustlings richtet sich an Entwickler*innen, die bereits eine Programmiersprache kennen und Rust von Grund auf lernen möchten. Auch als Auffrischung funktioniert Rustlings gut. Wer Rust eine Weile nicht aktiv genutzt hat und wieder einsteigen möchte, kann sich gezielt einzelne Kapitel vorknöpfen, ohne von vorne anfangen zu müssen.\nWelche Themen werden behandelt # Rustlings deckt den Großteil der Rust-Grundlagen ab. Zu jeder Übung gibt es eine oder mehrere Stellen im Buch, die tiefere Erklärungen bieten.\nAufgaben Kapitel im Buch variables §3.1 functions §3.3 if §3.5 primitive_types §3.2, §4.3 vecs §8.1 move_semantics §4.1-2 structs §5.1, §5.3 enums §6, §19.3 strings §8.2 modules §7 hashmaps §8.3 options §10.1 error_handling §9 generics §10 traits §10.2 lifetimes §10.3 tests §11.1 iterators §13.2-4 smart_pointers §15, §16.3 threads §16.1-3 macros §20.5 clippy Appendix D Quelle: Rustlings Github Repository\nWie lernt man am besten damit # Der klassische Ansatz, den auch das offizielle Rust-Buch empfiehlt, ist eine Kombination aus beiden Ressourcen parallel: Kapitel lesen, passende Rustlings-Aufgaben lösen, weiterlesen. Das Buch erklärt das jeweilige Konzept, Rustlings lässt einen es direkt umsetzen.\nWer lieber hands-on lernen möchte, kann auch direkt mit Rustlings beginnen und bei Bedarf im Buch oder in der Dokumentation nachschlagen. Das ist für erfahrene Entwicklerinnen und Entwickler oft der schnellere Weg.\nMeine Empfehlung, nicht gleich die Musterlösung öffnen, sonst nimmt man sich selbst etwas weg.\nPersönliches Highlight # Was mich an Rustlings am meisten überzeugt, ist der schnelle Feedback-Loop. Man spart sich das Aufsetzen eines Projekts, das Schreiben von Boilerplate und das Navigieren durch Compiler-Fehler in fremdem Code.\nMan macht einfach auf, liest den Fehler, denkt nach und schreibt Code.\nOder auch nicht, aber dann weiß man zumindest genau, woran es hängt.\nAußerdem zeigt Rustlings nach jeder gelösten Aufgabe die empfohlene Musterlösung. Man lernt also nicht nur, den Code zum Laufen zu bringen, sondern auch, wie idiomatisches Rust aussieht. Und das kann deutlich vom eigenen ersten Ansatz abweichen.\nZum Schluss # Rustlings ist kein vollständiger Kurs, ersetzt nicht das eigene Lesen oder gar einen erfahrenen Mentor, aber das will es auch nicht. Es ist einfach ein wirklich gutes Werkzeug zum Üben.\nWer Rust lernen möchte und schon etwas Programmiererfahrung hat, findet hier einen schnellen und fundierten Einstieg in die Sprache. Ich habe es bereits durchgearbeitet und dabei genau das gefunden, was ich gesucht hatte: einen schnellen Wiedereinstieg in Rust.\nVorschaubild # Erstellt mit ChatGPT.\nBasierend auf „Ferris the Crab“ von Karen Rustad Tölva (Public Domain).\n","date":"2 März 2026","externalUrl":null,"permalink":"/posts/recommendations/rustlings/","section":"Posts","summary":"Hands-on idiomatisches Rust lernen? Begleitend zum Rust-Buch? Dann ist Rustlings genau das richtige für dich.","title":"Empfehlungen: Rustlings","type":"posts"},{"content":"","date":"2 März 2026","externalUrl":null,"permalink":"/tags/lernen/","section":"Tags","summary":"","title":"Lernen","type":"tags"},{"content":"","date":"2 März 2026","externalUrl":null,"permalink":"/categories/programmiersprache/","section":"Categories","summary":"","title":"Programmiersprache","type":"categories"},{"content":"","date":"2 März 2026","externalUrl":null,"permalink":"/tags/rustlings/","section":"Tags","summary":"","title":"Rustlings","type":"tags"},{"content":"","date":"2 März 2026","externalUrl":null,"permalink":"/tags/terminal/","section":"Tags","summary":"","title":"Terminal","type":"tags"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/tags/arc-browser/","section":"Tags","summary":"","title":"Arc Browser","type":"tags"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/categories/browser/","section":"Categories","summary":"","title":"Browser","type":"categories"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/tags/codeberg/","section":"Tags","summary":"","title":"Codeberg","type":"tags"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/tags/copilot/","section":"Tags","summary":"","title":"Copilot","type":"tags"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/tags/firefox/","section":"Tags","summary":"","title":"Firefox","type":"tags"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/tags/gentoo/","section":"Tags","summary":"","title":"Gentoo","type":"tags"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/tags/github/","section":"Tags","summary":"","title":"Github","type":"tags"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/tags/gitlab/","section":"Tags","summary":"","title":"Gitlab","type":"tags"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/tags/google-summer-of-code/","section":"Tags","summary":"","title":"Google Summer of Code","type":"tags"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/tags/gsoc/","section":"Tags","summary":"","title":"GSoC","type":"tags"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/tags/linus-torvalds/","section":"Tags","summary":"","title":"Linus Torvalds","type":"tags"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/categories/pers%C3%B6nliches/","section":"Categories","summary":"","title":"Persönliches","type":"categories"},{"content":" Quelltext #2 # Willkommen zum Quelltext #2.\nDiese Woche: ein Sommer voller Open-Source-Möglichkeiten, ein Browser, der gerade Zen-untypisch durch die Decke geht, und Gentoo erklimmt einen Berg.\nGoogle - Summer of Code # Dieses Jahr veranstaltet Google den 22. Summer of Code (GSoC)1.\nDrei Monate lang arbeiten Teilnehmende unter Anleitung erfahrener Mentoren an echten Projekten, für viele der erste echte Berührungspunkt mit Open Source.\nMan kann bei einer erfolgreichen Teilnahme sogar eine Art Stipendium (ich würde es eher Aufwandsentschädigung nennen) bekommen.2\nAnfang Februar hat Google die Liste der teilnehmenden Organisationen veröffentlicht, darunter OpenSUSE, Gnome, FreeBSD, GNU Project, Debian und viele mehr.\nDie Bewerbungsphase für Contributor startet am 16. März 2026 - wenn du Lust hast mitzumachen, lohnt sich ein Blick in die Projektliste 3.\nMeine Meinung # Ich finde das Format großartig, gerade weil es Menschen ohne Vorkenntnisse einen echten Einstieg ermöglicht. Und vielleicht sorgt es dafür, dass ein paar mehr Leute merken, auf wie vielen unverzichtbaren Open-Source-Projekten unser aller Alltag eigentlich aufbaut — oft ohne dass wir es wissen.\nLinux hat auch ohne Linus eine Zukunft # Das Linux Kernel Projekt hat in seinem Maintainer-Handbuch einen neuen Schlachtplan veröffentlicht, wie zu verfahren ist, sollte der betreuende Maintainer des Mainline-Repositorys, die Rolle nicht mehr erfüllen können oder wollen.\nIn diesem Fall wird innerhalb von 72 Stunden von dem Organisator des letzten Maintainer Summits oder dem aktuellen Vorsitzenden der Linux Foundation ein Meeting einberufen, um eine Nachfolgelösung zu finden.\nInnerhalb von zwei Wochen wird das Ergebnis dann per Mailingliste an die gesamte Community verteilt.\nKein rein theoretisches Szenario — 2018 hat Torvalds bereits eine kurze Auszeit genommen, in der Greg Kroah-Hartman das Release von Linux 4.19 übernommen hat. Ein echter Nachfolger auf Dauer ist jedoch eine ganz andere Frage.\nMeine Meinung # Ich finde es gut, dass dieses Thema offen angegangen wird, da es in der Community schon seit Jahren ein Gefühl der Unsicherheit gibt, was mit dem Kernelprojekt passiert, sollte Linus Torvalds mal nicht mehr können oder wollen.\nIch denke aber auch, dass trotz dieses Notfallplans nicht alle Unsicherheiten ausgeräumt sind — nur die Zeit wird zeigen, was im Ernstfall passiert. Dennoch hoffe ich, dass Linus Torvalds uns noch lange erhalten bleibt.\nImmerhin hat er dem Linux Kernel vor ca. 35 Jahren Leben eingehaucht und ist seither der Benevolent Dictator for Life (BDFL)4.\nGentoo ist jetzt auch auf dem Codeberg # Am 16. Februar hat Gentoo auf Planet Gentoo5 bekanntgegeben, dass das Projekt nun einen Repository-Mirror auf Codeberg6 betreibt — und dort auch Contributions eingereicht werden können.\nGentoo plant, sich sukzessive von GitHub zu lösen — GitHub versuche seine Nutzer zunehmend zur Nutzung von Copilot zu drängen, so Gentoo in ihrem Jahresrückblick 2025.7\nWillkommen auf dem (Code-)Berg, Gentoo.\nMeine Meinung # Ich finde es gut, dass sich Organisationen wie Gentoo gegen den (KI-)Zwang großer Firmen wehren und diese nachvollziehbaren Konsequenzen daraus ziehen — das stärkt Plattformen wie Codeberg enorm, was wiederum der gesamten Open-Source-Welt zugutekommt.\nWarum ich selbst eines meiner Projekte von Codeberg zu Gitlab umgezogen habe, könnt ihr im Abschnitt Umzug von Codeberg zu GitLab nachlesen.\nZen Browser wächst so schnell wie kein anderer # In einer neuen Github Statistik, veröffentlicht am 18. Februar 2026, ist der Zen Browser auf Platz 1 in der Kategorie \u0026ldquo;Das am schnellsten wachsende Open-Source-Projekt, gemessen an der Anzahl von Contributor\u0026rdquo;.\nDer Zen Browser basiert auf Firefox, hat jedoch einige deutliche Veränderungen im Bereich der GUI vorgenommen, unter anderem vertikale Tabs, Tabs-Kacheln und die sogenannten Zen Mods. Diese mutigen Neuerungen im eher konservativen Browser-Bereich kommen bei vielen Nutzern gut an.\nDer rasante Zuwachs könnte darauf zurückzuführen sein, dass der Browser Arc keine Weiterentwicklung mehr erfährt. Hinzu kommt, dass Firefox im vergangenen Jahr mit negativen Schlagzeilen zu kämpfen hatte — unter anderem die Kontroverse um die geänderten Nutzungsbedingungen, in denen das Versprechen gestrichen wurde, Nutzerdaten niemals zu verkaufen.\nMeine Meinung # Ich nutze den Zen Browser als Alternative zum Firefox und mag besonders die vertikalen Tabs, die Datenschutzversprechen und die schnelle Entwicklung neuer Funktionen und Bugfixes.\nGenau diese Art Open-Source-Projekt zeigt, dass man auch auf einem hart umkämpften Markt noch etwas Neues schaffen und aus einer Nische heraus eine Erfolgsgeschichte schreiben kann.\nPersönliches # Umzug von Codeberg zu GitLab # Mitte letzter Woche habe ich meine Webseite von Codeberg nach GitLab umgezogen — Codeberg Pages sind noch nicht ganz so ausgereift, und die Downtime ist spürbar höher.\nFür meine privaten Open-Source-Projekte bleibt Codeberg trotzdem die erste Wahl — der Umzug war pragmatisch und kein Abschied.\nVorschaubild # Erstellt mit ChatGPT\nGoogle Summer of Code\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nContributor Stipendien for 2026\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nTeilnehmende Orgnisationen beim GSoC\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nBenevolent Dictator for Life\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nPlanet Gentoo - Gentoo on Codeberg\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGentoo Repository auf Codeberg\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n2025 in retrospect \u0026amp; happy new year 2026!\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"25 Februar 2026","externalUrl":null,"permalink":"/posts/source/summer-zen-mountains/","section":"Posts","summary":"Was haben der Sommer, Zen und ein Berg gemeinsam? Finde es heraus im Quelltext #2 mit den Neuigkeiten aus der Open-Source-Welt die mich diese Woche bewegt haben.","title":"Quelltext #2 - Sommer, Zen und Berge","type":"posts"},{"content":"","date":"25 Februar 2026","externalUrl":null,"permalink":"/tags/zen-browser/","section":"Tags","summary":"","title":"Zen Browser","type":"tags"},{"content":"","date":"23 Februar 2026","externalUrl":null,"permalink":"/categories/community/","section":"Categories","summary":"","title":"Community","type":"categories"},{"content":"","date":"23 Februar 2026","externalUrl":null,"permalink":"/tags/community/","section":"Tags","summary":"","title":"Community","type":"tags"},{"content":"","date":"23 Februar 2026","externalUrl":null,"permalink":"/tags/contribution/","section":"Tags","summary":"","title":"Contribution","type":"tags"},{"content":"","date":"23 Februar 2026","externalUrl":null,"permalink":"/tags/foss/","section":"Tags","summary":"","title":"FOSS","type":"tags"},{"content":"Während du diesen Artikel gerade liest, nutzt du Open-Source Software, vielleicht sogar ohne es zu wissen. Der Browser auf deinem Bildschirm, das Betriebssystem deines Handys, der Router zuhause, der Server auf dem diese Seite liegt – sie alle stehen auf den Schultern von Millionen Zeilen frei verfügbarem Code.\nUnd doch steckt hinter diesem Code oft kein großes Unternehmen, sondern eine Handvoll Menschen, die abends nach der Arbeit Issues beantworten, Bugs fixen und Releases bauen. Freiwillig, unbezahlt, einfach weil sie es für wichtig halten.\nWas viele nicht wissen, du musst kein Entwickler sein, um einen Unterschied zu machen.\nStell dir vor, du nutzt eine App und stolperst über einen Fehler. Du schreibst eine kurze, klare Fehlermeldung, Schritt für Schritt, was passiert ist. Für dich sind das fünf Minuten Arbeit, für den Maintainer ist es jedoch unbezahlbar.\nWas bedeutet das für dich # Issues schreiben # Issues schreiben ist vielleicht der am stärksten unterschätzte Beitrag überhaupt. Ein guter Bug Report – mit klaren Schritten, Fehlermeldungen und Systeminformationen – kann einem Entwickler Stunden an Rätselraten ersparen. Du brauchst dafür kein technisches Wissen, nur Geduld und ein gutes Auge.\nDokumentation verbessern # Dokumentation verbessern ist etwas, das fast jeder tun kann – und das so oft vernachlässigt wird. Hast du etwas gefunden, das unklar erklärt war? Schreib es besser. Du warst selbst Anfänger, du weißt wo es hakt.\nÜbersetzen # Übersetzen öffnet Software für Menschen, die kein Englisch sprechen. Plattformen wie Weblate1 machen das besonders einfach, oft reicht ein Browser.\nWerbung machen # Werbung machen klingt groß, ist es aber nicht. Ein Post, eine persönliche Empfehlung an einen Freund, ein Stern auf GitHub, eine Rezension, das hilft Projekten, wahrgenommen zu werden.\nGeld spenden # Geld spenden ist der direkteste Weg. Viele Maintainer haben einen GitHub Sponsors2, Open Collective Account3 oder Buy Me A Coffee4. Auch kleine Beträge summieren sich.\nMitentwickeln # Und wenn du doch Entwickler bist?\nAuch hier gilt, du bist in der Minderheit derer, die sich tatsächlich einbringen.\nSuch dir ein Projekt, das dich interessiert und dessen Programmiersprache du beherrscht. Niemand erwartet perfekten Code beim ersten Beitrag – ein kleiner Fix, ein aufgeräumter Test, eine verbesserte Fehlermeldung.\nDas zählt alles.\nWie findest du solche Projekte # Die meisten Open Source Projekte leben auf GitHub5, GitLab6 oder Codeberg7. Such einfach nach Software, die du bereits nutzt – und schau ob es offene Issues gibt.\nWer gezielt einen Einstieg sucht, findet auf Good First Issues und First Timers Only kuratierte Listen mit Aufgaben, die explizit für Neulinge gedacht sind.\nStarte jetzt gleich # Was wäre, wenn du heute einfach mal anfängst? Ein Issue. Eine Übersetzung. Ein Stern. Eine Rezension. Fünf Minuten. Das ist alles, was es braucht.\nAn die Unternehmen # Viele Unternehmen bauen ihr gesamtes Geschäftsmodell auf Open Source Software – und geben nichts zurück. Keine Patches, kein Geld, keine Arbeitszeit. Das ist legal, aber es ist nicht fair. Wenn du in so einem Unternehmen arbeitest: Bring das Thema zur Sprache. GitHub Sponsors, ein bezahlter Hacktag im Monat, ein offizieller Contribution-Prozess – das sind keine großen Forderungen.\nVorschaubild # \u0026ldquo;Tux\u0026rdquo; wurde ursprünglich von Larry Ewing erstellt.\nDas verwendete Bild stammt von BAMCAT und ist unter CC BY-NC 2.0 lizenziert.\nWeblate.org\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGithub Sponsors\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nOpen Collective\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nBuy Me a Coffee\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGitHub\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nGitLab\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nCodeberg\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"23 Februar 2026","externalUrl":null,"permalink":"/posts/open-source-needs-help/","section":"Posts","summary":"Open Source Software steckt in fast allem, was wir täglich nutzen. Doch hinter den Projekten steckt meist eine erschreckend kleine Gruppe von Freiwilligen. Du kannst das ändern.","title":"Tux und Co. brauchen dich","type":"posts"},{"content":"","date":"18 Februar 2026","externalUrl":null,"permalink":"/tags/cosmic-desktop/","section":"Tags","summary":"","title":"Cosmic Desktop","type":"tags"},{"content":"","date":"18 Februar 2026","externalUrl":null,"permalink":"/tags/datenschutz/","section":"Tags","summary":"","title":"Datenschutz","type":"tags"},{"content":"","date":"18 Februar 2026","externalUrl":null,"permalink":"/tags/discord/","section":"Tags","summary":"","title":"Discord","type":"tags"},{"content":"","date":"18 Februar 2026","externalUrl":null,"permalink":"/tags/filen/","section":"Tags","summary":"","title":"Filen","type":"tags"},{"content":"","date":"18 Februar 2026","externalUrl":null,"permalink":"/tags/flathub/","section":"Tags","summary":"","title":"Flathub","type":"tags"},{"content":"","date":"18 Februar 2026","externalUrl":null,"permalink":"/tags/game-engine/","section":"Tags","summary":"","title":"Game Engine","type":"tags"},{"content":"","date":"18 Februar 2026","externalUrl":null,"permalink":"/tags/gaming/","section":"Tags","summary":"","title":"Gaming","type":"tags"},{"content":"","date":"18 Februar 2026","externalUrl":null,"permalink":"/tags/go/","section":"Tags","summary":"","title":"Go","type":"tags"},{"content":"","date":"18 Februar 2026","externalUrl":null,"permalink":"/tags/godot/","section":"Tags","summary":"","title":"Godot","type":"tags"},{"content":" Worum geht es in dieser Serie # Es gibt jede Woche mehr interessante Entwicklungen in der Open-Source-Welt, als ich in einem Artikel unterbringen könnte – aber ich versuche es trotzdem. In dieser Serie fasse ich zusammen, was mich in der jeweiligen Woche beschäftigt hat: neue Releases, kontroverse Entscheidungen, Trends, die sich langsam abzeichnen.\nDer Blickwinkel ist immer mein eigener – subjektiv, manchmal meinungsstark, aber immer neugierig. Wer einen nüchternen Newsfeed sucht, wird woanders besser bedient. Wer wissen will, was einen Linux-affinen Entwickler gerade umtreibt, ist hier richtig.\nDen Namen Quelltext habe ich gewählt, weil er für mich zwei Dinge auf einmal beschreibt: die Welt, über die ich schreibe – Software, Code, Open Source – und das, was diese Serie sein soll: verlässliche Informationen, aber auch ein Einblick in das, was diese Themen in mir auslösen.\nCosmic Desktop - Epoch 2 \u0026amp; 3 Roadmap vorgestellt # System 76 haben ihre Roadmap für den Cosmic Desktop1 der nächsten 12 - 18 Monate vorgestellt. Der Cosmic Desktop ist als Rolling Release geplant, daher sollen fertiggestellte Features wochenweise verteilt werden.\nHighlights - Epoch 2 # Bereich Änderungen Performance \u0026amp; Rendering Reaktives Rendering (60–80 % weniger CPU), neuer Vulkan Renderer, Gaming‑Optimierungen Desktop \u0026amp; Workflow libcosmic‑Rewrite, IME, Animationen, Hot Reloading, Time‑Travel Debugging, Clipboard‑Manager, COSMIC Sync Look \u0026amp; Feel Live Wallpapers, neue Shortcuts, Accessibility‑Upgrades Highlights - Epoch 3 # Bereich Änderungen Animationen \u0026amp; Workspace Flüssigere Workspace‑Übergänge, verbesserter App‑Launcher, Feinschliff bei Animationen Display \u0026amp; Input HDR, Night Light, Gamepad‑Support, Touchpad‑Gesten, Session Restore Theming Neues Theming‑System, Shader‑Anpassungen, automatisches Theme‑Matching Apps Verbesserungen an COSMIC Files, Store, Player und Edit; Flatpak‑Permissions‑GUI; Fingerprint‑Support Meine Meinung # Das Linux-Ökosystem lebt von Vielfalt – und Cosmic ist dafür ein besonders spannendes Beispiel: modern, durchdacht, und noch mitten in der Entwicklung.\nSeit einigen Wochen nutze ich Cosmic selbst als täglichen Treiber und kenne seine aktuellen Schwächen daher aus erster Hand.\nUmso gespannter bin ich auf das, was die Roadmap verspricht. Ganz oben auf meiner persönlichen Wunschliste stehen die Performance-Verbesserungen: 60–80 % weniger CPU-Last, das ist bei einem so jungen Projekt sicherlich nicht ungewöhnlich und doch wäre das ein riesiger Sprung.\nDazu kommt der Clipboard-Manager, dessen Fehlen mich im Alltag doch etwas stört, und die Verbesserungen an COSMIC Files, das durchaus noch einige Features vermissen lässt.\nFür mein Setup freue ich mich außerdem auf den Vulkan Renderer, der nochmal bessere Performance verspricht, vor allem für AMD Grafikkarten. Und zu guter Letzt Night Light, was ich unter KDE immer gerne genutzt habe.\nGo 1.26 Release # Go 1.262 bringt eine Mischung aus Sprachverbesserungen, Performance‑Upgrades und neuen Tools – und einige davon werden den Alltag vieler Entwickler spürbar verändern.\nGo 1.26 – Highlights # Bereich Änderungen Sprache new() akzeptiert Ausdrücke; Generics erlauben selbstreferenzierende Type‑Parameter Performance Green Tea GC standardmäßig aktiv; 30 % weniger cgo‑Overhead; mehr Stack‑Allokationen Tools Neues go fix mit Modernizers; Inline‑Analyzer; neue Crypto‑Pakete (hpke, mlkem, cryptotest) Meine Meinung # Technisch am interessantesten finde ich den „Green Tea\u0026quot; Garbage Collector. Die Kernidee – seitenweise statt objektweise arbeiten – klingt simpel, aber der offizielle Blogartikel der Go-Entwickler zeigt, wie viel Arbeit dahinter steckt: von den Microarchitektur-Problemen des klassischen Mark-Sweep-Algorithmus bis hin zur AVX-512-Vektorisierung.\nWer sich für die Details interessiert, dem empfehle ich einen Blick in The Green Tea Garbage Collector.\nGefreut hat mich auch das neue go fix. Automatische Code-Migrationen klingen unspektakulär, sind aber für größere oder langlebige Projekte ein richtig nützliches Feature.\nGodot Engine 4.6 Release # Godot 4.6 ist erschienen3 – und das Release-Motto \u0026ldquo;It’s all about your flow\u0026rdquo; trifft es gut. Es geht weniger um neue Kernfeatures als viel mehr um \u0026ldquo;Quality-of-Life‑Features\u0026rdquo;.\nGodot 4.6 – Highlights # Bereich Änderungen Editor \u0026amp; Workflow Neues Docking‑System, floatbare Panels, Modern Theme, Drag‑and‑hover Tab‑Switching, klickbare Fehlermeldungen Physics Jolt Physics als Standard für neue 3D‑Projekte Rendering \u0026amp; Animation SSR‑Overhaul, neues IK‑Framework (TwoBoneIK, FABRIK, CCDIK) Architektur LibGodot als einbettbare Library; Unique Node IDs für robustere Refactorings Meine Meinung # Ich verfolge Godot seit Jahren und nutze es regelmäßig für kleine Projekte. Genau deshalb freue ich mich über die großartige Arbeit, die das Team und die Community hier leistet.\nDas neue Docking-System ist so ein Fall. Wer viel im Editor arbeitet, kennt das: Man arrangiert seine Panels, öffnet ein neues Fenster, und plötzlich ist alles verschoben. Floatbare Panels klingen unspektakulär, sind aber ein echter Qualitätsgewinn.\nDazu kommt das neue „Modern\u0026quot; Theme, nach Jahren mit dem gleichen Editor-Look ist das eine willkommene Auffrischung. Ein Interface, das gut aussieht, macht für mich tatsächlich einen Unterschied: Man verbringt viel Zeit darin und ein aufgeräumtes, modernes Design senkt unterschwellig die kognitive Last.\nFilen – Änderung bei kostenlosen Accounts # Filen, der datenschutzorientierte Cloud-Speicher, führt eine Änderung bei der Registrierung neuer kostenloser Accounts ein.\nWas ändert sich # Neue Accounts erhalten die kostenlosen 10 GB nur noch, wenn die Registrierungs-IP wie ein normaler Consumer-Anschluss aussieht. VPN-Nutzer können weiterhin einen Account erstellen, starten aber ohne freien Speicher – es sei denn, sie upgraden. Bestehende Accounts sind nicht betroffen.\nWarum # Filen begründet den Schritt mit einem starken Anstieg von Missbrauch: automatisierte Massenaccounts, kriminelle Nutzung und VPN-basierte Multi-Accounting-Netzwerke haben das Ausmaß erreicht, wo es den Dienst und reguläre Nutzer spürbar belastet. Abuse-Reports, Reputationsrisiken und DNS-Blocklisten wie Quad9 sind die konkreten Folgen.\nMeine Meinung # Ich finde die Entscheidung nachvollziehbar. Filen positioniert sich als Privacy-First-Dienst und genau das macht den Missbrauch durch VPN-Netzwerke so attraktiv. Filen steht vor der Wahl, entweder den Dienst gefährden oder gezielt eingreifen.\nDie Lösung ist ein Kompromiss, aber ein fairer. VPN-Nutzer werden nicht ausgesperrt, sie verlieren nur den automatischen Anspruch auf kostenlosen Speicher. Wer Filen ernsthaft nutzen möchte, kann das weiterhin mit oder ohne VPN.\nFlathub-Trends: Auf der Suche nach Discord-Alternativen # Die aktuellen Flathub-Trends zeigen einen auffälligen Schwerpunkt: Revolt (jetzt Stoat), Element, FluffyChat, Cinny und sogar TeamSpeak tauchen prominent auf – alles Messenger und Kommunikationsplattformen, die als Discord-Alternativen gehandelt werden. Das kommt nicht von ungefähr.\nDiscord hat kürzlich einschneidende Änderungen angekündigt, die in einigen Ländern bereits umgesetzt werden. Ab März sollen alle Nutzer standardmäßig als „Teen\u0026quot; eingestuft werden, mit entsprechend eingeschränkten Funktionen. Wer nachweisen möchte, dass er volljährig ist, muss sich per Ausweis verifizieren.\nDas wirft berechtigte Fragen auf. Discord ist kein Dienst, der für Transparenz oder Datenschutz bekannt ist und die Datenleaks der letzten Jahre liegen noch nicht lange zurück. Die Kombination aus Ausweispflicht und einer Plattform mit fragwürdiger Sicherheitsbilanz ist für viele Nutzer schwer zu akzeptieren.\nVielleicht ist genau das der Moment, um offene Alternativen ernsthafter zu testen. Die Flathub-Zahlen legen nahe, dass einige Nutzer damit bereits losgelegt haben.\nSchluss # Das war die erste Ausgabe von Quelltext. Was die nächste Woche bringt, weiß ich noch nicht, aber die Open Source Welt ist immer in Bewegung und so bin ich mir sicher, dass es auch nächste Woche wieder Interessantes zu berichten gibt.\nQuellenangaben # Vorschaubild: Erstellt mit ChatGPT https://blog.system76.com/post/cosmic-epoch-2-and-3-roadmap\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nhttps://go.dev/blog/go1.26\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nhttps://godotengine.org/releases/4.6/\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"18 Februar 2026","externalUrl":null,"permalink":"/posts/source/green-tea/","section":"Posts","summary":"Von einem neuen Garbage Collector in Go bis zu Discord-Flucht auf Flathub: Was mich in den letzten Wochen in der Open-Source-Welt beschäftigt hat.","title":"Quelltext #1 - Grüner Tee \u0026 Discord-Exodus","type":"posts"},{"content":"","date":"18 Februar 2026","externalUrl":null,"permalink":"/tags/retrospektive/","section":"Tags","summary":"","title":"Retrospektive","type":"tags"},{"content":"","date":"17 Februar 2026","externalUrl":null,"permalink":"/tags/buch/","section":"Tags","summary":"","title":"Buch","type":"tags"},{"content":"","date":"17 Februar 2026","externalUrl":null,"permalink":"/tags/creative-coding/","section":"Tags","summary":"","title":"Creative-Coding","type":"tags"},{"content":"Quick Facts:\nAutor: Daniel Shiffman Veröffentlichung: 3. September 2024 (zweite Edition) Umfang: ca. 500 Seiten Format: Online frei verfügbar + Printversion Zielgruppe: Programmierer, Artists Link: natureofcode.com ISBN-10: 1718503709 ISBN-13: 978-1718503700 Worum geht es? # Daniel Shiffman beschreibt sein Buch in der Einleitung wie folgt:\n\u0026hellip; exploring the unpredictable evolutionary and emergent properties of nature in software via the creative coding framework Processing \u0026hellip;\nDaniel Shiffman\nSinngemäß: Das Buch erforscht, wie emergente und evolutionäre Phänomene aus der Natur durch Code lebendig gemacht werden können – umgesetzt mit dem Creative-Coding-Framework Processing.\nKonkret bedeutet das: Du lernst, wie Schwerkraft, Schwärme, Fraktale, zelluläre Automaten und andere natürliche Systeme programmiert werden.\nFür wen ist das Buch? # Ideal für:\nCreative Coder, die ihre Arbeiten mit echten Naturphänomenen anreichern möchten Entwickler, die Mathematik und Physik endlich verstehen statt nur auswendig lernen wollen Studierende, die generative Kunst, Simulationen oder Game-Physics interessant finden Alle, die bei The Coding Train auf YouTube hängengeblieben sind (über diesen Kanal wird es vermutlich nochmal einen separaten Empfehlungsartikel geben) Du solltest mitbringen:\nGrundkenntnisse in JavaScript oder einer ähnlichen Programmiersprache Neugierde auf Mathematik und Physik (Vorkenntnisse nicht nötig!) Lust, Code auszuprobieren und zu experimentieren Eher nicht geeignet, wenn:\nDu noch nie programmiert hast Du trockene, akademische Lehrbücher bevorzugst Was behandelt das Buch? # The Nature of Code ist in elf Kapitel gegliedert, die aufeinander aufbauen, aber auch einzeln gelesen werden können.\nTeil 1 - Unbelebte Objekte # 0 - Zufall - Verschieden Arten von Zufall\n1 - Vektoren – Die Grundlage für Bewegung und Position im Raum\n2 - Kräfte – Gravitation, Reibung, Wind und wie Objekte darauf reagieren\n3 - Oszillation – Pendel, Wellen und trigonometrische Bewegungen\n4 - Partikelsysteme – Feuer, Rauch, Regen und andere Effekte\nTeil 2 - Es lebt # 5 - Autonome Agenten – Wie Objekte Entscheidungen treffen und sich verhalten\n6 - Physik-Engines – Integration von Box2D für realistische Kollisionen\n7 - Zelluläre Automaten – Conway\u0026rsquo;s Game of Life und ähnliche Systeme\n8 - Fraktale – Selbstähnliche Muster und rekursive Strukturen\nTeil 3 - Intelligenz # 9 - Evolutionäre Algorithmen – Genetische Algorithmen und künstliche Selektion\n10 - Neuronale Netze – Grundlagen von Machine Learning\n11 - Neuroevolution - Wie neuronale Netze durch Evolution lernen\nJedes Kapitel erklärt die mathematischen Grundlagen, zeigt lauffähigen Code (in p5.js/JavaScript) und bietet Übungen zum Experimentieren. Alle Beispiele sind online interaktiv verfügbar.\nWarum lohnt sich das Buch? # Drei Gründe, warum ich dieses Buch jedem empfehle:\n1. Es verändert, wie du Mathematik siehst\nPlötzlich sind Vektoren keine abstrakten Pfeile mehr, sondern Bewegung. Sinus und Cosinus werden zu Wellen. Matrizen zu Transformationen. Du verstehst statt nur anzuwenden.\n2. Daniel Shiffman ist ein Ausnahme-Lehrer\nSeine Begeisterung ist ansteckend. Er erklärt nicht nur was, sondern warum. Jedes Kapitel fühlt sich an wie eine spannende Entdeckungsreise, nicht wie trockener Unterricht.\n3. Es ist ein Türöffner\nDie Techniken aus dem Buch brauchst du überall: Spieleentwicklung, Datenvisualisierung, Simulationen, generative Kunst, Machine Learning. Es ist eine Investition, die sich vielfach auszahlt.\nZusatz: Es kostet nichts, alle Beispiele sind interaktiv, und die Community ist riesig und hilfsbereit.\nWie liest man es am besten? # Daniel Shiffman gibt in der Einleitung eine klare Empfehlung. Behandle das Buch wie einen Lehrplan und arbeite es über mehrere Wochen hinweg durch.\nBesondere Betonung liegt auf durcharbeiten, nicht nur lesen! Die Code Beispiele solltest du abtippen, erweitern und damit experimentieren.\nManche Kapitel schaffst du locker in einer Woche, für andere solltest du dir mehr Zeit lassen – je nachdem, wie tief du einsteigen möchtest.\nZum Programmieren nutzt du am besten den Browser und p5.js.\nWenn du zusätzlich Videos zum Lernen möchtest, kannst du dir Daniels Kanal The Coding Train auf Youtube anschauen. Hier gibt es alle Kapitel nochmal in Videoform und viele Erweiterungen zu den einzelnen Themen.\nVerfügbarkeit # Das Buch ist online kostenlos verfügbar direkt auf der Seite von The Nature of Code oder zum selbst erstellen unter Github.\nZudem kann man es als Printausgabe bestellen. Ich habe meine Version beispielsweise bei Thalia bestellt.\nEs ist außerdem bei no starch press erhältlich, in Deutschland allerdings nicht versandkostenfrei.\nPersönliches Highlight # Mein persönliches Highlight, ist das Kapitel 9 über die evolutionären Systeme. Es zeigt, wie man mit relativ wenig Code sehr mächtige und intelligent wirkende Programme realisieren kann.\nAußerdem ist die Art und Weise wie Daniel das Wissen vermittelt einmalig. Man spürt wie viel Spaß ihm die Materie aber auch das Unterrichten macht.\nZum Schluss # The Nature of Code ist ein Buch, das man nicht einfach liest, sondern man erlebt es. Jedes Kapitel öffnet neue Türen und zeigt, wie viel Schönheit in Mathematik und Code steckt.\nDinge die nach Chaos aussehen, können einfachen Regeln folgen und genau das macht die Faszination für dieses Buch aus.\nMein Tipp für den Einstieg:\nLies Kapitel 1-3 der Reihe nach, für die wichtigsten Grundlagen Spring dann zu den Themen, die dich am meisten interessieren Experimentiere und baue eigene Projekte Hinter Daniel Shiffman steht eine große, freundliche und hilfsbereite Community, also trau dich ruhig Fragen zu stellen.\nIch wünsche dir viel Freude beim Programmieren, ich hatte und habe sie noch heute mit dem Buch.\nQuellenangaben # Vorschaubild: freepik Zitat \u0026ldquo;Worum geht es?\u0026rdquo;: The Nature of Code ","date":"17 Februar 2026","externalUrl":null,"permalink":"/posts/recommendations/nature-of-code/","section":"Posts","summary":"The Nature of Code von Daniel Shiffman verwandelt abstrakte Mathematik in sichtbaren, lebendigen Code.","title":"Empfehlungen: The Nature of Code","type":"posts"},{"content":"","date":"17 Februar 2026","externalUrl":null,"permalink":"/categories/mathematik/","section":"Categories","summary":"","title":"Mathematik","type":"categories"},{"content":"","date":"17 Februar 2026","externalUrl":null,"permalink":"/tags/mathematik/","section":"Tags","summary":"","title":"Mathematik","type":"tags"},{"content":"","date":"17 Februar 2026","externalUrl":null,"permalink":"/tags/physik/","section":"Tags","summary":"","title":"Physik","type":"tags"},{"content":"","date":"17 Februar 2026","externalUrl":null,"permalink":"/tags/programmieren/","section":"Tags","summary":"","title":"Programmieren","type":"tags"},{"content":"","date":"17 Februar 2026","externalUrl":null,"permalink":"/categories/selbststudium/","section":"Categories","summary":"","title":"Selbststudium","type":"categories"},{"content":"","date":"14 Februar 2026","externalUrl":null,"permalink":"/tags/autorit%C3%A4t/","section":"Tags","summary":"","title":"Autorität","type":"tags"},{"content":" Autorität vs. Expertise: Der strukturelle Unterschied # Autorität verschiebt den Fokus auf die Person # Ein Senior, der Autorität ausübt, verschiebt den Fokus seines Arguments auf die Person – in diesem Fall auf seine eigene Person. Seine Aussage wird nicht mehr am Inhalt gemessen, sondern an seiner gehobenen Stellung.\nDas machen wir so, weil ich 15 Jahre Erfahrung habe und du erst ein Jahr.\nHäufig klingt es subtiler:\nAus meiner Erfahrung sollten wir das so machen. Ich habe das in vielen Projekten gesehen.\nDoch die Struktur bleibt dieselbe:\nWo sind die konkreten Gründe? Welche Projekte, welche Kontexte, was genau ist passiert?\nDieses Beispiel zeigt, der Inhalt spielt keine Rolle mehr, denn die Begründung ist die Position.\nDas epistemische Problem # Sobald die Person zur Begründung wird, ist Kritik nicht mehr möglich.\nWer die Aussage anzweifelt, zweifelt die Person an – und das ist in hierarchischen Strukturen riskant oder gar verboten.\nDamit wird ein logischer Kurzschluss erzeugt:\nDie Aussage ist richtig, weil sie von der richtigen Person kommt.\nDas Argument entzieht sich der Prüfung. Es wird unkritisierbar und somit epistemisch wertlos.\nAutorität entkoppelt Aussage und Begründung # In einem funktionierenden Erkenntnisprozess werden Aussagen durch Gründe gestützt, diese Gründe bleiben kritisierbar, und Kritik ist möglich, ohne Sanktionen zu riskieren.\nAutorität unterbricht diesen Zusammenhang:\nDie Aussage wird nicht mehr durch Gründe gestützt, sondern durch Rang – aber Rang ist kein Argument.\nSelbst wenn die Aussage zufällig korrekt ist, bleibt sie epistemisch schwach, denn ihre Richtigkeit wurde nicht geprüft, sondern angenommen.\nExpertise gibt Erfahrung wieder – mit Argumenten # Expertise verweist auf Erfahrung, stützt sie mit Argumenten und lässt Raum für Kritik, ohne sich auf ihre Stellung zu berufen.\nBeispiel:\nIch würde hier auf Microservices verzichten, weil ich in den letzten drei Projekten gesehen habe, dass der Overhead bei dieser Teamgröße nicht lohnt. Aber wenn ihr andere Faktoren seht, diskutieren wir das.\nDer Fokus bleibt auf dem Inhalt, da die Erfahrung ein Argument unter anderen ist und nicht das letzte Wort.\nDas epistemische Potential: Die Aussage bleibt prüfbar und sie kann ergänzt, korrigiert oder widerlegt werden.\nWissen entsteht durch Diskussion, nicht durch Gehorsam.\nDer entscheidende Unterschied # Autorität behauptet Gewissheit und verlangt Zustimmung. Sie ersetzt Begründung durch Position und entzieht sich der Prüfung.\nExpertise dagegen bleibt reversibel. Sie zeigt, wie man zu einer Einschätzung gelangt ist, und lädt andere ein, diese Schritte nachzuvollziehen – und zu kritisieren.\nAutorität schließt Diskussion. Expertise eröffnet sie.\nErkenntnis im Team-Kontext # Erkenntnis in einem Softwareentwicklungs-Team ist kein endgültiges Ergebnis, sondern ein Prozess, der mehrere Ebenen umfasst:\nDer Prozess des Prüfens und Diskutierens # Dort, wo Ideen aufeinander treffen, beginnt Erkenntnis. Ein Vorschlag wird gemacht, hinterfragt, verteidigt, verworfen oder verfeinert. Dieser Prozess ist kein unerwünschtes Beiwerk, er ist die Erkenntnis. Ohne Diskussion gibt es nur Meinungen. Erst die kritische Auseinandersetzung macht aus Meinungen geprüftes Wissen.\nGemeinsames Verstehen eines Problems # Aus dem Prozess entsteht Verständnis – aber nicht als individuelle Einsicht, sondern als geteiltes Wissen. Das Team versteht nicht nur was das Problem ist, sondern warum es ein Problem ist, wo es herkommt und welche Faktoren eine Rolle spielen. Dieses gemeinsame Verstehen ist mehr als die Summe einzelner Perspektiven. Es entsteht durch den Abgleich verschiedener Blickwinkel.\nEine Lösung, die sich bewährt # Das Verstehen mündet in Handlung – eine Lösung wird entwickelt und umgesetzt. Doch erst die Bewährung in der Praxis zeigt, ob das Verständnis richtig war.\nDie Bewährung (oder das Scheitern) wird wieder zum Ausgangspunkt neuer Diskussionen, neuen Verstehens, neuer Lösungen.\nKritikoffenheit # Auch eine bewährte Lösung muss immer offen sein, sich Kritik zu stellen. Das heißt nicht, dass man endlos diskutiert. Es heißt, dass jede Lösung offen für Revision bleibt – akzeptiert, aber nicht unantastbar.\nKritikoffenheit schließt den Kreislauf: Sie führt zurück zum Diskutieren und Prüfen – nicht als Wiederholung, sondern als Weiterentwicklung.\nErkenntnis ist ein Zyklus # Diese vier Ebenen lassen sich nicht klar voneinander trennen; sie sind ineinander verschränkt.\nErkenntnis ist dieser Kreislauf, denn sie ist weder das Verstehen, noch die Lösung, noch die Diskussion allein, sie ist die Bewegung zwischen ihnen.\nUnd deshalb ist Autorität so problematisch:\nSie stoppt diese Bewegung und unterbricht den Zyklus, indem sie die Diskussion abbricht (\u0026ldquo;Das ist so, weil ich es sage\u0026rdquo;), das gemeinsame Verstehen verhindert (nur einer \u0026ldquo;versteht\u0026rdquo; wirklich) und Lösungen aufzwingt, statt sie zu erarbeiten. Autorität stoppt Erkenntnis, Kritik hält sie in Bewegung.\nWarum Autorität Erkenntnis strukturell verhindert # Die epistemischen Probleme der Autorität gehen über einzelne Situationen hinaus, denn sie sind strukturell.\nAutorität erzeugt epistemische Asymmetrie # Wo Autorität herrscht, entsteht ein Ungleichgewicht: Der Senior darf irren, ohne hinterfragt zu werden, und der Junior darf nicht hinterfragen, ohne ein Risiko einzugehen.\nDamit wird Kritik selektiv – doch selektive Kritik ist keine Kritik, sondern Inszenierung.\nErkenntnis braucht symmetrische Fehlbarkeit: Jeder kann sich irren, jeder darf widersprechen.\nOhne diese Symmetrie wird Diskussion zur Formalität.\nAutorität friert Hypothesen ein # Im Team sind Lösungen immer Hypothesen. Wenn jemand sagt: „Diese Architektur wird skalieren\u0026quot;, „Dieses Pattern ist wartbarer\u0026quot; oder „Dieser Test deckt das Risiko ab\u0026quot;, dann sind das keine Wahrheiten, sondern Annahmen, die sich erst in der Praxis bewähren müssen.\nHypothesen müssen überprüfbar bleiben, sonst verwandelt Autorität sie in Dogmen.\nUnd ein Team, das Hypothesen nicht mehr prüfen darf, lernt nicht mehr, sondern wiederholt nur.\nPhilosophische Einordnung # Die hier formulierte Kritik an Autorität ist keine rein praktische Beobachtung, denn sie steht in einer bestimmten erkenntnistheoretischen Tradition.\nFallibilismus: Niemand besitzt Wahrheit # Der Fallibilismus – prominent vertreten etwa bei Charles S. Peirce und Karl Popper – geht von einer einfachen, aber radikalen Annahme aus:\nWir können uns irren. Immer.\nWissen ist nie endgültig gesichert, es ist immer vorläufig und immer korrigierbar.\nKarl Popper formulierte diesen Gedanken so:\n„Ich kann irren und du kannst recht haben, und wir können uns bemühen, gemeinsam der Wahrheit näher zu kommen.“\nAutorität widerspricht diesem Prinzip, denn sie macht bestimmte Aussagen faktisch unfehlbar – nicht logisch, aber sozial.\nWas nicht kritisiert werden darf, kann auch nicht korrigiert werden.\nErkenntnis als Irrtumskorrektur # Im kritischen Rationalismus ist Erkenntnis ein Prozess: Wir stellen Hypothesen auf und versuchen sie zu widerlegen.\nVoraussetzung: Jede Hypothese muss angreifbar sein.\nAutorität durchbricht diesen Mechanismus, da sie bestimmte Hypothesen gegen Kritik immun macht und das nicht durch bessere Argumente, sondern durch soziale Struktur. Damit wird der Prozess der Irrtumskorrektur verlangsamt oder ganz blockiert.\nAutorität ist epistemisch problematisch, weil sie Falsifikation verhindert.\nHerrschaftsfreier Diskurs als Ideal # Implizit setzt diese Argumentation ein Ideal voraus, das Jürgen Habermas als „herrschaftsfreien Diskurs“ beschrieben hat.\nEin Diskurs ist herrschaftsfrei, wenn Argumente zählen, nicht Positionen, jeder Einwand gehört werden kann und wenn niemand aufgrund seiner Stellung vor Kritik geschützt ist.\nDas bedeutet nicht, dass alle gleich erfahren sind, sondern dass Erfahrung kein Schutzschild gegen Kritik ist.\nÜbertragen auf Software-Teams heißt das konkret:\n\u0026ldquo;Der beste Vorschlag ist der, der der Kritik standhält und nicht der, der von der ranghöchsten Person stammt.\u0026rdquo;\nAutorität verschiebt den Diskurs von der Sachebene auf die Machtebene und sobald Macht Argumente ersetzt, ist der Diskurs nicht mehr frei und somit zum Scheitern verurteilt.\nEine bewusste Begrenzung # Diese Kritik ist primär epistemisch gemeint.\nAutorität kann auch moralisch problematisch sein – etwa wenn sie Menschen entmündigt oder einschüchtert.\nDoch selbst wenn man diese ethische Dimension ausklammert, bleibt das erkenntnistheoretische Problem bestehen.\nWann ist Erfahrung legitim? – Die Grauzonen # Eine Kritik der Autorität darf nicht zur Kritik der Erfahrung werden. Das Problem beginnt nicht dort, wo Erfahrung spricht, sondern dort, wo sie sich der Prüfung entzieht.\nErfahrung als Hypothese # Erfahrung ist epistemisch legitim, wenn sie als Hypothese eingebracht wird, nicht als Gesetz. Wenn jemand sagt: „In den letzten Projekten ist uns das mehrmals um die Ohren geflogen – deshalb vermute ich, dass wir hier vorsichtig sein sollten\u0026quot;, dann beansprucht diese Aussage kein Gehorchen, sondern liefert Kontext.\nSie bleibt angreifbar:\nIst die Situation wirklich vergleichbar? Haben sich Rahmenbedingungen geändert? Gab es damals andere Ursachen, die hier nicht gelten?\nErfahrung wird so nicht zum Machtinstrument, sondern zu einem Argument mit empirischem Hintergrund – und entfaltet so ihr epistemisches Potential.\nEntscheidung ist nicht gleich Autorität # In realen Teams müssen Entscheidungen getroffen werden – Diskurs kann nicht endlos sein, Zeit ist begrenzt. Eine Führungskraft darf entscheiden – das gehört zur Verantwortung.\nEine Entscheidung ist nur dann autoritär im problematischen Sinne, wenn sie sich der Begründung entzieht.\nEs ist ein Unterschied zwischen: „Wir entscheiden uns für X. Hier sind die Gründe. Wenn wir falsch liegen, lernen wir daraus\u0026quot; – und: „Wir machen X. Diskussion beendet.\u0026quot; Das erste ist verantwortliche, begründende Führung, das zweite Autoritär und epistemisch immunisierend.\nAutorität beginnt dort, wo Begründung durch Position ersetzt wird, nicht dort, wo Verantwortung übernommen wird.\nGeschwindigkeit als versteckte Autorität # Eine subtile Grauzone entsteht unter Zeitdruck.\n„Dafür haben wir jetzt keine Zeit\u0026quot;, „Das müssen wir einfach machen\u0026quot; – solche Sätze können auf realen Zwängen beruhen, aber sie können auch zur Ausrede werden, Kritik zu umgehen.\nSchnelligkeit ist kein epistemisches Argument.\nManchmal ist es rational, eine Entscheidung unter Unsicherheit zu treffen, ohne jede Hypothese bis ins Letzte zu prüfen. Doch auch dann sollte klar sein: Diese Entscheidung ist temporär, eine pragmatische Setzung, keine endgültige Wahrheit.\nWo Zeitdruck immer wieder Kritik ersetzt bzw. unterdrückt, wo er zur Routine statt zur Ausnahme wird, entsteht schleichend Autorität.\nExpertise kann kippen # Auch Expertise selbst ist nicht immun gegen Verhärtung.\nWer oft recht hatte, gewöhnt sich daran, recht zu haben und wer selten widersprochen wird, verlernt zuzuhören. So kann Expertise unmerklich und schleichend in Autorität übergehen.\nWenn die eigene Einschätzung sich nicht mehr wie eine Hypothese anfühlt, sondern wie eine Tatsache, kippt Expertise in Autorität.\nDeshalb braucht selbst die kompetenteste Person eine Umgebung, in der Widerspruch normal ist. Nicht, weil sie inkompetent wäre, sondern weil sie fehlbar ist, wie jeder andere auch.\nDer entscheidende Maßstab # Der entscheidende Maßstab in jeder Form von Zusammenarbeit lautet nicht: Wer hat die meiste Erfahrung, wer trägt die größte Verantwortung, wer trifft am Ende die Entscheidung.\nDie eigentliche Frage ist einfacher und zugleich viel anspruchsvoller: Bleibt das Gesagte kritisierbar?\nSolange Erfahrung begründet statt befohlen wird, solange Entscheidungen erklärbar und revisierbar bleiben, solange Widerspruch möglich ist, ohne Sanktionen zu riskieren, liegt keine problematische Autorität vor. Dann entsteht ein Raum, in dem Argumente zählen und nicht Positionen.\nWie man Kritik zur Normalität macht # Wenn Autorität Erkenntnis blockiert, dann ist die entscheidende Frage nicht ausschließlich theoretisch, sondern lässt sich praktisch adressieren. Das ist nicht immer leicht, jedoch absolut erstrebenswert.\nDie Frage ist nun, Wie schafft man eine Kultur, in der Kritik normal ist?\nEine gesunde Fehlerkultur, könnte man sagen.\nKritik entsteht nicht aus dem luftleeren Raum, sie muss ermöglicht und vorgelebt werden.\nAls Senior oder Führungskraft # Besonders die Erfahrenen im Team tragen Verantwortung.\nBegründungen statt Anweisungen # Wer Begründungen gibt, schafft Offenheit und Anweisungen engen ein.\nStatt zu sagen: „Das ist der richtige Weg“, wirkt es konstruktiver, die eigene Position transparent zu machen. So könnte man stattdessen sagen: „Ich tendiere zu X, weil ich Y beobachtet habe. Welche Risiken seht ihr?“.\nWer Gründe teilt, lädt andere ein, mitzudenken und mitzudiskutieren. Wer hingegen Anweisungen gibt, schließt diesen Raum und begrenzt die gemeinsame Suche nach besseren Lösungen.\nEigene Fehlbarkeit sichtbar machen # Sätze wie „Da lag ich falsch“, „Das habe ich übersehen“ oder „Guter Einwand“ wirken unscheinbar, doch sie tragen eine enorme Kraft. Nichts stärkt eine Diskurskultur mehr als sichtbare Fehlbarkeit. Wer nie irrt, wird irgendwann nicht mehr hinterfragt – und wer nicht mehr hinterfragt wird, hört auf zu lernen.\nAktiv um Widerspruch bitten # Widerspruch entsteht nicht von selbst, schon gar nicht in hierarchischen Strukturen. Erst Fragen wie „Wer sieht das anders?“, „Was spricht gegen diesen Ansatz?“ oder „Welche Annahmen könnten falsch sein?“ öffnen den Raum dafür. Sie machen deutlich, dass Kritik kein Angriff ist, sondern ein notwendiger Teil der gemeinsamen Arbeit.\nAls Kritiker # Auch als Kritiker – gerade als Junior – trägt man Verantwortung, denn Offenheit allein genügt nicht.\nDas Kritisieren selbst ist eine Kunst, die gelernt sein will und die jeder bereit sein sollte zu lernen.\nHier gilt: Fragen statt Vorwürfe, Alternativen statt Destruktion.\nStrukturelle Maßnahmen # Kultur entsteht nicht aus wohlmeinenden Absichten allein, sondern aus den Strukturen, die ein Team sich erarbeitet.\nCode Reviews, in denen Begründungen erwartet werden;\nArchitekturentscheidungen, deren Annahmen sichtbar festgehalten sind;\nRetrospektiven, in denen auch Senior-Entscheidungen zur Disposition stehen;\nEntscheidungsprotokolle, die offenbleiben für Revisionen – all das schafft einen Rahmen, in dem Kritik nicht an Personen haftet.\nDiese und ähnliche Mechanismen entpersonalisieren den Widerspruch. Sie machen ihn erwartbar, regelhaft, fast schon selbstverständlich – und dadurch verliert er seine Bedrohlichkeit.\nKritik als Normalzustand # Kritik ist in einer reifen Teamkultur kein Ausnahmezustand, sondern der Normalfall. Sie signalisiert weder Konflikt noch Misstrauen und schon gar keine Respektlosigkeit.\nGanz im Gegenteil ist sie die Methode, mit der ein Team lernt, seine Arbeit verfeinert und schließlich auch wächst.\nZum Schluss # Autorität wirkt effizient – sie verkürzt Diskussionen und beschleunigt Entscheidungen. Doch wo Aussagen gelten, weil sie von der richtigen Person stammen, hören wir auf zu prüfen. Hypothesen verhärten sich zu Dogmen, und Dogmen lernen nicht mehr.\nKritik wirkt langsamer, mühsamer, konfliktanfälliger. Ein Team, das Kritik zulässt, stellt Fragen, wo andere schon Antworten haben.\nDas wird oft als Schwäche missverstanden.\nDoch hier liegt die Stärke: Nicht im Zweifel selbst, sondern in dem, was er ermöglicht – Kritisierbarkeit, Korrigierbarkeit, Verbesserbarkeit.\nEin Team, das nicht widerspricht, arbeitet nicht effizienter. Es arbeitet epistemisch blind.\nQuellenangaben # Vorschaubild: Erstellt mit Bing ","date":"14 Februar 2026","externalUrl":null,"permalink":"/posts/authority-knowledge/","section":"Posts","summary":"Eine erkenntnistheoretische Analyse, wie Autorität in Teams den Lernprozess blockiert und warum Kritikoffenheit epistemisch notwendig ist.","title":"Autorität: Eine erkenntnistheoretische Kritik","type":"posts"},{"content":"","date":"14 Februar 2026","externalUrl":null,"permalink":"/tags/engineering-kultur/","section":"Tags","summary":"","title":"Engineering-Kultur","type":"tags"},{"content":"","date":"14 Februar 2026","externalUrl":null,"permalink":"/tags/erkenntnistheorie/","section":"Tags","summary":"","title":"Erkenntnistheorie","type":"tags"},{"content":"","date":"14 Februar 2026","externalUrl":null,"permalink":"/categories/essay/","section":"Categories","summary":"","title":"Essay","type":"categories"},{"content":"","date":"14 Februar 2026","externalUrl":null,"permalink":"/tags/falibilismus/","section":"Tags","summary":"","title":"Falibilismus","type":"tags"},{"content":"","date":"14 Februar 2026","externalUrl":null,"permalink":"/tags/kritischer-rationalismus/","section":"Tags","summary":"","title":"Kritischer-Rationalismus","type":"tags"},{"content":"","date":"14 Februar 2026","externalUrl":null,"permalink":"/tags/kritisches-denken/","section":"Tags","summary":"","title":"Kritisches-Denken","type":"tags"},{"content":"","date":"14 Februar 2026","externalUrl":null,"permalink":"/tags/leadership/","section":"Tags","summary":"","title":"Leadership","type":"tags"},{"content":"","date":"14 Februar 2026","externalUrl":null,"permalink":"/categories/theorie/","section":"Categories","summary":"","title":"Theorie","type":"categories"},{"content":"","date":"9 Februar 2026","externalUrl":null,"permalink":"/tags/branching-strategy/","section":"Tags","summary":"","title":"Branching-Strategy","type":"tags"},{"content":"","date":"9 Februar 2026","externalUrl":null,"permalink":"/tags/ci-cd/","section":"Tags","summary":"","title":"CI-CD","type":"tags"},{"content":"","date":"9 Februar 2026","externalUrl":null,"permalink":"/tags/code-review/","section":"Tags","summary":"","title":"Code-Review","type":"tags"},{"content":"","date":"9 Februar 2026","externalUrl":null,"permalink":"/categories/devops/","section":"Categories","summary":"","title":"DevOps","type":"categories"},{"content":"","date":"9 Februar 2026","externalUrl":null,"permalink":"/tags/devops/","section":"Tags","summary":"","title":"DevOps","type":"tags"},{"content":"","date":"9 Februar 2026","externalUrl":null,"permalink":"/tags/git/","section":"Tags","summary":"","title":"Git","type":"tags"},{"content":"Moderne Softwareentwicklung benötigt klare, reproduzierbare und teamtaugliche Prozesse. Gerade kleine und mittlere Teams profitieren von einem Workflow, der Stabilität gewährleistet, ohne unnötige Komplexität einzuführen.\nDer folgende Git‑Workflow hat sich in realen Projekten bewährt und ist darauf ausgelegt, Qualität, Transparenz und Deployment‑Sicherheit sicherzustellen.\nKein Overhead, keine unnötigen Sonderregeln, aber klare Leitlinien für ein professionelles Arbeiten.\nZielsetzung # Der Workflow verfolgt das Ziel, einen stabilen, nachvollziehbaren und automatisierbaren Entwicklungsprozess zu etablieren.\nEr sorgt dafür, dass:\nCodequalität gesichert ist, weil Reviews, Tests und CI‑Checks verpflichtend sind. Deployments reproduzierbar bleiben, da jeder Schritt dokumentiert und automatisiert ist. Feature‑Entwicklung und Release‑Management getrennt voneinander stattfinden, was Risiken reduziert. Teams effizient arbeiten, weil der Prozess klar strukturiert ist und keine unnötigen Entscheidungen erfordert. Damit eignet sich der Workflow besonders für Teams, die Wert auf Stabilität legen, aber nicht in komplexe Git‑Flow‑Varianten abgleiten möchten.\nPermanente Branch‑Struktur # Der Prozess basiert auf drei dauerhaften Branches, die klar definierte Rollen haben:\nmain – stabiler Integrationsbranch für getesteten, reviewten Code. Er repräsentiert den aktuellen Entwicklungsstand, der jederzeit deploybar ist. staging – dient als QA‑, UAT‑ und Integrationsumgebung. Hier wird geprüft, ob der Code nicht nur technisch, sondern auch fachlich korrekt funktioniert. production – enthält ausschließlich den Code, der live im Produktivsystem läuft. Diese Struktur vermeidet unnötige Branch‑Hierarchien: Entwicklung auf main, Validierung auf staging, Live-Betrieb auf production.\nBranch Policies # Auf allen permanenten Branches gelten verbindliche Richtlinien, die die Qualität und Nachvollziehbarkeit sichern:\nPull Requests sind verpflichtend – kein Code gelangt ohne Review in einen permanenten Branch. Direkte Pushes sind verboten – verhindert unkontrollierte Änderungen und schützt die Stabilität. Mindestens ein Reviewer – fördert Wissenstransfer und reduziert Fehler. Erfolgreiche Build‑Pipeline – verhindert, dass fehlerhafter Code integriert wird. Verlinkung eines Work Items – stellt sicher, dass jede Änderung einen fachlichen oder technischen Kontext hat. Conventional Commits1 – sorgen für konsistente Commit‑Nachrichten und erleichtern Release Notes, Changelogs und Automatisierung. Diese Kombination aus Policies mag auf den ersten Blick streng erscheinen, doch genau das schafft die Grundlage für professionelles Arbeiten. Sie verhindert nicht nur technische Fehler, sondern etabliert eine Kultur der gemeinsamen Verantwortung: Code wird nicht mehr isoliert geschrieben, sondern im Team validiert. Die Verknüpfung mit Work Items stellt sicher, dass keine \u0026ldquo;Geisteränderungen\u0026rdquo; entstehen, deren Zweck später niemand mehr nachvollziehen kann. Und Conventional Commits machen aus der Versionshistorie ein maschinenlesbares Protokoll, das automatisierte Prozesse erst möglich macht.\nFeature‑Branches # Die eigentliche Entwicklung findet ausschließlich auf kurzlebigen (wenige Tage) Branches statt:\nfeature/* – neue Features fix/* – kleinere Fehlerbehebungen hotfix/* – dringende Korrekturen für staging oder production Die Basis ist immer main, um sicherzustellen, dass neue Arbeit auf dem aktuellen Stand beginnt.\nIn der Praxis bedeutet das: Ein Feature-Branch wird erstellt, sobald die Arbeit an einem Work Item beginnt, und gelöscht, sobald der Code in main gemerged wurde. Die Benennung folgt einem klaren Muster: feature/WORKITEM-123-kurze-beschreibung macht auf einen Blick deutlich, worum es geht. Feature-Branches sollten klein bleiben: maximal 3-5 Tage, besser kürzer. Das minimiert Merge-Konflikte und hält Reviews handhabbar. Ein Branch, der wochenlang existiert, ist ein Warnsignal: Entweder ist das Work Item zu groß geschnitten, oder es fehlt an Priorisierung.\nKurzlebige Branches reduzieren nicht nur technische Risiken, sondern fördern auch einen kontinuierlichen Entwicklungsrhythmus. Wer täglich kleine, abgeschlossene Änderungen integriert, vermeidet die gefürchteten \u0026ldquo;Mega-Merges\u0026rdquo; am Ende eines Sprints.\nMerge‑Request‑Flow # Der Merge-Prozess ist das Herzstück des Workflows. Er verbindet menschliche Kontrolle mit automatisierter Qualitätssicherung und stellt sicher, dass main jederzeit stabil bleibt.\nDer Ablauf ist schlank:\nFeature‑Branch von main erstellen Entwicklung und Push → CI führt Build und Tests aus Pull Request in Richtung main Pipeline muss erfolgreich sein Code Review Merge in main Dieser Flow mag simpel erscheinen, doch seine Stärke liegt in der Konsequenz: Kein Schritt kann übersprungen werden. Die CI-Pipeline fungiert als erster Filter – schlägt der Build fehl oder brechen Tests, wird der Pull Request nicht einmal zur Review freigegeben. Das spart den Reviewern Zeit und verhindert, dass offensichtlich fehlerhafter Code diskutiert werden muss.\nDas Code Review selbst ist nicht nur eine technische Kontrolle, sondern auch ein Moment des Wissenstransfers. Reviewer lernen neue Codebereiche kennen, Entwickler erhalten Feedback zu ihrem Ansatz, und das Team entwickelt ein gemeinsames Verständnis von Qualität. Nach dem Merge ist der Feature-Branch obsolet und wird gelöscht – main bleibt damit übersichtlich und frei von Altlasten.\nStaging‑Phase # Nach dem Merge in main erfolgt automatisch ein Merge oder Deployment nach staging. Diese Umgebung dient als realitätsnahe Testfläche und bildet den letzten Schritt vor der Produktion.\nWas genau in staging validiert wird, hängt von den Ressourcen und Anforderungen des Teams ab. In formalen Enterprise-Umgebungen können das umfangreiche QA-Prozesse sein, in kleineren Teams reicht oft manuelles Testing durch Entwickler oder Stakeholder. Entscheidend ist: Staging ist der Ort, an dem Code unter produktionsnahen Bedingungen geprüft wird, bevor er live geht.\nMögliche Validierungsschritte in staging können sein:\nQA‑Tests – technische Validierung durch dediziertes QA-Team Manuelles Testing – Entwickler oder Product Owner testen selbst UAT – fachliche Abnahme durch Stakeholder Integrationstests – Zusammenspiel verschiedener Komponenten Smoke Tests – grundlegende Funktionstests nach Deployment Abnahmen – finale Freigaben für das Release (falls erforderlich) Staging ist mehr als nur eine Testumgebung – es ist der Ort, an dem Code zum ersten Mal unter realistischen Bedingungen beweisen muss, dass er funktioniert. Anders als lokale Entwicklungsumgebungen oder isolierte CI-Systeme bildet Staging die Produktionsinfrastruktur so genau wie möglich nach: gleiche Datenbanken (anonymisiert), gleiche Services, gleiche Netzwerk-Konfigurationen. Fehler, die hier auftreten, wären in der Produktion katastrophal – hier sind sie lehrreich und korrigierbar.\nDie Staging-Phase fungiert damit als Sicherheitsnetz, das verhindert, dass ungetesteter oder unvollständig geprüfter Code in die Produktion gelangt. Sie gibt dem Team die Gewissheit, dass das, was released wird, tatsächlich funktioniert.\nFreigabeprozess: staging → production # Der Übergang in die Produktion ist der kritischste Moment im gesamten Workflow. Hier entscheidet sich, ob Wochen oder Monate Entwicklungsarbeit reibungslos live gehen – oder ob ein Release zurückgerollt werden muss, weil etwas übersehen wurde.\nDeshalb ist dieser Prozess bewusst streng geregelt. Ziel ist ein kontrollierter, nachvollziehbarer und weitestgehend automatisierter Release‑Prozess, der Risiken minimiert und Transparenz schafft. Jeder Schritt ist dokumentiert, jede Freigabe ist nachvollziehbar, und kein Deployment erfolgt ohne explizite Bestätigung.\nFreigabevoraussetzungen (Release Gates) # Bevor Code in die Produktion gelangen kann, müssen zentrale Gates erfüllt sein. Diese Gates sind keine bürokratischen Hürden, sondern Schutzmaßnahmen, die verhindern, dass unfertige, fehlerhafte oder riskante Änderungen live gehen.\nDie folgenden Gates sind Beispiele für einen formalen Release-Prozess. Nicht jedes Team benötigt alle vier Gates in dieser Ausprägung. Ein kleineres Team ohne dedizierte QA-Abteilung kann die QA-Freigabe durch \u0026ldquo;erfolgreiche manuelle Tests durch Entwickler\u0026rdquo; ersetzen. Ein Startup ohne Product Owner kann UAT durch \u0026ldquo;fachliche Prüfung im Team\u0026rdquo; ersetzen.\nEntscheidend ist das Prinzip: Bevor Code in production geht, muss er nachweislich funktionieren – technisch und fachlich. Wie formalisiert dieser Nachweis erfolgt, richtet sich nach den Anforderungen des Projekts.\n1. QA‑Freigabe (Beispiel für formalen Prozess) # alle Testfälle im Release‑Scope erfolgreich keine offenen Bugs mit Severity2 1 oder 2 abgeschlossene Regressionstests Alternative für kleinere Teams: Erfolgreiche manuelle Tests durch Entwickler, dokumentiert als Checklist oder im PR-Kommentar.\nDie QA‑Freigabe stellt sicher, dass der Code technisch stabil ist und keine bekannten kritischen Fehler enthält.\n2. UAT‑Freigabe (Beispiel für formalen Prozess) # fachliche Abnahme aller relevanten Work Items dokumentierte Zustimmung des Product Owners Alternative für kleinere Teams: Kurzes Testing durch einen fachlichen Stakeholder oder Tech Lead, Freigabe per Slack/E-Mail.\nDamit wird bestätigt, dass der Code fachlich korrekt ist und den Anforderungen entspricht. Technisch perfekter Code ist wertlos, wenn er nicht das tut, was die Nutzer brauchen.\n3. Technische Checks (sollten immer automatisiert sein) # erfolgreiche End‑to‑End‑Tests Security‑Scans ohne kritische Findings erfolgreiche Build‑Pipeline keine Merge‑Konflikte zwischen staging und production Diese Checks sollten in jedem Setup vorhanden sein, da sie automatisiert ablaufen.\nDiese Checks verhindern technische Risiken und stellen sicher, dass der Code sicher und kompatibel ist.\n4. Manuelle Freigabe (immer erforderlich) # ein definierter Verantwortlicher (z. B. Product Owner oder Tech Lead) bestätigt das Release im Environment „production\u0026quot; ohne diese Freigabe erfolgt kein Deployment Auch in kleinen Teams sollte jemand final „OK\u0026quot; sagen – verhindert versehentliche Deployments.\nDieser letzte Schritt ist bewusst manuell gehalten. Auch wenn alle automatisierten Checks bestanden sind, braucht es einen Menschen, der die Gesamtsituation bewertet: Ist jetzt der richtige Zeitpunkt für ein Release? Gibt es externe Faktoren, die dagegen sprechen? Diese finale Kontrolle sorgt für maximale Verantwortlichkeit und verhindert ungewollte Deployments.\nSkalierbarkeit der Gates # Die beschriebenen Release Gates lassen sich an die Größe und Reife des Teams anpassen:\nTeam-Größe QA-Freigabe UAT-Freigabe Technische Checks Manuelle Freigabe Klein (3-5) Entwickler testen selbst Tech Lead prüft fachlich Automatisiert (Pflicht) Tech Lead Mittel (6-15) Rotierende QA-Rolle oder dedizierte QA-Person Product Owner Automatisiert (Pflicht) Product Owner Groß/Enterprise Dediziertes QA-Team mit formalen Testplänen Formale UAT mit Dokumentation Automatisiert + Security/Compliance Release Manager Das Prinzip bleibt gleich: Nichts geht in production, ohne dass es geprüft wurde. Die Formalität der Prüfung skaliert mit den Anforderungen.\nAblauf: staging → production # main → staging erfolgt automatisch nach jedem Merge QA und UAT prüfen den Stand in staging nach erfüllten Gates wird automatisch ein PR von staging → production vorgeschlagen Reviewer prüfen den PR technisch und fachlich nach Freigabe: Build Deployment nach production automatisches Tagging (vX.Y.Z) automatische Release Notes (kurz + lang) Veröffentlichung der Artefakte Dieser Ablauf verbindet Automatisierung mit klaren manuellen Kontrollpunkten. Das Beste aus beiden Welten: Geschwindigkeit durch Automation, Sicherheit durch menschliche Urteilskraft.\nHotfix‑Prozess # Fehler in der Produktion sind unvermeidlich. Entscheidend ist, wie schnell und kontrolliert sie behoben werden können. Der Hotfix-Prozess ist bewusst so gestaltet, dass er Geschwindigkeit ermöglicht, ohne die Stabilität des Workflows zu gefährden.\nBei Fehlern in staging oder production:\nhotfix/*‑Branch von main erstellen Fehler beheben Pull Request → main normaler Flow: main → staging → production Hotfixes werden niemals direkt in staging oder production durchgeführt. Das mag auf den ersten Blick umständlich erscheinen – warum nicht einfach schnell den Fehler in production fixen? – doch dieser Weg führt unweigerlich zu Inkonsistenzen. Ein direkter Fix in production würde bedeuten, dass main und staging plötzlich einen anderen Stand haben. Spätere Merges würden den Fix überschreiben oder zu schwer durchschaubaren Konflikten führen.\nDer beschriebene Prozess stellt sicher, dass alle Umgebungen synchron bleiben und der Hotfix vollständig getestet wird, bevor er live geht. In der Praxis bedeutet das: Selbst dringende Fixes durchlaufen CI, Review und staging – nur eben priorisiert und beschleunigt.\nRelease‑Tags # Nach erfolgreichem Merge in production wird automatisch ein Tag gesetzt:\nFormat: vX.Y.Z Der Tag markiert exakt den Commit, der live ist. Dies ist mehr als nur eine Formalität: Tags sind unveränderliche Markierungen in der Git-Historie, die jederzeit reproduzierbar machen, welcher Code zu welchem Zeitpunkt in der Produktion lief. Bei Incidents ermöglicht das schnelles Debugging (\u0026ldquo;Welcher Code war am 15. März live?\u0026rdquo;), bei Audits liefert es lückenlose Nachvollziehbarkeit, und bei Rollbacks gibt es ein klares Ziel, zu dem zurückgekehrt werden kann.\nDiese Tags folgen der Semantic Versioning Convention (SemVer), die es ermöglicht, auf einen Blick zu erkennen, ob ein Release Breaking Changes, neue Features oder nur Bugfixes enthält.\nRelease‑Automation # Der gesetzte Tag ist nicht das Ende des Prozesses, sondern der Auslöser für die finale Automatisierung. Eine Release‑Pipeline wird gestartet, die alle notwendigen Artefakte erzeugt und dokumentiert:\nArtefakte erzeugt (Binaries, Container-Images, Packages) automatische Release Notes generiert Dokumentation aktualisiert Benachrichtigungen versendet Damit wird jeder Release vollständig dokumentiert und automatisiert ausgeliefert. Was früher manuell zusammengestellt werden musste – Release Notes schreiben, Stakeholder informieren, Artefakte hochladen – geschieht jetzt in Sekunden. Das spart nicht nur Zeit, sondern eliminiert auch menschliche Fehler: keine vergessenen Benachrichtigungen, keine fehlenden Artefakte, keine inkonsistenten Release Notes.\nAutomatische Release Notes (optional KI‑gestützt) # Die Pipeline sammelt:\nWork Items Pull Requests Commits und erzeugt daraus:\neine Kurzfassung für Endnutzer (Was ist neu? Was wurde behoben?) eine Langfassung für technische Stakeholder (Welche Pull Requests? Welche technischen Änderungen?) Optional kann dieser Prozess durch KI-Modelle unterstützt werden, die aus den gesammelten Daten lesbare, kontextuelle Release Notes generieren. Das Ergebnis: Dokumentation, die tatsächlich gelesen wird, weil sie verständlich und relevant ist.\nDies reduziert manuellen Aufwand erheblich und sorgt für konsistente, vollständige Release‑Dokumentation, die nicht mehr davon abhängt, ob jemand daran denkt, sie zu schreiben.\nProzessübersicht # feature/* ↓ (PR, CI, Review) main ↓ (automatisch) staging ↓ (QA, UAT, Gates erfüllt) PR staging → production ↓ (Review, Approval) production ↓ (Deployment erfolgreich) Tag vX.Y.Z ↓ (automatisch) Release-Pipeline → Artefakte → AI Release Notes (kurz + lang) → Dokumentation → Notifications Grenzen und Anwendbarkeit # Ich möchte an dieser Stelle nicht verschweigen, dass auch dieser Workflow nicht für jedes Team und jedes Projekt gleichermaßen geeignet ist. Er entfaltet seine Stärken vor allem in bestimmten Kontexten:\nDieser Workflow passt gut, wenn:\ndas Team aus 3-20 Entwicklern besteht (klein genug für Abstimmung, groß genug, dass Prozesse nötig sind) Stabilität wichtiger ist als maximale Deployment-Geschwindigkeit regulatorische Anforderungen oder Audit-Trails erforderlich sind mehrere Umgebungen (dev, staging, production) existieren das Team bereit ist, in CI/CD-Infrastruktur zu investieren Weniger geeignet für:\nEin- oder Zwei-Personen-Projekte – hier ist der Overhead zu groß Experimentelle Prototypen oder MVPs, bei denen schnelle Iteration wichtiger ist als Stabilität Teams, die mehrmals täglich deployen möchten (Continuous Deployment im engeren Sinne) – der staging-Gate verlangsamt bewusst Anpassbar für verschiedene Team-Größen:\nKleine Teams (3-5 Entwickler) ohne dediziertes QA: Entwickler testen selbst in staging, Tech Lead gibt final frei. Die Release Gates sind vereinfacht, aber das Prinzip bleibt. Mittlere Teams (6-15 Entwickler): QA-Rolle kann rotieren, UAT durch Product Owner oder fachliche Stakeholder. Große Teams/Enterprise: Formale QA-Abteilung, dokumentierte UAT, Compliance-Anforderungen – hier entfaltet der Workflow seine volle Stärke. Trade-offs, die bewusst eingegangen werden:\nGeschwindigkeit vs. Sicherheit: Der Weg von main über staging nach production dauert länger als ein direktes Deployment. Das ist gewollt, kostet aber Zeit. Flexibilität vs. Konsistenz: Keine Ausnahmen zu erlauben (keine direkten Pushes, keine Skip-Reviews) schränkt in Ausnahmesituationen ein. Automatisierung vs. Kontrolle: Manuelle Freigaben verhindern vollständig automatisierte Deployments. Das ist ein bewusster Kontrollpunkt, aber auch ein manueller Eingriff. Wer täglich oder mehrmals täglich deployen möchte, braucht einen anderen Ansatz – etwa Trunk-Based Development mit Feature Flags. Wer hingegen wöchentliche oder zweiwöchentliche Releases fährt und dabei maximale Sicherheit benötigt, findet hier eine solide Grundlage.\nDieser Ansatz lässt sich modifizieren und an andere Anforderungen anpassen.\nFazit # Dieser Git-Workflow verzichtet auf komplexe Branch-Strukturen, langlebige Feature-Branches oder manuelle Deployment-Schritte, wo Automatisierung möglich ist. Gleichzeitig lässt er an den entscheidenden Stellen – Code Review, QA-Freigabe, finales Deployment – keinen Raum für Shortcuts.\nDie Stärke dieses Ansatzes liegt in seiner Klarheit. Jedes Teammitglied weiß zu jedem Zeitpunkt, wo Code steht und welche Schritte als nächstes folgen. Es gibt keine Grauzone, keine Sonderregeln für \u0026ldquo;dringende\u0026rdquo; Änderungen, keine Diskussionen darüber, ob ein Review \u0026ldquo;diesmal\u0026rdquo; ausnahmsweise übersprungen werden kann.\nFür Teams, die Wert auf Stabilität, Nachvollziehbarkeit und Automatisierung legen, bietet dieser Workflow eine gute Grundlage.\nVorschaubild # Erstellt mit ChatGPT\nConventional Commits ist eine Konvention für Commit-Nachrichten mit dem Format type(scope): description. Mehr Details: conventionalcommits.org\u0026#160;\u0026#x21a9;\u0026#xfe0e;\nSeverity klassifiziert den Schweregrad von Bugs: 1 = kritisch (Systemausfall), 2 = schwerwiegend (wichtige Features defekt), 3 = mittel, 4 = niedrig.\u0026#160;\u0026#x21a9;\u0026#xfe0e;\n","date":"9 Februar 2026","externalUrl":null,"permalink":"/posts/gate-based-git-workflow/","section":"Posts","summary":"Ein gate-basierter Git-Workflow mit drei permanenten Branches, skalierbaren Quality Gates und vollständiger CI/CD-Integration – für Teams, die Stabilität ohne GitFlow-Overhead wollen.","title":"Git-Workflow mit skalierbarer Qualitätssicherung","type":"posts"},{"content":"","date":"9 Februar 2026","externalUrl":null,"permalink":"/tags/release-management/","section":"Tags","summary":"","title":"Release-Management","type":"tags"},{"content":"","date":"6 Februar 2026","externalUrl":null,"permalink":"/categories/ausbildung/","section":"Categories","summary":"","title":"Ausbildung","type":"categories"},{"content":"","date":"6 Februar 2026","externalUrl":null,"permalink":"/tags/denkmethoden/","section":"Tags","summary":"","title":"Denkmethoden","type":"tags"},{"content":"Quick Facts:\nHost: Stefan Macke Laufzeit: Seit über 10 Jahren Erscheinungsweise: Mehrmals pro Jahr Zielgruppe: Auszubildende, Studierende, Ausbilder in IT-Berufen Link: it-berufe-podcast.de Worum geht es? # Seit über zehn Jahren begleitet mich der IT-Berufe Podcast.\nStefan Macke behandelt in seinem Podcast alle Themen, die für die Ausbildung in den IT-Berufen wichtig sind – mit leichtem Schwerpunkt auf die Anwendungsentwicklung. Er erklärt, wie man sich bewirbt, was man für den Einstieg benötigt, welche Inhalte prüfungsrelevant sind und vieles mehr.\nFür wen ist der Podcast? # Auszubildende Studierende Quereinsteiger Ausbilder Mentoren Teamleiter Was gibt es zu hören? # Interviews Prüfungstipps Praxisbeispiele Lernstrategien Ausbildungsrecht Soft Skills Warum lohnt sich der Podcast? # Ich bin überzeugt, dass jede Person in der IT‑Ausbildung diesen Podcast hören sollte.\nViel zu oft sitzen Azubis oder Studenten in der Ecke und wissen gar nicht genau, was sie denn jetzt eigentlich lernen sollen. Betreuer wissen oft nicht, welche Themen für ihre Mentees wirklich wichtig sind.\nUnd genau hier kommt der IT-Berufe Podcast von Stefan Macke ins Spiel. Er führt sehr kurzweilig in alle wichtigen Themen ein, so dass man ihm gerne zuhört, auch wenn es mal ein vermeintlich trockenes Thema ist.\nBesonders interessant für Auszubildende dürften die expliziten Folgen zur Prüfungsvorbereitung sein.\nAuch nach so vielen Jahren ist der Podcast für mich eine der zuverlässigsten Quellen, wenn es um gute IT‑Ausbildung geht. Viele der Themen sind zeitlos: \u0026ldquo;Zahlensysteme, Zweierpotenzen und Binärzahlen\u0026rdquo;, \u0026ldquo;Eigenschaften und Unterscheidung von Programmiersprachen\u0026rdquo;, \u0026ldquo;Normalisierung einer Datenbank am konkreten Beispiel\u0026rdquo; und viele mehr.\nViele meiner eigenen Auszubildenden haben durch den Podcast schneller verstanden, wie ihre Ausbildung strukturiert ist und worauf es wirklich ankommt. Aber nicht nur meine Auszubildenden haben viel gelernt – ich ebenso.\nWie hört man ihn am besten? # Der Podcast eignet sich hervorragend für den Arbeitsweg oder während konzentrierter Pausen. Stefan Mackes Erklärungen sind kompakt und durchdacht – man sollte ihm aufmerksam zuhören.\nIch empfehle, früh in der Ausbildung oder im Studium einzusteigen. Die Themen bauen nicht streng aufeinander auf, aber ein grundlegendes Verständnis hilft, die Zusammenhänge besser zu erfassen.\nNoch besser: Notizen machen. Block oder Tablet zur Hand nehmen und mitschreiben – das verdoppelt den Lerneffekt.\nWie aktiv ist der Podcast? # Seit über zehn Jahren erscheinen mehrere Folgen pro Jahr – konstant, zuverlässig und mit hoher Qualität.\nPersönliches Highlight # Es ist schwer, mich auf eins zu beschränken, aber ich würde sagen, dass gerade die Rückblicke auf vergangene Prüfungen und die Folge \u0026ldquo;Aufbau und Ablauf der IHK-Abschlussprüfung in den IT-Berufen\u0026rdquo; besondere Highlights darstellen. Stefan Macke versteht es, den Auszubildenden die Angst vor dem Unbekannten – der Abschlussprüfung – zu nehmen.\nZum Schluss # Gute Ausbildung braucht gute Ressourcen. Dieser Podcast ist eine davon – zuverlässig, praxisnah und das seit über zehn Jahren.\nQuellenangaben # Vorschaubild: freepik ","date":"6 Februar 2026","externalUrl":null,"permalink":"/posts/recommendations/it-berufe-podcast/","section":"Posts","summary":"Seit über zehn Jahren erklärt Stefan Macke im IT-Berufe Podcast, worauf es in der IT-Ausbildung ankommt – unverzichtbar für Azubis, Studierende und Ausbilder.","title":"Empfehlungen: IT-Berufe Podcast","type":"posts"},{"content":"Fallibilismus ist die Grundbedingung für Entwicklung und echter Erkenntnis.\nGewissheit wirkt auf viele Menschen beruhigender als die Einsicht, dass selbst empirisch gut bestätigte Tatsachen nur vorläufig sind. Doch gerade deshalb muss sich jede Überzeugung, so eindeutig sie erscheinen mag, jederzeit der Möglichkeit ihrer Korrektur aussetzen.\nFallibilismus ist jedoch nicht mit blindem Zweifel zu verwechseln. Er fordert keine pauschale Skepsis, sondern eine Haltung, die Kritik zulässt.\nZwischen Skeptizismus und Dogmatismus # Ein ständiger Zweifel ist ebenso gedankenlos wie das blinde Folgen einer vorgegebenen Theorie. Wer an allem und jedem zweifelt, kann sich nicht auf eine tragfähige Erkenntnis hin bewegen. Nehmen wir uns diese Möglichkeit von vornherein, verlieren wir auch die Freude daran, ein Ziel überhaupt zu verfolgen.\nIm Gegenteil - die Wahl einer Theorie ist weder zufällig noch willkürlich, sondern ergibt sich daraus, welche Erklärung der Kritik am besten standhält.\nDogmatismus ist das andere Extrem: Während der Skeptizismus alles infrage stellt, stellt der Dogmatismus nichts infrage. Er hält an Überzeugungen fest, als wären sie unangreifbar, und verschließt sich damit jeder Möglichkeit der Korrektur. So entsteht keine Stabilität, sondern geistige Starre.\nHinter dogmatischen Überzeugungen steht oft ein tiefes Bedürfnis nach Sicherheit. Klare Antworten wirken beruhigend, gerade wenn die Welt komplex und unübersichtlich erscheint. Doch dieser Halt wird teuer erkauft: Wer sich vor Kritik schützt, schützt nicht seine Erkenntnis, sondern nur sein Gefühl der Gewissheit.\nDogmatismus verwechselt Überzeugung mit Wahrheit. Er verhindert, dass Gegenargumente überhaupt in Betracht gezogen werden und eine Theorie überhaupt besser werden kann. Eine Überzeugung, die nicht kritisiert werden kann, kann stabil wirken, jedoch hat sie keinen epistemischen Wert, da sie weder geprüft noch verbessert werden kann.\nWir sehen die Folgen des Dogmatismus überall: in wissenschaftlichen Paradigmen, die zu lange verteidigt wurden; in technischen Systemen, die aus Gewohnheit nicht hinterfragt werden; im Alltag, wenn Menschen an Überzeugungen festhalten, obwohl sie längst widerlegt sind. In all diesen Fällen verhindert Dogmatismus nicht Fehler, er konserviert und intensiviert sie.\nEin historisches Beispiel für Dogmatismus ist das Festhalten am geozentrischen Weltbild trotz gegenteiliger Evidenz.\nWeder der radikale Zweifel noch die starre Gewissheit führen zu Erkenntnis. Fallibilismus entsteht genau zwischen diesen Extremen. Als epistemische Haltung, die Kritik zulässt, ohne an allem zu zweifeln und die Überzeugungen ernst nimmt, ohne sie zu dogmatisieren. Er ist die einzige Position, die Entwicklung nicht nur erlaubt, sondern aktiv ermöglicht.\nFallibilismus als aktive Haltung # Fallibilismus ist keine defensive Haltung, die sich aus Vorsicht oder Unsicherheit speist. Er ist im Kern eine aktive Form des Denkens, die Erkenntnis nicht als Besitz, sondern als fortlaufenden Prozess versteht. Wer falibilistisch denkt, geht nicht davon aus, die Wahrheit bereits gefunden zu haben, sondern bewegt sich auf sie zu. Fehlbarkeit wird dabei nicht als Schwäche begriffen, sondern als Voraussetzung dafür, überhaupt lernen zu können. Nur was korrigierbar ist, kann sich verbessern; nur was offen bleibt, kann wachsen. In diesem Sinne ist Fallibilismus kein Rückzug, sondern ein Vorstoß: die bewusste Entscheidung, Erkenntnis nicht zu verwalten, sondern zu erweitern.\nDie Rolle der Kritik # Kritik ist im falibilistischen Denken kein Angriff, sondern ein Prüfverfahren. Sie dient nicht dazu, Überzeugungen zu zerstören, sondern dazu, sie zu bewähren. Eine Theorie gewinnt ihren Wert nicht durch ihre Unantastbarkeit, sondern durch ihre Belastbarkeit: Sie zeigt ihre Stärke erst dann, wenn sie ernsthafte Einwände übersteht. Kritik macht Überzeugungen nicht schwächer, sondern verlässlicher, weil sie jene Aspekte sichtbar macht, die einer Revision bedürfen. In diesem Sinne ist Kritik kein Hindernis der Erkenntnis, sondern ihr eigentliches Werkzeug. Ohne sie könnten wir nicht unterscheiden, welche unserer Annahmen tragfähig sind und welche nur zufällig Bestand haben.\nVorläufigkeit ohne Beliebigkeit # Vorläufigkeit bedeutet im falibilistischen Denken nicht Beliebigkeit. Eine Theorie verliert nichts an Wert, nur weil sie nicht endgültig ist – ihre Qualität hängt davon ab, wie gut sie sich in der Praxis und gegenüber Kritik behauptet. Verlässlichkeit entsteht nicht durch Unantastbarkeit, sondern durch Bewährung.\nPraktische Dimension # Fallibilismus zeigt seine Stärke nicht nur im Denken, sondern im Handeln.\nAuch in der Wissenschaft zeigt sich diese Haltung besonders deutlich. Sie arbeitet längst nicht mehr mit dem Anspruch, endgültige Gesetze zu formulieren. Der Begriff „Gesetz“ wird heute nur noch aus historischen Gründen verwendet; tatsächlich spricht man von Theorien, die sich bewähren müssen, solange sie der Kritik standhalten. Eine Theorie gilt nicht deshalb, weil sie unantastbar wäre, sondern weil sie sich in unzähligen Prüfungen als tragfähig erwiesen hat. Wissenschaftlicher Fortschritt entsteht nicht durch das Festhalten an vermeintlichen Gewissheiten, sondern durch die Bereitschaft, auch etablierte Modelle zu revidieren, wenn neue Evidenz es verlangt.\nHypothesen werden nicht verehrt, sondern getestet. Experimente dienen nicht dazu, Überzeugungen zu bestätigen, sondern sie zu widerlegen. Fortschritt entsteht dort, wo Fehler sichtbar werden dürfen.\nÄhnlich verhält es sich in der Technik und Softwareentwicklung, wo Iteration, Tests und kontinuierliche Verbesserung nicht Zeichen von Unsicherheit sind, sondern Ausdruck einer reifen Fehlerkultur. Agile Softwareentwicklung ist so ein Beispiel für institutionalisierten Fallibilismus, denn eines der Grundprinzipien der Agilen Softwareentwicklung sagt:\nIn regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.\nAuch im Alltag zeigt sich, wie wertvoll eine falibilistische Haltung ist: Wer bereit ist, Irrtümer einzugestehen und aus ihnen zu lernen, handelt nicht schwächer, sondern klüger. Fallibilismus lähmt nicht — er macht handlungsfähig, weil er uns erlaubt, Entscheidungen zu treffen, ohne absolute Gewissheit zu benötigen.\nEthische Dimension # Fallibilismus ist nicht nur eine epistemische Haltung, sondern auch eine ethische. Wer anerkennt, dass die eigenen Überzeugungen fehlbar sind, übernimmt Verantwortung für sie. Fehler einzugestehen ist dann kein Zeichen von Schwäche, sondern Ausdruck von Integrität. Eine solche Haltung öffnet den Raum für echte Gespräche: für Positionen, die sich begegnen können, ohne sich gegenseitig zu ersticken. Sie verlangt die Bereitschaft, andere Perspektiven ernst zu nehmen, nicht weil jede Meinung gleich viel wert wäre, sondern weil keine Überzeugung über Kritik erhaben ist. In einer Zeit, in der öffentliche Debatten oft von Gewissheitsgesten und moralischer Selbstsicherheit geprägt sind, wirkt Fallibilismus fast wie eine Tugend: Er macht uns nicht nur klüger, sondern auch dialogfähiger.\nSprachphilosophische Dimension # Auch in der Sprachphilosophie zeigt sich die Bedeutung des Fallibilismus. Es macht einen erheblichen Unterschied, ob wir sagen: „Das ist so“ – oder ob wir formulieren: „Meine Theorie deutet darauf hin, dass es so sein könnte.“ Die erste Formulierung schließt ab, sie fixiert Bedeutung und blockiert jede weitere Nachfrage. Die zweite öffnet einen Raum: Sie markiert die eigene Aussage als Deutung, nicht als unumstößliche Tatsache. Diese sprachliche Offenheit ist kein rhetorischer Trick, sondern Ausdruck einer Haltung, die ihre eigenen Begriffe und Kategorien nicht für selbstverständlich hält. Wer so spricht, macht Kritik nicht nur möglich, sondern erleichtert sie. Sprache wird dann nicht zum Werkzeug der Absicherung, sondern zum Medium des gemeinsamen Prüfens. Fallibilismus wirkt damit bis in unsere Ausdrucksformen hinein: Er verändert nicht nur, was wir denken, sondern auch, wie wir es sagen.\nFallibilismus zeigt damit eine Haltung, die weit über die Grenzen der Erkenntnistheorie hinausreicht. Er prägt, wie wir denken, wie wir sprechen und wie wir handeln. Wer anerkennt, dass jede Theorie nur eine Annäherung ist, öffnet sich für Kritik, ohne sich von ihr bedroht zu fühlen. Wer seine Begriffe als verbesserbare Werkzeuge versteht, schafft Raum für Verständigung. Und wer Entscheidungen ohne absolute Gewissheit trifft, handelt nicht vorsichtiger, sondern verantwortlicher. Fallibilismus ist damit keine Einladung zur Beliebigkeit, sondern zur geistigen Beweglichkeit. Er erlaubt uns, Überzeugungen ernst zu nehmen, ohne sie zu verabsolutieren, und Ziele zu verfolgen, ohne die Möglichkeit des Irrtums zu verdrängen. In einer Welt, die sich ständig verändert, ist diese Haltung kein Luxus, sondern eine Notwendigkeit.\nQuellenangaben # Vorschaubild: freepik ","date":"6 Februar 2026","externalUrl":null,"permalink":"/posts/fallibilist-mindset/","section":"Posts","summary":"Fallibilismus als epistemische Grundhaltung zwischen Skeptizismus und Dogmatismus – und ihre Implikationen für Wissenschaft, Praxis, Ethik und Sprache.","title":"Fallibilismus als epistemische Grundhaltung","type":"posts"},{"content":"","date":"6 Februar 2026","externalUrl":null,"permalink":"/tags/fehlbarkeit/","section":"Tags","summary":"","title":"Fehlbarkeit","type":"tags"},{"content":"","date":"6 Februar 2026","externalUrl":null,"permalink":"/tags/it-ausbildung/","section":"Tags","summary":"","title":"IT-Ausbildung","type":"tags"},{"content":"","date":"6 Februar 2026","externalUrl":null,"permalink":"/tags/mentoring/","section":"Tags","summary":"","title":"Mentoring","type":"tags"},{"content":"","date":"6 Februar 2026","externalUrl":null,"permalink":"/tags/podcast/","section":"Tags","summary":"","title":"Podcast","type":"tags"},{"content":"","date":"6 Februar 2026","externalUrl":null,"permalink":"/tags/pr%C3%BCfungsvorbereitung/","section":"Tags","summary":"","title":"Prüfungsvorbereitung","type":"tags"},{"content":"","date":"6 Februar 2026","externalUrl":null,"permalink":"/tags/weiterbildung/","section":"Tags","summary":"","title":"Weiterbildung","type":"tags"},{"content":"","date":"6 Februar 2026","externalUrl":null,"permalink":"/tags/wissenschaftstheorie/","section":"Tags","summary":"","title":"Wissenschaftstheorie","type":"tags"},{"content":"","date":"1 Februar 2026","externalUrl":null,"permalink":"/categories/allgemein/","section":"Categories","summary":"","title":"Allgemein","type":"categories"},{"content":"Wenn du Fragen, Anregungen oder Feedback zu meinen Artikeln hast, freue ich mich über eine Nachricht.\nDu erreichst mich unter:\ncontact [at] devcartes [punkt] de Wofür du mich kontaktieren kannst # Austausch über Softwareentwicklung, Teamkultur oder Philosophie Fragen zu meinen Artikeln oder Serien Hinweise auf Fehler, Ergänzungen oder neue Themen Kooperationen oder Gastbeiträge Ich versuche jede Nachricht zu lesen und antworte, sobald ich kann.\ninfo@example.com admin@fake.de webmaster@notreal.org ","date":"1 Februar 2026","externalUrl":null,"permalink":"/pages/contact/","section":"Pages","summary":"","title":"Kontakt","type":"pages"},{"content":"","date":"1 Februar 2026","externalUrl":null,"permalink":"/tags/meta/","section":"Tags","summary":"","title":"Meta","type":"tags"},{"content":"","date":"1 Februar 2026","externalUrl":null,"permalink":"/pages/","section":"Pages","summary":"","title":"Pages","type":"pages"},{"content":" Wer ich bin # Ich bin Tristan, Senior Software Engineer und Philosophie-Enthusiast.\nIch arbeite seit bald zwei Jahrzehnten in der IT, habe Auszubildende, Studierende und Juniors begleitet und dabei gelernt, wie viel in diesem Beruf von Kommunikation, Fehlerkultur und gesundem Denken abhängt.\nWas mich antreibt # Softwareentwicklung ist für mich mehr als Code.\nSie ist ein Zusammenspiel aus:\nklaren Gedanken guter Zusammenarbeit Mut zum Irrtum Neugier und der Bereitschaft, ständig zu lernen Ich schreibe, weil ich glaube, dass wir als Branche besser werden können – nicht durch mehr Tools, sondern durch mehr Klarheit, Pragmatismus und Menschlichkeit.\nWorum es auf dieser Seite geht # Hier findest du:\nArtikel über technische Systeme Empfehlungen zu Literatur, Podcasts und Medien Essays und Gedanken über Philosophie und ihre Bedeutung für Entwickler Ich schreibe nicht, um Recht zu haben, sondern um zum Denken anzuregen.\nWas ich sonst mache # Wenn ich nicht schreibe oder entwickle, beschäftige ich mich mit Philosophie, lese viel, lerne Neues oder arbeite an kleinen Projekten, die mich neugierig machen.\nWenn du Fragen hast oder dich austauschen möchtest, melde dich gerne.\n","date":"1 Februar 2026","externalUrl":null,"permalink":"/pages/about/","section":"Pages","summary":"","title":"Über mich","type":"pages"},{"content":"","date":"1 Februar 2026","externalUrl":null,"permalink":"/tags/%C3%BCber-diesen-blog/","section":"Tags","summary":"","title":"Über-Diesen-Blog","type":"tags"},{"content":" Wer schreibt # Ich wandere zwischen zwei Welten: der gedanklichen, in der Theorien wachsen, und der praktischen, in der Dinge Form annehmen.\nIch übe mich im Philosophieren, im Entwerfen von Gedankenräumen, im Erkunden des Möglichen. Und zugleich liebe ich das Konkrete. Das Bauen, das Programmieren, das Tüfteln, das Erschaffen – den Moment, in dem eine Idee plötzlich Gestalt annimmt.\nIch bin am ehesten dort zu Hause, wo beide Welten aufeinander treffen.\nWorüber # Ich schreibe über das, was mich beschäftigt: über Systeme – technische wie gedankliche –, über Klarheit, über Irrtümer, über das Staunen, das manchmal zwischen zwei Zeilen auftaucht. Manches wird knapp sein, anderes etwas ausführlicher.\nWarum # Weil Schreiben eine Form des Nachdenkens ist. Weil Gedanken, die nicht festgehalten werden, zu schnell verdampfen.\nWenn du hier etwas findest, das dich begleitet, irritiert oder inspiriert, dann erfüllt dieser Blog seinen Zweck.\nRhythmus # Alle zwei Wochen erscheint ein neuer Artikel – mal ein Essay, mal ein Praxisbericht. Zwischen den Hauptartikeln streue ich manchmal kürzere Stücke ein: Tools, News, Empfehlungen, Gedanken, die keinen langen Atem brauchen.\nWas du nicht findest # Fertige Wahrheiten. Buzzwords, die sich für Gedanken ausgeben. Oder die Illusion, dass Komplexität sich immer auf einen Satz reduzieren lässt.\nWas du findest # Einen Gedanken, der hängen bleibt. Einen Zweifel, der fruchtbar wird. Oder einen Satz, der etwas in dir anstößt, das du schon kanntest, aber noch nicht benannt hattest.\nAußerdem # Kritikoffenheit - ich schreibe nicht aus der Position des Wissenden, sondern aus der des Erkundenden. Fehler gehören dazu, blinde Flecken erst recht.\nWenn dir etwas auffällt – ein Gedanke, der schief steht, ein Argument, das wackelt, ein Satz, der stolpert, freue ich mich über jede Rückmeldung. Dieser Ort lebt davon, dass er sich verändern kann und darf.\nQuellenangaben # Vorschaubild: freepik ","date":"1 Februar 2026","externalUrl":null,"permalink":"/posts/welcome/","section":"Posts","summary":"Willkommen in meiner Gedankenwelt.","title":"Willkommen","type":"posts"}]