Wann hast du erkannt, dass es im technischen Bereich keinen Ausweg gibt?

Dieser Artikel #BCGame @bcgame exklusiv gesponsert

Viele Anfänger, die gerade erst anfangen, einschließlich mir damals, glauben an eine harte Wahrheit: Solange meine Technik beeindruckend genug ist, bin ich unersetzlich.

Deshalb arbeiten wir uns ab. Lernen Java, Go, Rust, lesen Quellcodes, knabbern an Algorithmen, bauen Microservices, nutzen Cloud-Native. Heute tüfteln wir noch an Spring Cloud, morgen müssen wir Service Mesh lernen, übermorgen, wenn große KI-Modelle populär werden, müssen wir schnell Prompt Engineering lernen.

Wir denken, das ist Fortschritt, in Wirklichkeit ist das Cyber-Labern.

Du denkst, du baust eine technische Barriere auf, in Wahrheit hilfst du deinem Chef nur, die Machbarkeit neuer Technologien zu prüfen.

In der Internetbranche veraltet Technik schneller als der Wert deiner Eigentumswohnung fällt. Du hast drei Jahre lang an einem Framework gearbeitet, und dann veröffentlicht Google oder Facebook eine neue Version oder ändert das Architekturkonzept – dein stolz auf das Drachenbezwingen-Wissen wird im Nu zu Papier.

Das bedeutet aber nicht, dass Lernen sinnlos ist, sondern dass dein Lernfokus vielleicht falsch liegt. Statt den Frameworks nachzujagen, die in drei Jahren veralten, solltest du dich auf die fundamentalen Logiken konzentrieren, die sich niemals ändern. Zum Beispiel, während du noch überlegst, ob du Spring Cloud oder K8s benutzt, denken die großen Köpfe über Datenkonsistenz in verteilten Systemen nach. Wenn du aus dem Framework-Kreislauf aussteigen willst, solltest du das Buch „Designing Data-Intensive Applications“ (DDIA) lesen, das als das Backend-Bibel gilt. Es erklärt die Essenz von verteilten Systemen, Datenbanken und Systemdesign. Wenn du das verstanden hast, kannst du morgen, egal welches Framework populär ist, seine Grundprinzipien durchschauen.

Erinnerst du dich an die Jungs, die damals Flash gemacht haben? Oder an die Experten, die für Symbian-Systeme programmiert haben?

Sind sie nicht fleißig? Sind sie nicht klug?

Wenn die Zeit dich verlässt, sagen sie nicht einmal auf Wiedersehen.

Das Schlimmste ist, dass unsere stolze Fähigkeit zum schnellen Lernen eigentlich die Ressource ist, die Kapital am liebsten verschleißt.

Denn je schneller du lernst, desto billiger bist du.

Früher war ein alter TCM-Arzt umso wertvoller, weil Erfahrung nicht kopiert werden kann. Und heute? Ein 35-jähriger Programmierer, der viel verdient, weil er billig ist. Ein 23-jähriger frischgebackener Absolvent, der zwei Handbücher liest, auf Github kopiert und anpasst, kann in einem Monat einsatzbereit sein.

Dann sagst du vielleicht: Ich habe Erfahrung, ich kann Fallstricke vermeiden.

Spinnst du? In den meisten CRUD-Geschäftsszenarien braucht es keine hochkomplexe Technik. Was, wenn dein Code nicht perfekt ist? Dann schaff einfach zwei zusätzliche Server an. Was, wenn es Speicherlecks gibt? Dann starte den Server einfach nachts neu.

Für den Chef zählt nur, dass es läuft.

Dein eleganter Code, deine Designmuster, dein Architekturdenken – im Blick des Chefs sind sie nichts gegen den, der mit ihm zusammen trinkt, große Pläne schmiedet und mit beeindruckenden PPTs glänzt.

Das ist das Prinzip der „schlechten Münzen verdrängen die guten Münzen“.

Wenn du merkst, dass dein halbe Monat intensives Studium des Quellcodes weniger bringt als der Aufstieg des PPT-Engineers im Nachbarteam, der ständig von Empowerment, Keypoints, Closed-Loop, Granularität spricht, dann solltest du aufwachen.

Der größte Kummer eines Technikers ist, dass wir immer zu weit von Geld entfernt sind.

Wir sind die Produktivkraft, aber nicht die Hauptakteure der Produktionsverhältnisse.

Du hast einen genialen Empfehlungsalgorithmus geschrieben, der die Nutzerbindung erhöht. Wem gebührt der Verdienst? Dem Operations-Team, dem Produktteam, ja sogar dem Business-Partner, der die Channel-Kooperation ausgehandelt hat.

Warum?

Weil in der Business-Logik Technik nur ein Werkzeug ist.

Wie beim Hausbau: Du bist der, der Ziegel trägt und Mauern baut. Egal, wie gerade die Mauern sind oder wie schnell die Ziegel kommen, am Ende verdienen die Immobilienentwickler, die Makler oder sogar die Spekulanten, nicht du, der die Ziegel trägt.

Außerdem ist Technik oft der Sündenbock.

Wenn das System abstürzt, musst du die Schuld auf dich nehmen. Wenn die Veröffentlichung verzögert wird, bist du schuld. Bei vielen Bugs bist du schuld.

Aber was ist, wenn das Business nicht läuft?

Der Produktmanager sagt: Ich will auch, aber die Technik unterstützt nicht, diese Funktion lässt sich nicht umsetzen, der Zeitplan ist zu lang.

Siehst du? Ein perfekter geschlossener Kreis.