- Pendant environ cinq ans chez LinkedIn, Chris Krycho a été en charge de l’infrastructure frontend et de l’expérience développeur de l’application web desktop, où il a été confronté au conflit entre modifier en toute sécurité une codebase massive et les exigences d’exécution rapide côté produit
- À son arrivée, l’application desktop de LinkedIn comptait environ 2 millions de lignes de JavaScript ; elle a ensuite grandi jusqu’à devenir un monorepo d’environ 3,2 millions de lignes, rendant les migrations difficilement réalistes sans automatisation et sans minimiser la charge pour les équipes produit
- La modernisation d’Ember et l’adoption de TypeScript visaient à réduire les erreurs et à améliorer la qualité de développement ; l’analyse selon laquelle la migration vers TypeScript pourrait réduire d’au moins 25 % le volume d’erreurs dans les logs applicatifs a servi d’argument en interne
- Le plan de migration d’Ember vers React a mis en collision la stratégie progressive et automatisée sur 3 à 5 ans de l’équipe de Chris avec une approche visant à repenser beaucoup plus radicalement les méthodes existantes pour permettre des expérimentations produit plus rapides
- Lors de la gestion d’une panne majeure, les limites des alertes, de l’observabilité, de la résilience et des code reviews sont apparues ; Chris est parti en estimant que l’orientation de l’organisation, qui donnait la priorité absolue à la vitesse, ne correspondait pas à ses valeurs
Ce qu’il a fait pendant 5 ans et la taille de la codebase
- Chris Krycho a rejoint LinkedIn fin janvier 2019 et y a travaillé pendant environ 5 ans
- Son domaine n’était pas l’infrastructure serveur, mais l’infrastructure frontend et l’amélioration de l’expérience développeur de l’application web desktop de LinkedIn
- Il a dirigé de grands projets de modernisation JavaScript sur l’application desktop responsable de l’expérience LinkedIn.com sur navigateur non mobile
- L’application de son entreprise précédente faisait environ 150 000 lignes, mais le frontend LinkedIn comptait déjà environ 2 millions de lignes de code à son arrivée
- Sur cette même application, 150 à 200 ingénieurs committaient chaque trimestre, et des dizaines d’équipes continuaient à déployer un seul produit
- À son arrivée, il y avait moins de 100 ingénieurs en remote sur plusieurs milliers au total, et Chris faisait figure d’exception en travaillant à distance depuis le Colorado
Comment migrer une codebase de 2 millions de lignes
- L’un de ses premiers gros chantiers a été d’introduire la syntaxe moderne des classes JavaScript dans du code basé sur Ember
- Il existait un problème de mélange entre les classes Ember existantes et les classes JavaScript natives dans la chaîne d’héritage, appelé en interne « Zebra Striping »
- À cette échelle, une migration devait être automatisée autant que possible
- Corriger manuellement 2 millions de lignes pouvait prendre plusieurs mois ou plus
- Il était difficile de demander aux équipes produit d’arrêter le développement de fonctionnalités pour se consacrer uniquement à une nouvelle syntaxe
- LinkedIn disposait d’un processus de horizontal initiatives couvrant plusieurs équipes, avec un principe opérationnel consistant à maintenir la participation des équipes produit sous les 10 %
- L’équipe de Chris a jugé qu’il serait plus facile de faire accepter une approche où l’équipe infra génère automatiquement des PR, tandis que les équipes produit se chargent des reviews et des smoke tests, plutôt qu’un modèle où les équipes produit exécutent elles-mêmes les codemods
- Les travaux liés à Ember ont duré au total 18 mois ; l’essentiel a été réalisé en 6 mois, mais certains retards d’équipe ont laissé une longue traîne
La logique de réduction d’erreurs utilisée pour convaincre d’adopter TypeScript
- Après la modernisation d’Ember, l’équipe de Chris a pris pour cible suivante le grand volume d’erreurs JavaScript côté frontend
- LinkedIn utilisait sa propre infrastructure de logging au lieu d’un service externe, en raison de l’ampleur de ses logs d’erreur
- LinkedIn avait dépassé 1 milliard d’utilisateurs l’année précédente et, au moment du départ de Chris, le monorepo atteignait environ 3,2 millions de lignes
- la moitié était du code de test
- la moitié était du code de production
- L’équipe de Chris a analysé séparément les catégories d’erreurs que TypeScript pouvait détecter
- Certaines erreurs ne pouvaient pas être captées par TypeScript, mais l’équipe estimait qu’une fois la migration achevée, le volume de logs applicatifs parmi les millions d’erreurs JavaScript quotidiennes pourrait être réduit d’au moins 25 %
- Le document rédigé par Chris sur la transition vers TypeScript a circulé de manière répétée entre ingénieurs et managers
- le problème à résoudre
- les bénéfices attendus
- la compétitivité en matière de recrutement
- les éléments de comparaison avec d’autres priorités
- Par la suite, Chris a joué un rôle d’expert interne pour aider sur les problèmes de typage TypeScript les plus difficiles
D’Ember à React : transition progressive contre refonte générale
- LinkedIn était le plus grand utilisateur d’EmberJS au monde, mais le travail de Chris a fini par évoluer vers la planification d’un passage d’Ember à React
- Les dirigeants de haut niveau estimaient que le coût de migration de LinkedIn était trop élevé et ralentissait la vitesse produit
- Le plan de l’équipe de Chris reposait sur une stratégie progressive et automatisée sur 3 à 5 ans
- renforcer l’automatisation afin que les équipes produit aient à peine besoin de s’arrêter
- séparer puis migrer successivement la build pipeline, la couche de données, la couche de routing, le système de réactivité et la couche de vue
- terminer par le remplacement du système de rendu et de réactivité d’Ember par celui de React
- Une autre équipe visait plus directement le problème de vitesse
- l’objectif était de réduire le temps entre l’idée et l’A/B test de plusieurs mois à quelques semaines
- elle considérait comme problématiques les stacks différentes entre web desktop, web mobile, iOS et Android, ainsi que leurs longs cycles
- Chris a perçu l’approche de cette équipe comme proche d’une attitude « finger guns mode »
- il avait le sentiment qu’elle ne traitait pas suffisamment les problèmes qui surgissent lorsqu’on passe d’un support pour quelques dizaines de personnes à un support pour plusieurs centaines d’ingénieurs
- selon lui, beaucoup de réponses aux questions revenaient à dire que « ce ne sera pas un problème »
- Le plan sur 3 à 5 ans de l’équipe de Chris n’a pas reçu un bon accueil de la part du leadership
- le plan lui-même était long et peu enthousiasmant
- l’équipe l’avait aussi présenté comme « le moins mauvais des choix », ce qui le rendait moins convaincant
Les problèmes de résilience révélés par une panne
- Après son retour des vacances de Noël, un incident a empêché certains utilisateurs de voir les pages de LinkedIn.com pendant jusqu’à environ 20 minutes
- Le problème était lié à un service de prerendering qui exécutait du code client via Node.js pour agréger des données backend et les livrer plus rapidement
- Ce service souffrait d’une fuite mémoire, et les conteneurs étaient redémarrés lorsqu’ils dépassaient leur limite mémoire
- Plusieurs facteurs se sont combinés pour aggraver la panne
- les alertes sur les kills liés à la mémoire étaient insuffisantes
- le nombre de conteneurs pouvant redémarrer simultanément était défini via une clé dans un fichier YAML
- cette valeur était valide du point de vue du typage, mais incorrecte pour ce système
- la configuration était en pratique proche du nombre total de services en cours d’exécution
- Quand un gel de déploiement durait longtemps, comme pendant un long week-end, les services épuisaient leur mémoire à peu près au même moment et redémarraient tous ensemble, devenant incapables de traiter les requêtes utilisateur
- Quand certains serveurs tombaient, la charge augmentait sur les serveurs restants, dont l’usage mémoire montait alors plus vite, provoquant des pannes à l’échelle du datacenter
- En parallèle, un travail de rightsizing visait à réduire l’usage CPU et mémoire du fleet, ce qui avait diminué la marge disponible
- Chris et d’autres ingénieurs estimaient qu’il fallait de meilleures alertes, une meilleure observabilité et une meilleure résilience
- même si un serveur Node partait en dérive, il ne devait pas faire tomber le processus hôte
- il serait plus sûr de tuer uniquement le processus Node, d’émettre une alerte, puis de redémarrer
- ils ont aussi envisagé un chemin de repli basculant vers des fetch côté client si le service tombait
Le conflit autour de l’idée que la code review ne suffit pas
- Des réunions de suivi de l’incident avaient lieu plusieurs fois par semaine, pour partager l’avancement et faire remonter l’information aux dirigeants
- Le manager d’une autre équipe a pris en charge la réponse à l’incident et ajouté des effectifs, ce que Chris a interprété comme une dynamique de défiance envers ses réponses et celles de son équipe initiale
- Au cours du processus, un ingénieur senior a demandé : « Pourquoi la code review n’a-t-elle pas empêché ça ? »
- Chris estimait que la code review seule ne pouvait pas garantir qu’un tel incident ne se reproduise pas
- les humains font des erreurs
- il est difficile pour un ingénieur junior de remettre en question le caractère raisonnable d’une valeur de configuration dans la PR d’un SRE très senior
- un système doit fonctionner en sécurité non seulement lors du meilleur jour d’un ingénieur senior, mais aussi lors du mauvais jour d’un ingénieur junior
- Pour Chris, le software engineering inclut aussi la conception de systèmes qui soutiennent les ingénieurs chargés d’obtenir des résultats produit
- Les incidents techniques et la communication organisationnelle n’étaient pas séparables ; comme le dit Charity Majors, à haut niveau il n’existe pas de problèmes purement sociaux ou purement techniques
Leadership, culture du remote et conflit de valeurs
- Chris estimait que son équipe et son approche avaient été éclipsées par la proposition de l’autre équipe
- Le plan de cette autre équipe a pris de l’ampleur jusqu’à englober une remise à plat des applications desktop et mobile, et plus largement une reconsidération de la manière dont LinkedIn construit ses produits
- Chris voulait améliorer cette proposition, mais avait le sentiment que ses inquiétudes et ses questions n’étaient pas réellement prises en compte
- Il dit qu’un manager lui a dit : « Tu es trop idéaliste, tu ne te soucies pas assez du compte de résultat, et tu dois changer de valeurs »
- Chris estimait que le travail à distance avait eu un impact sur la création de relations
- LinkedIn avait une forte culture du présentiel, et beaucoup de relations se nouaient naturellement à la cafétéria ou dans les couloirs
- il avait le sentiment qu’un contact physique répété avec des ingénieurs seniors ou des dirigeants pouvait faire une différence en situation de conflit
- Chris reconnaît aussi, avec le recul, avoir eu lui-même des faiblesses dans la construction de relations
Pourquoi il est finalement parti
- Chris estimait qu’une grande partie des problèmes de la codebase existante venait d’une surestimation de la vitesse et d’un manque de correction ou de suppression des voies secondaires
- Si la vitesse devient la valeur suprême, on peut gagner en rapidité au départ, mais cela devient difficile à maintenir avec le temps
- Il dit avoir connu le burn-out dans un emploi précédent, avec de fortes migraines, des douleurs abdominales, l’impossibilité de faire du sport, des pleurs soudains et des attaques de panique
- Il pensait que s’il continuait à travailler chez LinkedIn, il passerait ses journées à essayer de ne pas être en colère
- Comparant la situation à la tentative de faire changer de cap à une énorme organisation avec une petite barque à rames, il a décidé de ne pas consacrer plusieurs années à une manière de travailler et à un travail auxquels il ne croyait pas
- Chris dit avoir appris chez LinkedIn ce que représente une application de 3 millions de lignes, une migration TypeScript dans une grande entreprise et les problèmes d’ingénierie à grande échelle, mais il est parti pour chercher un travail aligné avec ses valeurs
1 commentaires
Avis sur Hacker News
Je pense que le passage le plus intéressant du podcast était le feedback selon lequel il était « trop idéaliste, ne se souciait pas assez du résultat financier et devait changer ses valeurs ». J’avais déjà eu cette impression avant de lire, et on dirait qu’il a reçu au fil du temps des retours précieux, mais qu’il les a délibérément ignorés.
Ce qui est difficile pour un senior staff engineer, ce n’est pas d’« avoir raison » en soi, mais de créer, à l’échelle de toute l’organisation, l’alignement nécessaire autour de la bonne solution. Comme j’ai participé en 2019 à la réécriture de facebook.com en React, cette histoire m’a semblé particulièrement intéressante.
J’ai réussi à communiquer dans une certaine mesure, mais pendant mon passage chez LinkedIn, je n’ai pas vraiment réussi cet alignement. C’est en partie ma responsabilité, et en partie celle de LinkedIn aussi.
Cela dit, dans ce cas, « trop idéaliste » signifiait en réalité « ne te préoccupe pas de ce qui ne contribue pas directement au résultat financier », et je rejette cela jusqu’au plus profond de moi. Le résultat financier est important, mais l’expérience utilisateur, l’expérience développeur et l’éthique fondamentale de ce que nous construisons le sont aussi.
Dans une organisation, on défend du mieux possible ce que l’on pense être juste, puis quelqu’un d’autre, ou un groupe de décision, décide s’il est d’accord. Accepter le résultat, chercher un compromis ou partir, c’est à moi de le décider, et j’ai fait les deux au cours de ma carrière.
Dans une licorne connue, il y avait un senior staff engineer très intelligent, raisonnable et bienveillant. Il poussait pour faire passer de la v2 à la v3 un framework utilisé à hauteur de 50 millions de dollars par an, et comparé au passage de Python 2 à Python 3, c’était un changement tout à fait mineur.
L’enquête montrait qu’on pouvait, en gros, espérer une amélioration de performance de 10 %, mais la direction ne voulait pas « perdre du temps sur une mise à niveau de version ». Finalement, cet ingénieur a poussé seul le sujet, a produit une version de prévisualisation en moins d’un mois, puis a migré en moins de deux mois une partie des travaux à fort impact, économisant plusieurs fois son propre salaire.
Une fois les coûts politiques et d’ingénierie initiaux payés, tout le monde a voulu migrer, et un an plus tard, quand le déploiement était terminé, la hiérarchie au-dessus avait été à moitié décimée par des licenciements et des départs, mais cet ingénieur et la migration étaient toujours là. Parfois, un staff engineer n’est pas obstiné : il peut être la seule personne saine d’esprit dans un monde devenu fou.
J’ai été à ce genre de poste et j’ai pu choisir de ne pas participer, mais ce n’est pas toujours possible.
J’ai vu des gens convaincre la direction sans avoir la meilleure idée ni le meilleur plan, simplement grâce aux bonnes relations, au bon déjeuner et aux bons mots.
« Tu es trop idéaliste et tu ne te soucies pas assez du résultat financier » peut aussi être une étiquette utilisée pour écarter quelqu’un. Surtout si elle vient d’une personne qui a justement su se vendre, elle et ses idées, auprès de la hiérarchie.
Personnellement, dans une organisation plus petite que Facebook mais comptant des centaines d’ingénieurs et une grande base de code, j’ai mené plusieurs changements et mises à niveau à grande échelle autour de Ruby, Rails et Postgres, et la méthodologie décrite par Chris est très raisonnable et correspond aussi à une façon de faire que j’ai trouvée fructueuse.
Je suis d’accord pour dire qu’un rôle de leadership n’est efficace que s’il repose sur la confiance et le respect. Bien sûr, pour que cette confiance soit utile, il faut aussi avoir réellement raison. Avancer dans la mauvaise direction, ce n’est pas avancer.
Je n’ai jamais travaillé chez LinkedIn ni connu sa base de code, mais j’ai vu à plusieurs reprises des bases de code et des structures organisationnelles et politiques qui y ressemblaient de façon inquiétante. C’est pourquoi, en général, je défends l’approche finger gun
Une réécriture façon finger gun peut aussi être bien réalisée. S’il existe plusieurs clients qui font la même chose, on peut en prendre un comme base pour une autre plateforme ; et même en repartant de zéro, on peut faire quelque chose de propre, rapide et concis
La clé du succès est de confier le nouveau système à une petite équipe de vétérans qui soient à la fois experts du domaine et experts techniques. C’est controversé, mais je pense que tous les succès, y compris pour les problèmes ordinaires d’exploitation et de maintenance, viennent de là. Le reste ne fait que ralentir
Le gros problème que répètent la plupart des dirigeants techniques, c’est de confier le prochain grand système aux personnes les moins expérimentées. J’aimerais aussi entendre une interview symétrique du côté finger gun
C’est naturel, puisqu’il s’agit de choses éprouvées qui ont déjà fonctionné pour eux, mais ce n’est pas toujours le meilleur choix. De plus, même quand une équipe de vétérans lance un projet, il est rare qu’elle reste jusqu’au bout ; et si l’on n’a pas à assumer le résultat ou les retombées, il est trop facile de prendre des décisions
Un plan doit contenir des options réalistes pour traiter les obstacles, et cela ne se limite pas aux choix techniques : cela inclut aussi le temps et les capacités des personnes qui feront le travail. Par exemple, si un plan prévoit que plusieurs équipes exploitent des serveurs, cela peut être techniquement possible, mais si les équipes n’ont ni le temps ni les compétences, ce n’est pas une option réaliste
À l’inverse, planifier un itinéraire sophistiqué qui évite tous les obstacles est aussi une mauvaise idée. Au moment d’arriver, les obstacles peuvent avoir bougé, et il peut y en avoir sur la route qu’on ne connaît pas encore. Si l’on n’a prévu qu’un seul chemin, on se retrouve bloqué là
Cela dit, ce que l’on voit ici est une description de podcast qui résume comme une bande dessinée un débat d’architecture complexe ; il est donc impossible de savoir quel homme de paille était le plus proche de la réalité chez LinkedIn
D’après lui, le conseil d’administration avait dit à toute l’ingénierie que, désormais, dans aucun projet, personne ne pourrait dicter les détails à qui que ce soit
On dirait que Chris a fait plusieurs choix malheureux. Il a proposé un plan sur 5 ans, a orienté l’incident vers le blâme plutôt que vers le leadership, a davantage parlé du problème qu’il ne l’a résolu, et semble aussi avoir manqué de travail relationnel
J’ai de l’empathie pour Chris, tout en ayant l’impression qu’il ne savait pas comment obtenir des résultats dans cet environnement. Et ce n’est pas grave. Tout le monde n’a pas à apprendre à travailler dans des nœuds bureaucratiques ; les startups sont plus simples de ce point de vue
Il y a une raison pour laquelle les grandes entreprises perdent leur tranchant avec le temps, et pour laquelle un dirigeant finit par se retrouver dans une salle de réunion face à une perte de -10 % sur un an, sans un seul vice-président honnête à ses côtés
Quand on se retrouve dans ce genre de situation, on perd psychologiquement le nord. J’ai l’impression d’avoir raison, mais est-ce vraiment le cas ? Les gens autour de moi sont-ils vraiment aussi incompétents, et aussi peu intéressés par le fait d’apprendre de leurs collègues ?
Quelques années plus tard, une fois parti, on regarde en arrière : ces gens ont été licenciés ou sont partis, l’organisation ne sait toujours pas faire X, et l’agilité et les compétences des équipes arrivées ensuite existaient bel et bien
D’un côté, cela peut relever de l’arrogance, d’une incompétence politique ou d’une incapacité à s’adapter à une culture de travail pathologique. De l’autre, cela peut aussi être la bonne réaction
Si une organisation traverse une phase culturelle pathologique, il est peut-être normal que des personnes talentueuses, prudentes et passionnées deviennent folles à cause de cela. Ceux qui ne deviennent pas fous dans ce contexte sont peut-être indifférents à la productivité et à la croissance, voire pire, une perte nette
Ce genre d’environnement devient donc un psychodrame. La situation est-elle vraiment aussi mauvaise, ou est-ce moi qui réagis de façon excessive ?
Mais c’était aussi le seul plan que nous avions le sentiment de pouvoir présenter alors que la direction disait : « Même pour la migration que nous vous demandons, ne ralentissez absolument pas le rythme d’itération produit »
Je ne sais pas très bien ce que signifie l’idée selon laquelle j’aurais orienté l’incident vers le blâme. J’ai au contraire essayé de faire l’inverse, et je n’ai pas accusé la personne qui avait abaissé le seuil mémoire ni celle qui avait saisi une mauvaise valeur par faute de frappe dans le YAML. J’ai simplement insisté pour qu’on ne laisse pas la cause racine en place jusqu’à ce que la prochaine personne fasse tout exploser à nouveau, et pour qu’on la corrige réellement
Je ne comprends pas non plus l’idée selon laquelle j’aurais seulement parlé du problème au lieu de le résoudre. Je ne me suis simplement pas longuement vanté à l’antenne de ce que j’avais accompli ; les problèmes que j’ai résolus là-bas l’ont été plutôt correctement
Le manque de construction de relations était, comme je l’ai dit dans l’épisode, mon plus grand point faible. J’avais de bonnes relations avec les ingénieurs, mais j’ai largement échoué à construire une confiance politique, surtout avec les niveaux supérieurs du management
Cela dit, je ne pense pas que cela s’explique simplement par le fait que je ne savais pas comment obtenir des résultats dans cet environnement. Je voyais une manière de réussir, mais j’ai aussi choisi de ne pas agir d’une manière à laquelle je ne croyais pas. Beaucoup d’ingénieurs que je respecte acceptent de danser la danse politique pour ce en quoi ils croient, mais pas pour ce en quoi ils ne croient pas
Je travaille actuellement chez LinkedIn. Le rôle de Chris et son podcast semblent porter sur Ember et le développement web front-end, et le nombre de lignes de code ainsi que le build dont il parle correspondent probablement à voyager-web, l’application web monolithique principale de LinkedIn.
LinkedIn a d’autres systèmes avec des millions de lignes de code et des builds longs : la couche intermédiaire, la stack de données hors ligne, le système de métriques, et des choses comme KafkaKafkaKafka.
Malheureusement, un build de 17 minutes est plutôt pas mal. 17 minutes sans panne temporaire d’infrastructure, c’est même très bien.
Il n’y a quasiment aucune notion de test à l’échelle de l’entreprise, et pas de QA non plus. Les ingénieurs poussent des projets à moitié cuits pour les mettre dans leur dossier de promotion, puis passent à la suite.
En utilisant les outils internes au quotidien, il fallait résoudre soi-même beaucoup trop de problèmes ; les ingénieurs qui essayaient simplement de travailler devenaient de fait la QA.
Il faudrait au contraire chercher à rendre les builds plus rapides, ou à rendre l’infrastructure de build plus rapide et moins chère.
Au moins dans l’équipe où j’étais, la qualité du code faisait l’objet d’une attention assez forte, et la culture continuait de s’améliorer. Cela dit, j’ai travaillé une fois sur voyager, et j’en garde le souvenir d’un cauchemar.
Une réécriture à grande échelle est risquée même sur une codebase maîtrisable, et les résidus qui restent semblent ne jamais disparaître complètement. Qui aurait envie, des années plus tard, de gagner des points en réécrivant une page de paramètres oubliée dans un coin ?
J’ai vu tellement de tentatives de ce genre qu’on pourrait croire qu’il existe un framework pour réécrire des codebases, mais non. Les outils de modification automatique de code exigent de la cohérence, or rares sont les endroits qui l’ont conservée. Les patterns de code évoluent tellement avec le temps qu’on a l’impression de lire les cernes d’un arbre.
Fondamentalement, nous mettons du code dans des boîtes, nous réorganisons ces boîtes, puis nous affirmons de façon raisonnable qu’une disposition est plus efficace qu’une autre. Alors pourquoi n’avons-nous pas trouvé de meilleure méthode ? L’automatisation fonctionne au niveau du code, mais pas au niveau des boîtes.
C’est un exemple de la loi de Conway à l’œuvre. Comme l’organisation n’a pas changé, il est probable qu’elle recrée la même soupe de code.
Pour avoir été dans le même bateau, les initiatives d’ingénierie positives doivent venir du haut, avec un sponsor très haut placé, et descendre ensuite dans l’organisation. On ne peut pas transformer l’organisation de bas en haut, et c’est bien l’organisation qui finit par produire la codebase.
La loi de Conway ne change pas, mais elle ne dépend pas forcément uniquement de l’organigramme officiel. On peut la gérer en créant des structures de communication temporaires entre les bons leads techniques et des managers compétents.
Mais il suffit de quelques managers techniquement faibles ou désireux de bâtir leur petit royaume au milieu pour que tout se casse facilement la figure ; selon le stade de vie de l’entreprise, la loi d’airain de la bureaucratie de Pournelle peut même signifier qu’il n’y a déjà plus d’espoir.
Par exemple, si tous les développeurs sont médiocres, on leur donne un framework populaire. C’est une excuse pour éviter de traiter les problèmes de personnes, comme laisser des enfants gérer une crèche.
Si l’on veut l’excellence, il faut fixer des standards élevés avec des règles qui imposent la responsabilité, la propriété, ainsi que récompenses et conséquences. Ce n’est pas compliqué, mais cela exige de la fermeté au sommet et de ne pas craindre le conflit.
Cela dit, vous pourriez perdre tout espoir qu’une entreprise comme Microsoft construise quelque chose sans ensuite le gâcher.
J’ai passé 12 ans chez LinkedIn. Tristement, l’organisation d’ingénierie actuelle est très loin de ce qu’elle était autrefois. L’époque où Kevin Scott dirigeait l’ingénierie était vraiment excellente en comparaison.
Des millions de lignes de JavaScript, c’est en soi l’incarnation de la bloat
J’ai réfléchi à réimplémenter quelque chose comme LinkedIn, ou plus exactement à créer ma base de données de contacts sans fonctionnalités « à la Facebook »
Le problème, c’est comment faire migrer mes contacts en masse. Au-delà de la bloat, le principal problème de Microsoft LinkedIn, c’est qu’il ne permet pas d’exporter les informations de contact ; pour une plateforme de contacts, c’est une fonctionnalité indispensable
https://queue.acm.org/detail.cfm?id=2567673
Résumé : https://www.pixelstech.net/article/1395463142-Why-does-Linke...
LinkedIn est passé à Node début 2010
Cela dit, en voyant les réactions dans ce fil, je me demande si ce chiffre n’était pas erroné
Je ne l’ai pas fait avec LinkedIn, mais c’est une astuce un peu sale que j’utilise pour exporter des listes de participants à des conférences publiées sur des sites web publics. Ça peut dépendre du contexte
J’ai été impressionné par la manière dont Chris Krycho parle honnêtement de ses difficultés, sans tomber dans le jeu des reproches. CoRecursive est l’un de mes podcasts préférés parce qu’il traite du contexte complexe derrière le code
Ça ressemble presque toujours à un rôle de leadership informel difficile. Un poste où l’on est « responsable » de quelque chose, mais avec peu, voire aucune autorité sur le reste de l’organisation
S’il existe un vrai leadership technique, il peut être absent, ou bien présent depuis longtemps et, même en tant qu’« expert du système », ne plus être vraiment au contact des problèmes réels. Déjà vécu, et plus jamais pour moi