Beim Verlassen von LinkedIn
(corecursive.com)- Chris Krycho war bei LinkedIn etwa fünf Jahre lang für die Frontend-Infrastruktur und die Developer Experience der Desktop-Web-App verantwortlich und erlebte dabei den Konflikt zwischen sicheren Änderungen an einer riesigen Codebasis und dem Bedarf an schneller Produktumsetzung
- Die LinkedIn-Desktop-App umfasste bei seinem Eintritt etwa 2 Millionen Zeilen JavaScript und wuchs später zu einem Monorepo mit rund 3,2 Millionen Zeilen an; ohne Automatisierung und bei minimaler Belastung der Produktteams wären Migrationen praktisch nicht realisierbar gewesen
- Die Modernisierung von Ember und die Einführung von TypeScript zielten auf weniger Fehler und bessere Entwicklungsqualität; zur internen Überzeugungsarbeit diente die Analyse, dass der Wechsel zu TypeScript die Zahl der Fehler in den Application Logs um mindestens 25 % senken könnte
- Der Plan, von Ember zu React zu wechseln, brachte die 3- bis 5-jährige schrittweise Automatisierungsstrategie von Chris’ Team in Konflikt mit einem Ansatz, der für schnellere Produktexperimente die bestehende Arbeitsweise grundlegend neu gestalten wollte
- Bei der Reaktion auf einen größeren Ausfall zeigten sich Grenzen bei Alarmierung, Observability, Resilienz und Code-Reviews; Chris verließ das Unternehmen, weil die organisatorische Ausrichtung auf maximale Geschwindigkeit nicht zu seinen Werten passte
Fünf Jahre Arbeit und die Größe der Codebasis
- Chris Krycho kam Ende Januar 2019 zu LinkedIn und arbeitete dort etwa fünf Jahre
- Sein Verantwortungsbereich war nicht Server-Infrastruktur, sondern die Frontend-Infrastruktur und die Verbesserung der Developer Experience für die LinkedIn-Desktop-Web-App
- Er leitete große Modernisierungsprojekte für JavaScript in der Desktop-App, die für die Nicht-Mobil-Browser-Erfahrung auf LinkedIn.com zuständig ist
- Die App seines vorherigen Unternehmens hatte etwa 150.000 Zeilen Code, das LinkedIn-Frontend dagegen bei seinem Einstieg rund 2 Millionen Zeilen Code
- An derselben App commiteten pro Quartal 150 bis 200 Engineers, und dutzende Teams lieferten fortlaufend ein gemeinsames Produkt aus
- Als er einstieg, gab es unter mehreren tausend Engineers weniger als 100 Remote-Mitarbeitende, und Chris war als Remote-Engineer aus Colorado ein seltener Fall
Wie man aus einer 2-Millionen-Zeilen-Codebasis migriert
- Eine der ersten großen Aufgaben war es, in den Ember-basierten Code die moderne
class-Syntax von JavaScript einzuführen - Es gab Probleme damit, dass bestehende Ember-Klassen und native JavaScript-Klassen in Vererbungsketten gemischt wurden; intern nannte man das „Zebra Striping“
- Eine Migration in dieser Größenordnung musste so weit wie möglich automatisiert werden
- 2 Millionen Zeilen manuell zu ändern, hätte Monate oder länger dauern können
- Von Produktteams zu verlangen, die Feature-Entwicklung zu stoppen und nur neue Syntax einzuführen, war schwer vermittelbar
- Bei LinkedIn gab es einen Prozess für teamübergreifende horizontale Initiativen (horizontal initiatives), mit dem Betriebsprinzip, die Beteiligung der Produktteams unter 10 % zu halten
- Chris’ Team kam zu dem Schluss, dass Produktteams eher ein Modell akzeptieren würden, bei dem das Infrastrukturteam per Automatisierung PRs erstellt und die Produktteams nur Review und Smoke-Tests übernehmen, statt selbst Codemods auszuführen
- Die Ember-bezogenen Arbeiten dauerten insgesamt 18 Monate; der Großteil geschah innerhalb von 6 Monaten, doch durch Verzögerungen einzelner Teams blieb ein langer Nachlauf
Die Argumentation für TypeScript über Fehlerreduktion
- Nach der Ember-Modernisierung nahm sich Chris’ Team als Nächstes die große Zahl von JavaScript-Fehlern im Frontend vor
- Wegen des großen Umfangs der Error Logs nutzte LinkedIn statt externer Dienste eine interne Logging-Infrastruktur
- LinkedIn hatte im Vorjahr die Marke von 1 Milliarde Mitgliedern überschritten, und als Chris ging, umfasste das Monorepo rund 3,2 Millionen Zeilen
- die Hälfte davon Testcode
- die Hälfte Produktionscode
- Chris’ Team analysierte gesondert, welche Fehlerkategorien TypeScript abfangen könnte
- Einige Fehler lassen sich auch mit TypeScript nicht erkennen, doch man kam zu dem Schluss, dass nach Abschluss der gesamten Migration die Menge der Application Logs unter den täglich millionenfach auftretenden JavaScript-Fehlern um mindestens 25 % sinken könnte
- Ein von Chris verfasstes Dokument zur TypeScript-Umstellung wurde wiederholt unter Engineers und Managern geteilt
- welches Problem gelöst werden sollte
- welche Vorteile zu erwarten waren
- wie es sich im Hiring-Wettbewerb auswirken würde
- welche Entscheidungsgrundlage es im Vergleich zu anderen Prioritäten bot
- Später übernahm Chris intern die Rolle eines Experten für schwierige TypeScript-Typfragen
Von Ember zu React: schrittweise Umstellung und komplette Neuplanung
- LinkedIn war der größte EmberJS-Nutzer der Welt, doch Chris’ Arbeit entwickelte sich schließlich in Richtung eines Plans für die Migration von Ember zu React
- Führende Entscheidungsträger sahen die Migrationskosten bei LinkedIn als zu hoch an und meinten, sie bremsten die Produktgeschwindigkeit
- Der Plan von Chris’ Team war eine schrittweise, automatisierte Strategie über 3 bis 5 Jahre
- mehr Automatisierung, damit die Produktteams kaum ausgebremst werden
- Build-Pipeline, Data Layer, Routing-Schicht, Reaktivitätssystem und View-Schicht sollten nacheinander entkoppelt und migriert werden
- am Ende sollte das Ember-Rendering- und Reaktivitätssystem auf die React-Seite verlagert werden
- Ein anderes Team zielte direkter auf das Geschwindigkeitsproblem
- das Ziel war, die Zeit von der Idee bis zum A/B-Test von mehreren Monaten auf einige Wochen zu verkürzen
- als Problem galten die unterschiedlichen Stacks von Desktop Web, Mobile Web, iOS und Android sowie die langen Zykluszeiten
- Chris nahm den Ansatz dieses Teams als eine Haltung wahr, die nah an „finger guns mode“ lag
- er hatte das Gefühl, dass Probleme beim Skalieren von Unterstützung für einige Dutzend Personen auf Hunderte Engineers nicht ausreichend behandelt wurden
- auf Fragen habe es oft Reaktionen gegeben, die in etwa lauteten: „Das wird kein Problem sein“
- Der 3- bis 5-Jahres-Plan seines Teams stieß bei der Führung nicht auf gute Resonanz
- der Plan war lang und nicht besonders spannend
- das Team selbst präsentierte ihn auch als „die am wenigsten schlechte Wahl“, was seine Überzeugungskraft schwächte
Resilienzprobleme, die sich bei einem Ausfall zeigten
- Nachdem Chris aus dem Weihnachtsurlaub zurückgekehrt war, trat für einen Teil der LinkedIn-Nutzenden ein Problem auf, bei dem LinkedIn.com-Seiten bis zu etwa 20 Minuten lang nicht sichtbar waren
- Das Problem hing mit einem Prerendering-Service zusammen, der Client-Code in Node.js ausführt, um Backend-Daten zu sammeln und schneller auszuliefern
- Der Service hatte ein Memory Leak, und Container wurden so neu gestartet, dass sie bei Überschreitung des Memory-Limits beendet wurden
- Mehrere Faktoren verstärkten den Ausfall
- für Memory-Kills gab es nicht genügend Alarmierung
- die Zahl der gleichzeitig neu startbaren Container war als Schlüssel in einer YAML-Datei konfiguriert
- dieser Wert war vom Typ her zulässig, für dieses System aber falsch
- praktisch lag der Konfigurationswert nahe an der Gesamtzahl aller laufenden Services
- Wenn ein Deployment-Stopp lange andauerte, etwa über ein langes Wochenende, liefen Services ungefähr zur gleichen Zeit in Memory-Probleme und starteten gleichzeitig neu, sodass Nutzeranfragen nicht verarbeitet werden konnten
- Fielen einige Server aus, stieg die Last auf die verbleibenden Server, deren Memory-Verbrauch dadurch noch schneller anstieg, bis ganze Server in einem Rechenzentrum ausfielen
- Gleichzeitig lief eine Rightsizing-Maßnahme zur Reduktion von CPU- und Memory-Nutzung der Fleet, wodurch die Reserven kleiner geworden waren
- Chris und andere Engineers sahen den Bedarf an besserer Alarmierung, Observability und Resilienz
- auch wenn ein einzelner Node-Server in einen Runaway-Zustand gerät, sollte er nicht den Host-Prozess mit in den Tod reißen
- sicherer wäre es, nur den Node-Prozess zu beenden, zu alarmieren und dann neu zu starten
- außerdem wurde ein Fallback-Pfad geprüft, bei dem bei Ausfall des Services auf clientseitiges Fetching gewechselt wird
Der Konflikt, dass Code-Review allein nicht ausreicht
- Meetings zur Incident Response fanden mehrmals pro Woche statt und dienten dazu, Fortschritte zu teilen und an Executives zu berichten
- Ein Manager aus einem anderen Team übernahm die Incident Response und zog zusätzliche Ressourcen hinzu; Chris verstand das als Entwicklung, die ihm und seinem bisherigen Team die richtigen Antworten nicht zutraute
- In diesem Prozess fragte ein Senior Engineer: „Warum kann Code-Review das nicht verhindern?“
- Chris war der Ansicht, dass Code-Review allein nicht garantieren kann, dass so etwas nicht wieder passiert
- Menschen machen Fehler
- für einen Junior Engineer ist es schwer, bei einem PR eines sehr erfahrenen SRE zu hinterfragen, ob ein Konfigurationswert vernünftig ist
- ein System muss nicht nur an den besten Tagen eines Senior Engineers sicher funktionieren, sondern auch an den schlechten Tagen eines Junior Engineers
- Für Chris umfasst Software Engineering auch die Gestaltung von Systemen, die Engineers dabei unterstützen, Produktergebnisse zu liefern
- Technische Störungen und organisatorische Kommunikation waren für ihn nicht trennbar; wie Charity Majors sagt, gibt es auf hoher Ebene keine rein sozialen oder rein technischen Probleme
Führung, Remote-Kultur und Wertekonflikte
- Chris hatte den Eindruck, dass sein Team und sein Ansatz gegen den Vorschlag des anderen Teams verloren hatten
- Der Plan des anderen Teams weitete sich zu einer Richtung aus, die sowohl Desktop als auch Mobile Apps neu dachte und grundsätzlich infrage stellte, wie LinkedIn Produkte baut
- Chris wollte diesen Vorschlag besser machen, hatte aber das Gefühl, dass seine Bedenken und Fragen nicht ausreichend aufgenommen wurden
- Ein Manager habe ihm gesagt: „Du bist zu idealistisch, kümmerst dich nicht genug um Gewinn und Verlust und musst deine Werte ändern.“
- Chris war der Ansicht, dass Remote-Arbeit die Beziehungsbildung beeinflusste
- LinkedIn hatte eine starke Präsenzkultur, und viele bauten Beziehungen ganz natürlich in der Cafeteria oder auf den Fluren auf
- wiederholter physischer Kontakt zu Senior Engineers und Executives könne in Konfliktsituationen einen Unterschied machen
- Chris blickte selbstkritisch darauf zurück, dass auch er Schwächen im Aufbau von Beziehungen hatte
Warum er am Ende ging
- Chris sah viele Probleme der bestehenden Codebasis als Folge davon, dass Geschwindigkeit überbewertet und Probleme in Nebenpfaden nicht behoben oder entfernt wurden
- Wenn Geschwindigkeit zum obersten Wert wird, könne man anfangs zwar Tempo gewinnen, doch auf Dauer sei das schwer aufrechtzuerhalten
- Er sagte, er habe in einem früheren Job Burnout erlebt und unter starken Migränen, Bauchschmerzen, Bewegungsunfähigkeit, plötzlichen Weinkrämpfen und Panikattacken gelitten
- Er glaubte, dass er bei einem Verbleib bei LinkedIn weiterhin jeden Tag darum hätte ringen müssen, nicht wütend zu werden
- Er verglich die Situation damit, die Richtung einer riesigen Organisation mit einem kleinen Ruderboot ändern zu wollen, und entschied, nicht mehrere Jahre auf eine Arbeitsweise und an Aufgaben zu verwenden, an die er nicht glaubte
- Chris lernte bei LinkedIn viel über eine App mit 3 Millionen Zeilen, TypeScript-Migrationen in Großunternehmen und groß angelegte Engineering-Probleme, verließ das Unternehmen aber, um Arbeit zu finden, die zu seinen Werten passt
1 Kommentare
Hacker-News-Kommentare
Ich fand den interessantesten Teil im Podcast die Rückmeldung: „zu idealistisch, achtet nicht genug auf Gewinn und Verlust und muss seine Werte ändern“. Diesen Eindruck hatte ich schon vor dem Lesen, und obwohl er zwischendurch wertvolles Feedback bekam, klang es so, als hätte er es absichtlich ignoriert
Das Schwierige für einen Senior Staff Engineer ist nicht nur, „richtig“ zu liegen, sondern in der gesamten Organisation Alignment in Richtung der richtigen Lösung herzustellen. Ich war 2019 an der Neuschreibung von facebook.com mit React beteiligt, deshalb fand ich das besonders interessant
In gewissem Maß habe ich kommuniziert, aber während meiner Zeit bei LinkedIn war ich dabei nicht besonders erfolgreich. Ein Teil davon lag an mir, ein Teil auch an LinkedIn
In diesem Fall bedeutete „zu idealistisch“ allerdings tatsächlich: „Kümmere dich nicht um Dinge, die nicht direkt zum Gewinn und Verlust beitragen“, und das lehne ich zutiefst ab. Gewinn und Verlust sind wichtig, aber auch User Experience, Developer Experience und die grundlegende Ethik dessen, was wir bauen, sind wichtig
In einer Organisation vertritt man nach bestem Wissen und Gewissen das, was man für richtig hält, und dann entscheidet jemand anderes oder ein Gremium, ob zugestimmt wird. Ob ich das Ergebnis akzeptiere oder einen Kompromiss eingehe oder gehe, entscheide ich, und in meiner Karriere habe ich beides getan
Bei einem bekannten Unicorn gab es einen sehr klugen, vernünftigen und freundlichen Senior Staff Engineer. Er drängte darauf, ein Framework, für das jährlich 50 Millionen Dollar ausgegeben wurden, von v2 auf v3 anzuheben, und verglichen mit dem Wechsel von Python 2 auf 3 war das eine sehr kleine Änderung
Die Untersuchung ergab, dass im Grunde 10 % Leistungsverbesserung zu erwarten waren, dennoch wollte das Management keine Zeit mit einem „Versions-Upgrade“ verschwenden. Schließlich setzte der Engineer es auf eigene Faust durch, baute in weniger als einem Monat eine Preview-Version und migrierte innerhalb von zwei Monaten einen Teil der Arbeiten mit großem Effekt, wodurch ein Mehrfaches seines Gehalts eingespart wurde
Nachdem die anfänglichen politischen und technischen Kosten bezahlt waren, wollten am Ende alle umziehen, und ein Jahr später, als das Rollout abgeschlossen war, war die obenstehende Managementstruktur durch Entlassungen und Kündigungen etwa zur Hälfte ausgetauscht, aber der Engineer und die Migration waren geblieben. Manchmal ist ein Staff Engineer nicht stur, sondern in einer verrückten Welt der einzige vernünftige Mensch
Ich war in so einer Position und hätte mich heraushalten können, aber das ist nicht immer möglich
Ich habe gesehen, dass jemand auch ohne die besten Ideen oder Pläne mit den richtigen Verbindungen, dem richtigen Mittagessen am richtigen Tisch und den richtigen Worten das Management überzeugt
Der Satz „Du bist zu idealistisch und achtest nicht genug auf Gewinn und Verlust“ kann auch ein Stigma sein, mit dem jemand verdrängt werden soll. Besonders dann, wenn die betreffende Person sich selbst und ihre Ideen auf diese Weise nach oben verkauft hat
Ich habe persönlich in Organisationen, die kleiner als Facebook waren, aber Hunderte von Engineers und große Codebases hatten, mehrfach große Änderungen und Upgrades rund um Ruby, Rails und Postgres durchgeführt, und die von Chris beschriebene Methodik ist sehr vernünftig und passt auch zu der Vorgehensweise, die ich als erfolgreich empfunden habe
Ich stimme zu, dass Führungsrollen nur mit Vertrauen und Respekt wirksam sind. Natürlich muss man dafür dann auch tatsächlich richtig liegen. Fortschritt in die falsche Richtung ist kein Fortschritt
Ich habe zwar nie gearbeitet, ohne die LinkedIn-Codebasis zu kennen, aber ich habe mehrfach Codebasen sowie Organisations- und Politikstrukturen gesehen, die beängstigend ähnlich klangen. Deshalb verteidige ich normalerweise den Fingergun-Ansatz
Auch ein Fingergun-artiges Rewrite kann gut umgesetzt werden. Wenn es mehrere Clients gibt, die dasselbe tun, kann man einen davon als Grundlage für eine andere Plattform nehmen, und selbst bei einem kompletten Neustart kann man sauber, schnell und kompakt vorgehen
Der Schlüssel zum Erfolg ist, ein neues System einem kleinen Veteranenteam zu überlassen, das sowohl Domänen- als auch Technikexperten sind. Das ist kontrovers, aber ich denke, daraus kommt jeder Erfolg, selbst bei gewöhnlichen Betriebs- und Wartungsproblemen. Der Rest verlangsamt nur alles
Ein großes Problem, das die meisten technischen Führungskräfte immer wiederholen, ist, dass sie das nächste große System den am wenigsten erfahrenen Leuten überlassen. Ich würde dazu gern auch ein symmetrisches Interview von der Fingergun-Seite hören
Das ist natürlich so, weil es erprobte Dinge sind, die für sie bereits funktioniert haben, aber es ist nicht immer das Beste. Außerdem bleiben Veteranenteams, selbst wenn sie ein Projekt starten, selten bis zum Ende dabei, und wenn sie weder die Folgen noch die Nachwirkungen tragen müssen, ist es allzu leicht, Entscheidungen zu treffen
Ein Plan braucht realistische Optionen, um mit Hindernissen umzugehen, und dazu gehören nicht nur technische Optionen, sondern auch die Zeit und Fähigkeit der Menschen, die die Arbeit machen sollen. Wenn ein Plan zum Beispiel vorsieht, dass mehrere Teams Server betreiben, dann mag das technisch möglich sein, ist aber keine realistische Option, wenn die Teams weder Zeit noch Fähigkeit dafür haben
Umgekehrt ist es auch schlecht, einen raffinierten Pfad zu planen, der jedes Hindernis umgeht. Bis man ankommt, könnten sich die Hindernisse bewegt haben, und auf dem Weg könnten noch unbekannte Hindernisse liegen. Wenn man nur einen einzigen Weg geplant hat, bleibt man dort stecken
Allerdings sehe ich hier gerade nur die Beschreibung eines Podcasts, der eine komplexe Architekturdebatte comicartig zusammenfasst, daher kann ich nicht sagen, welches Strohmann-Argument bei LinkedIn tatsächlich näher an der Realität war
Angeblich sagte der Vorstand der gesamten Engineering-Organisation, dass bei künftigen Projekten niemand mehr irgendwem Details vorgeben dürfe
Es klingt so, als hätte Chris einige unglückliche Entscheidungen getroffen. Er hat einen Fünfjahresplan vorgeschlagen, den Vorfall eher in Richtung Schuldzuweisung als Führung gelenkt, mehr über das Problem gesprochen als es zu lösen und offenbar auch zu wenig an Beziehungen gearbeitet
Ich habe Mitgefühl mit Chris, zugleich wirkt es aber auch so, als hätte er nicht gewusst, wie man in diesem Umfeld Ergebnisse erzielt. Das ist trotzdem okay. Nicht jeder muss lernen, in einem bürokratischen Knoten zu arbeiten, und Startups sind in dieser Hinsicht einfacher
Es gibt einen Grund, warum große Unternehmen mit der Zeit ihre Schärfe verlieren und warum irgendwann irgendein Executive im Konferenzraum einem Verlust von -10 % im Jahresvergleich gegenübersitzt, ohne dass auch nur ein einziger VP offen die Wahrheit ausspricht
Wenn man in so einer Situation steckt, verliert man psychologisch den Orientierungssinn. Ich scheine recht zu haben, aber habe ich wirklich recht? Sind die Leute um mich herum wirklich so unfähig und so wenig daran interessiert, von Kollegen zu lernen?
Wenn man Jahre später geht und zurückblickt, wurden diese Leute entlassen oder sind gegangen, die Organisation kann X immer noch nicht, und die Agilität und Kompetenz der später dazugestoßenen Teams waren tatsächlich real
Einerseits kann es Arroganz sein, politisches Unvermögen oder die Unfähigkeit, sich an eine krankhafte Kultur der Einzelarbeit anzupassen. Andererseits könnte genau das die richtige Reaktion sein
Wenn eine Organisation gerade durch eine Phase krankhafter Kultur geht, dann kann es gut sein, dass talentierte, sorgfältige und leidenschaftliche Menschen daran verrückt werden. Diejenigen, die davon nicht verrückt werden, sind für Produktivität und Wachstum womöglich irrelevant oder schlimmer noch ein Nettoverlust
Deshalb werden solche Umgebungen zu einem Psychodrama. Ist die Lage wirklich so schlimm, oder reagiere ich überempfindlich?
Aber in einer Situation, in der die Führung sagte: „Selbst die von uns geforderte Migration darf die Geschwindigkeit der Produktiteration überhaupt nicht verlangsamen“, war es auch der einzige Plan, den wir glaubten vertreten zu können
Ich bin mir nicht sicher, was damit gemeint ist, dass ich den Vorfall in Richtung Schuldzuweisung gelenkt hätte. Ich habe eher das Gegenteil versucht und weder der Person die Schuld gegeben, die den Memory-Schwellenwert gesenkt hat, noch der Person, die in YAML einen falschen Wert vertippt hat. Ich habe nur darauf bestanden, die eigentlichen Ursachen wirklich zu beheben, statt sie bis zum nächsten Ausfall liegenzulassen
Auch bei dem Punkt, ich hätte mehr geredet als Probleme gelöst, bin ich mir nicht sicher. Ich habe in der Sendung nur nicht lang und breit erzählt, was ich alles geschafft habe, aber die Probleme, die ich dort gelöst habe, habe ich ziemlich gut gelöst
Mangelnder Beziehungsaufbau war, wie ich auch in der Episode gesagt habe, mein größter Schwachpunkt. Zu den Ingenieuren hatte ich gute Beziehungen, aber gerade beim höheren Management bin ich deutlich daran gescheitert, politisches Vertrauen aufzubauen
Trotzdem glaube ich nicht, dass es einfach nur daran lag, dass ich nicht wusste, wie man in diesem Umfeld Ergebnisse erzielt. Ich konnte Wege sehen, auf denen ich hätte erfolgreich sein können, aber ich habe mich auch entschieden, nicht auf eine Weise zu handeln, an die ich nicht glaube. Viele der Ingenieure, die ich respektiere, tanzen den politischen Tanz für Dinge, an die sie glauben, aber nicht für Dinge, an die sie nicht glauben
Ich arbeite aktuell bei LinkedIn. Chris’ Rolle und Podcast scheinen sich um Ember und Frontend-Webentwicklung zu drehen, und die von ihm erwähnte Anzahl an Codezeilen und Builds bezieht sich wahrscheinlich auf voyager-web, die monolithische Haupt-Web-App von LinkedIn.
Bei LinkedIn gibt es noch weitere Systeme mit Millionen von Codezeilen und langen Build-Zeiten: die Mid-Tier-Schicht, den Offline-Daten-Stack, Metriksysteme und Dinge wie KafkaKafkaKafka.
Leider ist ein 17-Minuten-Build ziemlich gut. Wenn er ohne vorübergehende Infrastrukturstörungen 17 Minuten dauert, ist das sogar sehr gut.
Im ganzen Unternehmen gibt es fast kein Testverständnis und auch kein QA. Ingenieure drücken halbfertige Projekte hinein, damit sie sie in ihre Beförderungsunterlagen aufnehmen können, und ziehen dann weiter.
Weil man die internen Tools täglich nutzt, musste man zu viele Probleme selbst lösen, und die Ingenieure, die einfach nur ihre Arbeit machen wollten, wurden dadurch faktisch zu QA.
Stattdessen sollte man Builds schneller machen oder die Build-Infrastruktur schneller und günstiger machen.
Zumindest in den Teams, in denen ich war, wurde ziemlich viel Wert auf Codequalität gelegt, und die Kultur wurde auch kontinuierlich besser. Ich habe allerdings einmal an voyager gearbeitet, und das ist mir als Albtraum in Erinnerung geblieben.
Groß angelegte Rewrites sind selbst bei beherrschbaren Codebasen riskant, und die übrig gebliebenen Reste verschwinden offenbar nie ganz. Wer will schon in ein paar Jahren Punkte dafür sammeln, eine in die Ecke gedrängte Einstellungsseite neu zu schreiben?
Ich habe zu viele solcher Versuche gesehen; man sollte meinen, es gäbe ein Framework für Codebase-Rewrites, aber das gibt es nicht. Automatische Code-Modification-Tools verlangen Konsistenz, aber nur wenige Orte halten diese Konsistenz ein. Code-Patterns entwickeln sich im Lauf der Zeit so stark weiter, dass es sich anfühlt, als würde man Jahresringe betrachten.
Im Grunde packen wir Code in Kisten, ordnen die Kisten neu an und behaupten mit gewisser Plausibilität, dass irgendeine Anordnung effizienter sei. Warum haben wir also keinen besseren Weg gefunden? Automatisierung funktioniert auf Code-Ebene, aber nicht auf Kisten-Ebene.
Das ist ein Fall, in dem Conways Gesetz greift. Die Organisation hat sich nicht verändert, also ist die Wahrscheinlichkeit hoch, dass dieselbe Code-Suppe erneut entsteht.
Aus Erfahrung auf demselben Schiff kann ich sagen: Positive Engineering-Initiativen müssen von oben nach unten über einen Sponsor auf sehr hoher Ebene getragen werden. Man kann eine Organisation nicht von unten nach oben verändern, und letztlich ist es die Organisation, die die Codebasis hervorbringt.
Conways Gesetz ändert sich nicht, ist aber nicht zwangsläufig nur an das formale Organigramm gebunden. Wenn man zwischen den richtigen Tech Leads und fähigen Managern eine temporäre Kommunikationsstruktur schafft, lässt sich damit arbeiten.
Es reichen allerdings schon ein paar technisch schwache Manager in der Mitte oder Leute, die sich ihr eigenes Königreich aufbauen wollen, und das Ganze kippt leicht. Je nach Lebenszyklus des Unternehmens kann wegen Pournelles eisernem Gesetz der Bürokratie ohnehin schon alles verloren sein.
Zum Beispiel gibt man allen Entwicklern ein populäres Framework, wenn sie eigentlich alle schlecht sind. Das ist nur eine Ausrede, um das eigentliche Menschenproblem nicht anzugehen, und so, als würde man Kinder eine Kita betreiben lassen.
Wenn man Exzellenz will, muss man hohe Standards mit Regeln setzen, die Rechenschaft einfordern und Eigentümerschaft sowie Belohnung und Verantwortung zuweisen. Das ist nicht kompliziert, aber es erfordert Entschlossenheit von oben und die Bereitschaft, Konflikte nicht zu scheuen.
Es könnte allerdings dazu führen, dass du jede Hoffnung verlierst, dass eine Firma wie Microsoft noch etwas bauen und es danach nicht ruinieren kann.
Ich habe 12 Jahre bei LinkedIn verbracht. Traurigerweise ist es weit entfernt von der früheren Engineering-Organisation. Als Kevin Scott das Engineering leitete, war es im Vergleich wirklich gut.
Hunderte Millionen Zeilen JavaScript – das ist schon für sich die Verkörperung von Aufgeblähtheit
Ich habe darüber nachgedacht, so etwas wie LinkedIn neu umzusetzen, oder genauer gesagt eine Datenbank meiner Kontakte ohne diese „Facebook-artigen“ Funktionen zu bauen.
Das Problem ist, wie ich meine Kontakte in großer Zahl herüberbekomme. Abgesehen von der Aufgeblähtheit ist das Hauptproblem bei Microsoft LinkedIn, dass es den Export von Kontaktinformationen nicht erlaubt, und für eine Kontaktplattform ist das eine zwingend nötige Funktion.
https://queue.acm.org/detail.cfm?id=2567673
Zusammenfassung: https://www.pixelstech.net/article/1395463142-Why-does-Linke...
LinkedIn ist Anfang 2010 auf Node migriert.
Wenn ich allerdings die Reaktionen in diesem Thread sehe, frage ich mich auch, ob die Zahl vielleicht falsch war.
Bei LinkedIn habe ich das nicht gemacht, aber es ist ein schmutziger Trick, den ich nutze, wenn ich Teilnehmerlisten von Konferenzen exportiere, die auf öffentlichen Websites stehen. Kann je nach Situation unterschiedlich sein.
Beeindruckend fand ich, wie Chris Krycho nicht in ein Schuldzuweisungsspiel abrutscht, sondern offen über seine Schwierigkeiten spricht. CoRecursive ist einer meiner Lieblingspodcasts, weil er sich mit dem komplexen Kontext hinter dem Code beschäftigt.
Klingt fast immer nach einer harten Rolle im Bereich Soft Leadership. Man trägt für etwas „Verantwortung“, hat aber kaum oder gar keine Befugnisse gegenüber dem Rest der Organisation.
Wenn es echte technische Führung gibt, ist sie möglicherweise nicht mehr da oder schon lange im Unternehmen und selbst als „Systemexperte“ nicht mehr wirklich mit den tatsächlichen Problemen verbunden. Habe ich erlebt, und ich passe dankend.