En quittant LinkedIn

• Que choisir quand bien faire son travail entre en conflit avec le rythme rapide de l’entreprise ?
• L’histoire de l’ingénieur Chris Krycho, qui a choisi la seconde option : partir pour trouver un travail en accord avec ses principes, plutôt que de préserver ses convictions tout en composant avec la situation
• Chris a finalement quitté LinkedIn pour poursuivre un travail conforme à ses principes
• Résumé de ce qu’il a raconté dans un podcast
• Son récit met en lumière la tension entre la « nécessité d’innover » et « l’importance de la santé des projets »

Le premier jour de Chris Krycho chez LinkedIn

• Chris a rejoint LinkedIn fin janvier 2019. Il a suivi diverses étapes d’onboarding, comme on en voit souvent dans les grandes entreprises ou les petites structures bien organisées.
• Chris devait travailler à distance depuis le Colorado, mais il a passé les deux premières semaines à suivre l’onboarding et à passer du temps avec son équipe.

Des millions de lignes de code

• Par rapport à son expérience dans son entreprise précédente, il a été fortement surpris par l’ampleur des applications client front-end et des services back-end de LinkedIn.
• Le front-end de LinkedIn comptait 2 millions de lignes de code, bien davantage que l’ensemble du code de son entreprise précédente.

L’équipe infrastructure

• Le rôle de Chris, au sein de l’équipe infrastructure, ne portait pas sur la mise en place de serveurs, mais sur le support à l’ingénierie et l’amélioration de l’expérience développeur.
• L’objectif était de faciliter le travail sur la très grande application desktop de LinkedIn.

Modernisation JavaScript

• Il a participé à un travail de modernisation du code via l’introduction des classes JavaScript. En résolvant les problèmes liés à l’utilisation du framework Ember, il a beaucoup appris.
• Il a compris que les migrations dans une base de code de grande taille devaient être automatisées autant que possible, car la charge de travail est trop importante pour être traitée manuellement.

Adoption de TypeScript

• L’équipe a décidé de passer à TypeScript pour réduire les erreurs côté front-end.
• TypeScript peut être adopté progressivement, ce qui offre la scalabilité dont LinkedIn avait besoin.

Plan de migration lent contre « Finger Gun’s Plan »

• Chris et son équipe ont proposé un plan sur 3 à 5 ans pour migrer le code Ember vers React, mais une autre équipe a présenté le « Finger Gun’s Plan », qui promettait une refonte globale et un rythme plus rapide.
• Cette différence d’approche reflétait le conflit entre les problèmes que Chris et son équipe constataient sur le terrain, et une culture d’entreprise qui donnait la priorité à la vitesse.

L’expérience et les enseignements de Chris

• Prise de conscience d’un problème d’alertes insuffisantes.
• L’augmentation de l’utilisation mémoire et la réaction en chaîne des redémarrages de serveurs ont entraîné la panne des serveurs de tout le datacenter.
• Il a tenté de résoudre le problème via une réinitialisation du système et des ajustements de permissions.
• L’échec est inévitable, et le software engineering consiste à concevoir des systèmes qui soutiennent le processus par lequel les ingénieurs produisent des livrables.
• Il souligne la nécessité de systèmes dotés de résilience à plusieurs niveaux.

Réactions après l’incident

• Du mécontentement est apparu pendant la résolution du problème, en raison d’un manque de confiance de la part du management.
• Désaccords avec des ingénieurs seniors et problèmes de communication.
• Il insiste sur le fait qu’un système ne doit pas seulement fonctionner dans des conditions optimales, mais pouvoir offrir un support dans toutes les situations.

Une pression croissante

• Malgré les efforts pour résorber la dette technique et améliorer la résilience, l’insatisfaction de la direction a augmenté.
• Conflit avec des dirigeants qui exigeaient des solutions simples à des problèmes complexes.

Réorganisation

• Réorganisation de l’équipe et évolution des rôles sous l’effet de l’« équipe finger guns ».
• Prise de conscience de nouvelles expériences et opportunités d’apprentissage dans d’autres rôles.

