Beim Verlassen von LinkedIn

• Was würdest du wählen, wenn sorgfältige Arbeit und das hohe Tempo eines Unternehmens miteinander kollidieren?
• Die Geschichte des Ingenieurs Chris Krycho, der sich zwischen dem Festhalten an seinen Überzeugungen mit Kompromissen und dem Weggang auf der Suche nach Arbeit im Einklang mit seinen Prinzipien für Letzteres entschied.
• Chris verließ LinkedIn letztlich, um Arbeit zu verfolgen, die seinen eigenen Grundsätzen entsprach.
• Zusammenfassung dessen, was er im Podcast erzählt hat.
• Seine Geschichte betont die Spannung zwischen der „Notwendigkeit von Innovation“ und der „Wichtigkeit der Projekthygiene“.

Chris Krychos erster Tag bei LinkedIn

• Chris kam Ende Januar 2019 zu LinkedIn. Er durchlief verschiedene Onboarding-Prozesse, wie sie in großen Unternehmen oder gesunden kleineren Firmen häufig vorkommen.
• Chris sollte remote aus Colorado arbeiten, verbrachte aber die ersten zwei Wochen mit Onboarding und Zeit mit dem Team.

Millionen von Codezeilen

• Im Vergleich zu seinen Erfahrungen bei früheren Unternehmen war er vom Umfang der Frontend-Client-App und der Backend-Services bei LinkedIn stark überrascht.
• Das LinkedIn-Frontend umfasst 2 Millionen Zeilen Code, deutlich mehr als die gesamte Codebasis seines vorherigen Unternehmens.

Das Infrastruktur-Team

• Chris’ Rolle im Infrastruktur-Team konzentrierte sich nicht auf den Serveraufbau, sondern auf Engineering Enablement bzw. die Verbesserung der Developer Experience.
• Ziel war es, die Arbeit an LinkedIns großer Desktop-App einfacher zu machen.

Modernisierung von JavaScript

• Er arbeitete an der Modernisierung des Codes durch die Einführung von JavaScript-Klassen. Während er Probleme löste, die beim Einsatz des Ember-Frameworks entstanden, lernte er viel.
• Bei Migrationen in einer großen Codebasis müsse so viel wie möglich automatisiert werden; der Arbeitsaufwand sei zu groß, um ihn manuell zu bewältigen.

Einführung von TypeScript

• Um Fehler im Frontend zu reduzieren, fiel die Entscheidung für einen Wechsel zu TypeScript.
• TypeScript lässt sich schrittweise einführen und bietet damit die Skalierbarkeit, die LinkedIn benötigte.

Langsamer Migrationsplan vs. „Finger Gun's Plan“

• Chris und sein Team schlugen einen 3- bis 5-Jahres-Plan vor, um Ember-Code nach React zu migrieren, während ein anderes Team den „Finger Gun's Plan“ präsentierte, der ein komplettes Umdenken und hohes Tempo versprach.
• Dieser Unterschied im Ansatz spiegelte den Konflikt zwischen den Problemen wider, die Chris und sein Team erlebten, und einer Unternehmenskultur, die Geschwindigkeit priorisierte.

Chris’ Erfahrungen und Erkenntnisse

• Er erkannte ein Problem mit unzureichenden Benachrichtigungen.
• Durch steigende Speichernutzung und eine Kettenreaktion von Serverneustarts fielen Server im gesamten Rechenzentrum aus.
• Er versuchte, das Problem durch System-Resets und Anpassungen von Berechtigungen zu lösen.
• Scheitern ist unvermeidlich, und Software Engineering bedeutet, Systeme zu entwerfen, die den Prozess unterstützen, in dem Ingenieure Produktresultate hervorbringen.
• Er betonte die Notwendigkeit von Systemen mit Resilienz auf mehreren Ebenen.

Gegenreaktionen auf den Vorfall

• Während der Problemlösung entstand Unzufriedenheit wegen mangelnden Vertrauens seitens des Managements.
• Es kam zu Meinungsverschiedenheiten mit einem Senior Engineer und zu Kommunikationsproblemen.
• Er betonte, dass ein System nicht nur im Bestzustand funktionieren, sondern in allen Situationen unterstützen können müsse.

Zunehmender Druck

• Trotz der Bemühungen, technische Schulden abzubauen und die Resilienz zu verbessern, wuchs die Unzufriedenheit der Führungsebene.
• Es kam zu Konflikten mit dem Management, das für komplexe Probleme einfache Lösungen verlangte.

Organisatorische Neuaufstellung

• Organisatorische Umstrukturierung und Rollenänderungen durch das „Finger-Guns-Team“.
• Er erkannte neue Erfahrungen und Lernchancen in einer anderen Rolle.

Reflexion und Erkenntnis

