Der Pike-Effekt: Warum Entwickler oft unter ihrem Niveau arbeiten

Viele Entwickler haben kein Skill-Problem. Sie haben ein Erfahrungsproblem.

Nicht im Sinne von „zu wenig Erfahrung” – sondern: Die falschen Erfahrungen wurden verallgemeinert. Ein kaputtes Setup, ein schlechtes Projekt, ein Tutorial von 2016 – und plötzlich entstehen Regeln im Kopf, die nie wieder hinterfragt werden.

Der Pike-Effekt – aus der Biologie direkt ins Open-Space-Büro

Das Phänomen hat einen Namen. In einem bekannten Experiment wurde ein Hecht mit kleinen Fischen in ein Aquarium gesetzt. Zwischen ihm und den Fischen: eine Glasscheibe. Der Hecht prallte immer wieder dagegen. Irgendwann hörte er auf zu versuchen. Als die Scheibe entfernt wurde, schwammen die kleinen Fische direkt an ihm vorbei. Er rührte sich nicht.

Die Scheibe existierte nicht mehr. Die Überzeugung schon.

In der Softwareentwicklung klingt das dann so:

„Docker ist kompliziert.” – Entstanden nach einem Tutorial von 2014. Auf Windows 7. Mit Docker Toolbox, die schon beim Download ahnte, dass sie keine Zukunft hat. Das Setup lief ungefähr so stabil wie eine Jenga-Runde auf einem fahrenden Bus. Zweiter Versuch: zwei Jahre später, weil der Trend so eindeutig war, dass Ignorieren keine ernsthafte Option mehr schien. Diesmal mit aktuellem Setup, einem konkreten Use Case – und dem Ergebnis, dass Docker tatsächlich funktioniert. Die erste Erfahrung war real. Sie war nur nicht repräsentativ.

„Tailwind ist unleserlich.” – Entstanden nach dem ersten Blick auf einen Div mit 47 Klassen, geschrieben von jemandem, der das Prinzip „utility-first” als Einladung verstanden hatte, alle Utilities auf einmal zu benutzen. Drei Stunden Tailwind-Erfahrung, dokumentiert in einem einzigen Element. Zweiter Versuch: weil Tailwind nicht verschwand, sondern überall auftauchte. Mit einem leeren Projekt, der offiziellen Dokumentation und ohne fremden Code. Das Ergebnis war ein anderes.

„KI-Code ist unbrauchbar.” – Entstanden nach dem ersten Praxistest mit GPT-3, der auf die Frage „Schreib mir eine Login-Funktion” etwas zurückgab, das aussah wie eine Mischung aus PHP 4 und Wunschdenken. Mit einem Kommentar auf Englisch. In einer deutschen Datei. Ohne jegliche Fehlerbehandlung. Dafür mit var.

Die vier Stufen – von Erlebnis zu Identität

Stufe 1: Das Erlebnis

Hier fängt es an. Man probiert etwas, es funktioniert nicht – aus welchen Gründen auch immer. Die Erfahrung ist real. Das Problem: Sie ist zeitgebunden, aber das Gehirn hat kein Ablaufdatum draufgeschrieben.

„Monorepos sind langsam” – auf einem 2017er MacBook Pro, mit einem Webpack-Config, das aus fünf verschiedenen Stack-Overflow-Antworten zusammenkopiert war und dabei so aussah, als wäre es das. Der Build dauerte sechs Minuten. Man konnte in der Zeit Kaffee kochen, trinken und nochmal überlegen, ob man Entwickler werden wollte.

Stufe 2: Die Generalisierung

Aus einem konkreten Erlebnis wird eine universelle Regel. Das Gehirn liebt das – es spart Energie. Leider spart es auch Lernfortschritt.

„Microservices sind overengineered” – nachdem jemand mitbekommen hat, wie ein Team von vier Leuten 23 Services für eine Anwendung mit 300 monatlichen Nutzern betrieben hat, von denen drei aus dem eigenen Unternehmen kamen. Das war kein Microservices-Problem. Das war ein Architektur-Meeting-ohne-Erwachsenenaufsicht-Problem.

Die Beobachtung war korrekt. Der Schluss daraus war es nicht.

Stufe 3: Die Vermeidung

Jetzt wird es teuer. Neue Tools werden gar nicht erst getestet. Bessere Setups ignoriert. Der Stack von 2019 läuft stabil, also bleibt es bei 2019. Neue Technologien werden in Slack-Channels kommentiert, aber nicht ausprobiert.

Das ist kein Faulheitsproblem. Das ist Gehirneffizienz, die sich gegen den Anwender richtet.

Stufe 4: Die Identität

Die härteste Stufe. Die Überzeugung ist keine Meinung mehr – sie ist Persönlichkeitsmerkmal.

„Ich bin kein Frontend-Typ.” „DevOps ist nicht meins.” „KI ist was für Leute, die keinen richtigen Code schreiben wollen.”

Ab hier wird nicht mehr getestet. Ab hier wird verteidigt. Mit Verve, mit Anekdoten, mit Artikeln aus dem Jahr 2021.

Das Gegenmodell: Was die anderen machen