Réflexion et prise de conscience

• Réflexion personnelle nourrie par les expériences passées et la situation présente.
• Prise de conscience de l’importance des relations humaines et de la communication.
• Compréhension du lien entre problèmes techniques et problèmes sociaux.

Conclusion et enseignements

• Chris conserve un regard critique sur une culture qui érige la vitesse en valeur suprême.
• Il cherche de nouvelles opportunités à travers une réflexion sur sa carrière et ses valeurs personnelles.
• Le parcours de Chris pour trouver un rôle orienté vers l’excellence en ingénierie se poursuit.

L’avis de GN⁺

• L’expérience de Chris Krycho montre bien le conflit entre principes techniques et exigences business.
• Sa décision souligne l’importance de trouver un équilibre entre valeurs personnelles et choix professionnels.
• La conduite du changement dans un environnement technologique de grande ampleur comme LinkedIn est complexe, et offre aussi des enseignements importants à d’autres entreprises.
• L’adoption de technologies comme TypeScript peut aider à améliorer la qualité du code et à réduire les erreurs, mais une approche progressive est nécessaire dans une base de code de grande taille.
• Lorsqu’on mène ce type de transformations techniques, il faut prendre en compte l’équilibre entre l’expérience développeur et la vitesse de livraison produit.

[GN⁺]

Avis sur Hacker News

• Lors d’une conversation avec un manager, il aurait entendu : « tu es idéaliste, tu n’accordes pas assez d’importance au profit et tu dois changer de valeurs ». Il a dit que cela l’avait rebuté et a affirmé sa volonté de rester fidèle à ses convictions. Selon ce commentaire, c’était la partie la plus intéressante du podcast, et l’auteur en a retiré l’impression qu’il avait délibérément ignoré un retour important. La leçon tirée de sa carrière est que le plus difficile n’est pas de savoir ce qui est juste, mais d’obtenir l’alignement de toute l’organisation sur la bonne solution.

  • Exemple d’un conflit de valeurs lors d’un échange avec un manager
  • Impression d’un rejet délibéré d’un retour important
  • Leçon clé : l’alignement de toute l’organisation sur la bonne solution

• En 2019, j’ai participé à la réécriture de facebook.com en React. Je ne connais pas directement la base de code ni l’organisation de LinkedIn, mais j’ai vu des entreprises avec des bases de code et des structures organisationnelles similaires. Je soutiens l’approche « finger gun », qui peut produire de bons résultats lorsqu’elle est bien exécutée. Quand plusieurs clients essaient de faire la même chose, on peut partir d’un seul pour servir les autres plateformes. Ou, si on repart de zéro, on peut le faire de manière propre, rapide et concise. Les éléments de réussite sont généralement une petite équipe de vétérans construisant un nouveau système, et je pense que le succès vient de petites équipes d’ingénieurs combinant expertise métier et expertise technique. Un grand problème récurrent dans le management technique, c’est que ce sont les personnes les moins expérimentées qui construisent le prochain grand système.

  • Partage d’une expérience de réécriture vers React
  • Mise en avant de l’approche « finger gun » et de l’importance de petites équipes expérimentées
  • Critique du fait que les grands systèmes sont souvent confiés aux moins expérimentés

• Les grandes réécritures sont risquées même avec une base de code gérable, et les problèmes résiduels ne disparaissent jamais complètement. Qui voudra réécrire, des années plus tard, une page de configuration cachée ? J’aimerais qu’il existe un framework pour réécrire une base de code, mais en pratique ce n’est pas le cas. Les codemods automatisés exigent de la cohérence, ce qui est rarement respecté. Comme les patterns de code ont beaucoup évolué au fil du temps, c’est un peu comme regarder les cernes d’un arbre. On met le code dans des boîtes et on les réorganise, mais l’automatisation n’existe pas au niveau de ces boîtes.

  • Risques des réécritures de base de code et problèmes résiduels
  • Absence de framework pour réécrire du code
  • Écart entre l’automatisation au niveau du code et celle au niveau des boîtes