• Selbstreflexion durch frühere Erfahrungen und die aktuelle Situation.
• Erkenntnis der Bedeutung von Beziehungsaufbau und Kommunikation.
• Verständnis dafür, dass technische und soziale Probleme miteinander verknüpft sind.

Fazit und Lehren

• Chris behielt eine kritische Sicht auf eine Kultur bei, die Geschwindigkeit zum höchsten Wert erhebt.
• Durch die Reflexion über Karriere und persönliche Werte suchte er nach neuen Möglichkeiten.
• Chris’ Weg auf der Suche nach einer Rolle, in der Engineering Excellence angestrebt wird, geht weiter.

Meinung von GN⁺

• Chris Krychos Erfahrungen zeigen den Konflikt zwischen technischen Prinzipien und geschäftlichen Anforderungen deutlich.
• Seine Entscheidung unterstreicht, wie wichtig es ist, ein Gleichgewicht zwischen persönlichen Werten und beruflichen Entscheidungen zu finden.
• Change Management in einer groß angelegten technischen Umgebung wie bei LinkedIn ist komplex und bietet auch für andere Unternehmen wichtige Lehren.
• Die Einführung von Technologien wie TypeScript kann helfen, die Codequalität zu verbessern und Fehler zu reduzieren, erfordert in großen Codebasen jedoch einen schrittweisen Ansatz.
• Beim Vorantreiben solcher technischen Veränderungen sollte das Gleichgewicht zwischen Developer Experience und der Geschwindigkeit von Produkt-Releases berücksichtigt werden.

[GN⁺]

Hacker-News-Kommentare

• In einem Gespräch mit einem Vorgesetzten habe er gehört: „Du bist idealistisch, misst dem Gewinn nicht genug Bedeutung bei und musst deine Werte ändern.“ Er machte deutlich, dass ihn das abstößt, und bekräftigte seinen Willen, an seinen Überzeugungen festzuhalten. Das sei der interessanteste Teil des Podcasts gewesen, und der Autor habe dadurch den Eindruck gewonnen, dass er wichtiges Feedback absichtlich ignoriert habe. Die Lehre aus der Karriere sei nicht, dass es schwer sei zu wissen, was richtig ist, sondern dass die eigentliche Schwierigkeit darin liege, die gesamte Organisation auf die richtige Lösung auszurichten.

  • Ein Beispiel für einen Wertekonflikt in einem Gespräch mit einem Vorgesetzten
  • Der Eindruck, wichtiges Feedback bewusst ignoriert zu haben
  • Die wichtige Lehre, dass organisatorische Einigkeit über die richtige Lösung entscheidend ist

• 2019 war ich an der Neuschreibung von facebook.com in React beteiligt. Ich kenne die Codebasis oder die Organisation von LinkedIn nicht direkt, habe aber Unternehmen mit ähnlichen Codebasen und Organisationsstrukturen gesehen. Ich unterstütze den „Finger-Gun“-Ansatz, der bei guter Umsetzung positive Ergebnisse bringen kann. Wenn mehrere Clients dasselbe versuchen, kann man einen davon als Grundlage nutzen, um andere Plattformen zu bedienen. Oder man fängt neu an und kann es sauber, schnell und prägnant umsetzen. Ein typischer Erfolgsfaktor ist, dass ein kleines Team erfahrener Veteranen das neue System baut, und ich glaube, dass Erfolg aus kleinen Engineering-Teams entsteht, in denen Domänenexpertise und technische Expertise zusammenkommen. Ein wiederkehrendes großes Problem im technischen Management ist, dass ausgerechnet die am wenigsten erfahrenen Leute das nächste große System bauen.

  • Geteilte Erfahrung mit einer Neuschreibung in React
  • Betonung des „Finger-Gun“-Ansatzes und der Bedeutung kleiner, erfahrener Teams
  • Hinweis auf das Problem, dass unerfahrene Leute große Systeme bauen

• Große Neuschreibungen sind selbst bei beherrschbaren Codebasen riskant, und Altlasten verschwinden nicht vollständig. Wer will nach ein paar Jahren schon eine versteckte Einstellungsseite erneut schreiben? Es wäre schön, wenn es ein Framework für die Neuschreibung von Codebasen gäbe, aber in der Realität gibt es das nicht. Automatisierte Codemods verlangen Konsistenz, und daran fehlt es meist. Da sich Code-Muster im Lauf der Zeit stark verändert haben, wirkt es wie die Jahresringe eines Baums. Man packt den Code in Kästen und ordnet ihn neu an, aber auf der Ebene dieser Kästen findet keine Automatisierung statt.

  • Risiken einer Neuschreibung von Codebasen und verbleibende Probleme
  • Fehlendes Framework für die Neuschreibung von Code
  • Die Lücke zwischen Automatisierung auf Code-Ebene und auf Kasten-Ebene