Es gibt Entwickler, bei denen das Muster nicht greift. Was die anders machen, ist weniger aufregend als man erwartet – kein Geheimwissen, kein besonderes Talent. Sie machen im Wesentlichen vier Dinge.

Trigger erkennen, bevor sie als Argumente durchgehen. Wenn die Reaktion auf einen Technologienamen mehr Emotion als Substanz enthält – „Das ist doch wieder so ein Hype” – nehmen sie das als Signal, nicht als Schluss. Typische Formulierungen, die auffallen: „Hab ich probiert.” „Funktioniert in der Praxis nicht.” Gefolgt von keinem einzigen konkreten Beispiel aus den letzten 18 Monaten.

Den Kontext der ursprünglichen Erfahrung datieren. Wann war das genau? Mit welcher Version? Auf welcher Hardware? Ein Bekannter beschreibt TypeScript bis heute als „zu aufwendig” – entstanden bei einer Migration, bei der .js-Dateien einfach in .ts umbenannt wurden, ohne weitere Anpassung, und dann war man überrascht, dass TypeScript 4000 Meinungen zu bestehendem JavaScript hat. Das war keine TypeScript-Erfahrung. Das war eine Migrations-ohne-Plan-Erfahrung.

Kontrolliert neu testen, nicht enthusiastisch. Kein blinder Neustart, kein Zweistunden-Tutorial auf YouTube. Kleiner Scope, modernes Setup, ein konkretes Problem aus der eigenen Arbeit. Ziel: eine neue Referenzerfahrung, die die alte nicht löscht, sondern ergänzt.

Regeln mit Bedingungen versehen. „X funktioniert nicht” ist unbrauchbar. „X funktioniert nicht für Szenario Y, aber sehr gut für Z” ist eine Aussage, mit der man arbeiten kann. Der Unterschied zwischen diesen beiden Sätzen ist messbar – in Technologieentscheidungen, in Gesprächsqualität im nächsten Architektur-Meeting, in der Bereitschaft, das nächste neue Ding überhaupt anzuschauen.

Warum das gerade mit KI so relevant ist

Mit KI-Tools passiert der Pike-Effekt gerade in Echtzeit und im großen Maßstab.

Erste Erfahrungen mit GPT-3: Code, der aussah, als hätte jemand einen erschöpften Junior gebeten, Stack Overflow auf Autopilot zu stellen. Erste Copilot-Versionen: Vorschläge, die irgendwo zwischen „fast richtig” und „selbstsicher falsch” lagen – also die gefährlichste Kategorie.

Viele Entwickler haben ihre Meinung in genau dieser Phase gebildet – und nie wieder aktualisiert. Inzwischen sind mehrere Modellgenerationen vergangen. Aber die Glasscheibe ist geblieben. Man sieht sie nur nicht mehr, weil man nicht mehr hinschaut.

Die, die weitergetestet haben, arbeiten heute anders. Nicht unbedingt besser in jedem Einzelfall – aber mit einem aktuelleren Bild davon, was geht und was nicht. Das ist kein magischer Vorteil. Das ist der Preis einer regelmäßig gewarteten Einschätzung.

Was steckt dahinter – für die, die es genau wissen wollen

Der Pike-Effekt ist eine eingängige Geschichte, aber kein Zufall. Dahinter stecken gut erforschte psychologische Mechanismen, die sich gegenseitig verstärken.

Der Kern ist erlernte Hilflosigkeit: wiederholtes Scheitern führt dazu, dass das Gehirn „ich habe keinen Einfluss” als Regel speichert – und später nicht mehr handelt, obwohl die Situation sich geändert hat. „Dieses Build-System ist kaputt, da kann man nichts machen” ist kein technisches Urteil. Es ist ein gelerntes Nicht-Versuchen.

Darauf setzt Confirmation Bias auf: Man nimmt bevorzugt Informationen wahr, die die bestehende Überzeugung bestätigen. Wer einmal entschieden hat, dass Framework X schlecht ist, merkt sich jeden Bug und übersieht jeden Vorteil. Die Überzeugung ernährt sich selbst.

Die dritte Schicht ist Status-quo-Bias: Menschen bevorzugen den aktuellen Zustand, auch wenn er objektiv schlechter ist. „Never touch a running system” ist manchmal weise. Meistens ist es eine Rationalisierung.

Zusammen ergeben diese drei einen mentalen Lock-in: schlechte Erfahrung schafft Hilflosigkeit, Hilflosigkeit wird durch selektive Wahrnehmung bestätigt, und der Status quo wird zur Norm erklärt. Der Hecht muss die Scheibe nicht mehr sehen – er hat aufgehört, in die Richtung zu schwimmen.

Der Abstand wächst

Zwischen denen, die alte Regeln gelegentlich hinterfragen, und denen, die es nicht tun, wächst ein Abstand – langsam, kaum sichtbar, aber stetig. Irgendwann ist er so groß, dass er sich nicht mehr durch Aufholen schließen lässt, sondern nur noch durch einen Neustart, der schmerzhafter ist als die Wartung es gewesen wäre.

Die Fischchen schwimmen vorbei. Der Hecht merkt es nicht mehr. Er ist inzwischen überzeugt, dass er kein Frontend-Typ ist.