• Je travaille actuellement chez LinkedIn, et je pense que le rôle de Chris mentionné dans le podcast ainsi que le développement web frontend concernent ember. Il semble s’agir de voyager-web, l’application web monolithique phare de LinkedIn. Au-delà de voyager-web, LinkedIn possède de nombreux autres systèmes avec des millions de lignes de code et des temps de build longs. Par exemple, la couche intermédiaire, la stack de données offline, le système de métriques, Kafka, etc. Un build en 17 minutes est plutôt bon ; 17 minutes sans panne d’infrastructure transitoire, c’est même très bon.

  • Témoignage d’une expérience actuelle de travail chez LinkedIn
  • Explication sur divers systèmes et sur les temps de build
  • Évaluation d’un temps de build de 17 minutes

• Des millions de lignes de JavaScript, cela indique un volume excessif. Cela m’a donné envie de réimplémenter un service comme LinkedIn ou de créer ma propre base de données de contacts. Le problème, c’est comment migrer ses contacts à grande échelle. L’un des principaux problèmes de Microsoft LinkedIn, c’est qu’il n’est pas possible d’exporter les informations de contact, alors qu’il s’agit d’une fonctionnalité indispensable pour une plateforme de contacts.

  • Critique du volume excessif de code JavaScript
  • Difficulté du transfert des informations de contact
  • Importance de la fonction d’export des contacts

• J’ai passé 12 ans chez LinkedIn, mais c’est désormais très éloigné de l’ancienne organisation d’ingénierie. C’était bien mieux à l’époque où Kevin Scott dirigeait l’ingénierie.

  • Expérience d’une longue carrière chez LinkedIn
  • Différences entre l’ancienne organisation d’ingénierie et l’actuelle

• C’est un cas où la loi de Conway s’applique. Tant que l’organisation ne change pas, elle recréera le même chaos dans le code. Les initiatives d’ingénierie positives doivent venir d’en haut et nécessitent un soutien à un très haut niveau. Il est impossible de transformer une organisation du bas vers le haut ; c’est l’organisation qui produit la base de code.

  • Risque de reproduction du chaos logiciel sans changement organisationnel
  • Nécessité d’initiatives d’ingénierie positives portées par le sommet

• J’ai été profondément impressionné par la façon dont Chris Krycho parle honnêtement de ses difficultés sans entrer dans le jeu des reproches. CoRecursive est l’un de mes podcasts préférés, car il explore le contexte complexe qui se cache derrière le code.

  • Attitude honnête de Chris Krycho et refus de chercher des coupables
  • Évaluation positive du podcast CoRecursive

• La migration d’Ember vers React ressemble à un cas adapté à la technologie qu’avait créée un client avec qui j’ai travaillé auparavant. Il avait conçu un langage appelé « Unhack » pour permettre des opérations de recherche et remplacement au niveau de l’AST. Il utilisait un langage où l’on spécifie un pattern dans le code source, puis un autre pattern pour le remplacer. J’ai cessé de travailler avec ce client il y a quelques années, donc je ne sais pas si cela existe encore aujourd’hui.

  • Exemple de migration technique d’Ember vers React
  • Langage « Unhack » permettant la recherche et le remplacement au niveau de l’AST

• Que la base de code de LinkedIn soit désordonnée n’a rien de surprenant quand on utilise le site. On clique sur une publication intéressante, on essaie d’en savoir plus sur son auteur, puis on appuie sur retour et le fil se recharge, faisant disparaître la publication. Si on essaie de faire défiler les messages reçus, toute la page web ralentit et il faut 10 à 15 secondes pour qu’une saisie soit prise en compte. Pourquoi reçoit-on 30 fausses notifications ? Ce sont de fausses notifications conçues pour forcer l’interaction des utilisateurs. L’algorithme de recommandation est lui aussi complètement affreux.

  • Difficultés d’utilisation du site web de LinkedIn
  • Fausses notifications et lenteur de réaction de la page web
  • Critique des problèmes de l’algorithme de recommandation