• Ich arbeite derzeit bei LinkedIn, und ich denke, dass sich Chris’ im Podcast erwähnte Rolle und die Frontend-Webentwicklung auf ember beziehen. Gemeint ist vermutlich voyager-web, die monolithische Flaggschiff-Web-App von LinkedIn. Neben voyager-web gibt es bei LinkedIn viele weitere Systeme mit Millionen von Codezeilen und langen Build-Zeiten. Zum Beispiel die Mid-Tier-Schicht, den Offline-Daten-Stack, das Metriksystem, Kafka und mehr. Eine Build-Zeit von 17 Minuten ist ziemlich gut; wenn man ohne vorübergehende Infrastrukturfehler bei 17 Minuten liegt, ist das sehr gut.

  • Geteilte aktuelle Arbeitserfahrung bei LinkedIn
  • Erklärung zu verschiedenen Systemen und Build-Zeiten
  • Einschätzung der Build-Zeit von 17 Minuten

• Mehrere Millionen Zeilen JavaScript-Code bedeuten übermäßigen Ballast. Das brachte mich auf den Gedanken, einen Dienst wie LinkedIn neu zu implementieren oder eine eigene Kontaktdatenbank zu bauen. Das Problem ist, wie man Kontakte in großem Umfang migriert. Eines der Hauptprobleme von Microsoft LinkedIn ist, dass man Kontaktdaten nicht exportieren kann, obwohl das für eine Kontaktplattform eine zwingend notwendige Funktion ist.

  • Kritik am übermäßigen Umfang des JavaScript-Codes
  • Schwierigkeiten beim Übertragen von Kontaktinformationen
  • Die Bedeutung einer Exportfunktion für Kontaktdaten

• Ich habe 12 Jahre bei LinkedIn verbracht, aber inzwischen ist es weit entfernt von der früheren Engineering-Organisation. Als Kevin Scott das Engineering leitete, war es deutlich besser.

  • Langjährige Arbeitserfahrung bei LinkedIn
  • Unterschiede zwischen der früheren und der heutigen Engineering-Organisation

• Hier wirkt Conways Gesetz. Solange sich die Organisation nicht ändert, wird sie dieselbe Code-Unordnung wieder hervorbringen. Positive Engineering-Initiativen müssen von oben kommen und brauchen Unterstützung auf sehr hoher Ebene. Es ist unmöglich, eine Organisation von unten nach oben zu verändern; die Organisation erschafft die Codebasis.

  • Möglichkeit einer erneuten Code-Unordnung ohne organisatorischen Wandel
  • Notwendigkeit positiver Engineering-Initiativen von oben

• Ich war tief beeindruckt davon, wie offen Chris Krycho über seine Schwierigkeiten spricht, ohne dabei in Schuldzuweisungen zu verfallen. CoRecursive ist einer meiner Lieblingspodcasts, weil er den komplexen Kontext hinter Code erforscht.

  • Chris Krychos offene Haltung und sein Verzicht auf Schuldzuweisungen
  • Positive Einschätzung des Podcasts CoRecursive

• Der Wechsel von Ember zu React scheint gut zu einem Fall zu passen, bei dem ein früherer Kunde von mir die Technik entwickelt hat. Er baute eine Sprache namens „Unhack“, mit der sich auf AST-Ebene suchen und ersetzen ließ. Er nutzte eine Sprache, in der man ein Muster im Quellcode festlegt und ein anderes Muster angibt, das es ersetzen soll. Ich habe die Zusammenarbeit mit diesem Kunden vor einigen Jahren beendet, daher weiß ich nicht, ob das heute noch existiert.

  • Beispiel für einen Technologiewechsel von Ember zu React
  • Die Sprache „Unhack“, die Suchen und Ersetzen auf AST-Ebene ermöglicht

• Dass die Codebasis von LinkedIn chaotisch ist, überrascht nicht, wenn man die Website benutzt. Man klickt auf einen interessanten Beitrag, will mehr über die Person erfahren, die ihn geschrieben hat, drückt dann auf „Zurück“ – und der Feed lädt neu, sodass der Beitrag verschwunden ist. Wenn man durch empfangene Nachrichten scrollen will, wird die ganze Webseite träge, und es dauert 10 bis 15 Sekunden, bis Eingaben registriert werden. Warum bekommt man 30 gefälschte Benachrichtigungen? Das sind künstliche Benachrichtigungen, die Nutzer zu Interaktionen drängen sollen. Auch der Empfehlungsalgorithmus ist schlicht furchtbar.

  • Schwierigkeiten bei der Nutzung der LinkedIn-Website
  • Gefälschte Benachrichtigungen und langsame Reaktionszeiten der Webseite
  • Kritik an den Problemen des Empfehlungsalgorithmus