Ce que j’ai vécu en travaillant chez GitLab
(yorickpeterse.com)- Les six années passées chez GitLab, de son arrivée en octobre 2015 comme 28e employé jusqu’à décembre 2021, ont été marquées par un mélange de travail entièrement à distance, de chaos propre à une startup en hypercroissance, de problèmes de performance, de déploiement et de culture d’entreprise, ainsi que de burnout
- Aux débuts de GitLab, la plus grande plainte des utilisateurs concernait les baisses de performance et les pannes fréquentes, mais l’infrastructure de monitoring des performances était insuffisante, et il fallait en même temps créer des outils utilisables aussi par les clients en self-hosting
- En 2017-2018, au sein de l’équipe Database, il a créé un load balancer de base de données ; à la même période, une suppression de la base de données de production combinée à un échec des sauvegardes a entraîné environ 6 heures de perte de données et environ 24 heures de restauration
- Entre 2019 et 2021, l’équipe Delivery a unifié la structure de dépôts séparés de Community Edition et Enterprise Edition, réduisant un flux qui pouvait prendre jusqu’à 3 semaines entre un commit et le déploiement sur GitLab.com à quelques heures à une journée
- Les leçons tirées de GitLab sont que la scalabilité doit devenir une culture, qu’évaluer ce qui est « minimal viable » sans données est risqué, que faire coexister SaaS et self-hosting crée des exigences contradictoires, et que des déploiements rapides ainsi qu’une rémunération fondée sur le poste sont essentiels
Avant de rejoindre GitLab et les premiers rôles
- Avant de rejoindre GitLab, il travaillait dans une petite startup à Amsterdam, et l’entreprise était en difficulté au point de devoir sous-louer une partie de ses bureaux faute de financement
- Sur son temps personnel, il travaillait sur Rubinius et voulait le rendre suffisamment stable pour un usage en production ; il a donc commencé à chercher un poste lui permettant de faire un travail lié à ce sujet
- Il a découvert GitLab après avoir rencontré Sytse lors d’un meetup Ruby et d’un atelier Rails Girls ; après avoir envoyé un e-mail à l’été 2015, il a rejoint l’entreprise en octobre 2015 comme employé n°28
- Sa mission consistait à améliorer les performances de GitLab, avec 20 % de son temps de travail consacré à Rubinius
- En six ans, il est passé par plusieurs équipes avec une grande autonomie, a reporté à 10 managers différents et a vu GitLab passer d’une trentaine de personnes à environ 2 000
2015-2017 : travail à distance et création d’outils de performance
- Il a commencé chez GitLab le lendemain même de son dernier jour dans son entreprise précédente, passant d’un travail de bureau 5 jours sur 5 à du travail à distance 5 jours sur 5
- À l’époque, GitLab était déjà une entreprise totalement distribuée, mais avec une forte dimension sociale, avec de fréquents rassemblements et événements notamment à Amsterdam et Austin
- Durant cette période, GitLab a connu sa première phase de croissance rapide, recrutant environ 100 personnes ; l’entreprise est passée d’un peu plus de 30 employés à plus de 130, puis est redescendue dans les 80 avant de repartir à la hausse
- En parallèle, elle a aussi connu les problèmes typiques d’une startup en hypercroissance : graves problèmes de performance, pannes presque hebdomadaires et gestion immature
- « GitLab is slow » était la plainte principale des utilisateurs
- Sur Hacker News aussi, les plaintes sur la lenteur de GitLab revenaient souvent
- L’amélioration des performances était rendue plus difficile encore par le manque d’outils
- À l’époque, le monitoring se limitait à un compte d’essai New Relic, qui ne pouvait couvrir qu’1 ou 2 serveurs sur un total de 15 à 20
- Les données collectées ne représentaient donc pas fidèlement la situation globale
- GitLab exigeait que les outils utilisés soient également accessibles aux clients en self-hosting et, si possible, open source
- Pour améliorer les performances, il a donc fallu commencer par créer les outils eux-mêmes, ce qui a ensuite donné naissance à la fonctionnalité officielle GitLab Performance Monitoring
- Un profiler lourd pour l’environnement de développement, Sherlock, a aussi été développé pendant cette période
- GitLab a fini par reconnaître qu’une seule personne ne pouvait pas résoudre les problèmes de performance, et a créé une équipe Performance dédiée avec son propre manager et un petit budget de recrutement
- L’objectif était aussi de faire fonctionner Rubinius avec GitLab, mais cela n’a pas abouti ; entre les difficultés de maintenance et les controverses dans la communauté Ruby, le travail a finalement été abandonné
2017-2018 : équipe Database, load balancer et incident sur la base de production
- Après le chaos des 18 premiers mois, les performances se sont nettement améliorées et GitLab a commencé à traiter le sujet plus sérieusement
- L’équipe Performance a recentré son périmètre de l’amélioration générale des performances vers les performances de la base de données, devenant ainsi l’équipe Database
- Le budget de recrutement a été augmenté et un ingénieur infrastructure a été affecté pour aider sur la nouvelle configuration de base de données, entre autres
- La fonctionnalité clé développée à cette période a été le GitLab database load balancer
- Une présentation liée a été publiée sous le titre Scaling the GitLab database
- Les développeurs écrivaient leurs requêtes DB comme d’habitude, et le load balancer les routait vers le primary ou une replica
- Après une écriture, un mécanisme de sticking forçait l’usage du primary jusqu’à ce que les changements soient répliqués sur toutes les replicas
- Cela a eu un effet très positif sur les performances, et le fait que l’introduction ait été transparente reste ce dont il est le plus fier
- Le 31 janvier 2017, un incident a conduit à la suppression accidentelle de la base de données de production de GitLab.com
- L’incident a été rendu public dans GitLab.com database incident
- Le système de sauvegarde ne fonctionnait plus correctement depuis longtemps, et le système censé signaler les erreurs de sauvegarde ne fonctionnait pas non plus
- La restauration a été possible parce qu’une copie des données de production datant d’environ 6 heures plus tôt avait été placée dans l’environnement de staging
- La restauration a pris environ 24 heures, avec environ 6 heures de perte de données
- À la même période, GitLab voulait toujours faire du sharding de base de données, mais au vu des données et de l’analyse des ingénieurs, ce n’était pas la bonne réponse au problème
- Chez GitLab, les lectures représentaient environ 10:1 par rapport aux écritures
- Le volume de données stockées n’était pas non plus assez important pour justifier la complexité du sharding
- Un consultant a même indiqué que, pour des clients avec des charges et des volumes de stockage bien plus élevés, le sharding serait encore excessif
2019-2021 : équipe Delivery et amélioration du temps de déploiement
- Vers 2018-2019, fatigué du travail sur la performance et la fiabilité, il a rejoint la nouvelle équipe Delivery
- L’objectif de l’équipe Delivery était d’améliorer le processus de release et les outils de GitLab, dans un contexte alors très désordonné
- Entre l’arrivée d’un commit sur la branche main et son déploiement sur GitLab.com, il fallait en moyenne plusieurs jours, et dans le pire des cas jusqu’à 3 semaines
- Le plus gros goulot d’étranglement venait du fait que GitLab Community Edition et GitLab Enterprise Edition existaient dans des dépôts Git séparés
- Des merges manuels et des résolutions de conflits étaient régulièrement nécessaires
- Pour résoudre ce problème, plusieurs mois de travail ont été consacrés à fusionner les deux projets
- Ce travail a été présenté dans Merging CE and EE codebases
- L’équipe Delivery a fortement amélioré le processus de release, jusqu’à permettre de déployer des changements en quelques heures
- Passer d’un pire cas de 3 semaines à un pire cas d’environ une journée a représenté une amélioration majeure
- Cela dit, même cette vitesse n’était pas encore idéale
Évolution de la culture d’entreprise et départ
- 2018 a été la dernière année du GitLab summit centré sur les employés ; à partir de 2019, l’événement s’est transformé en un format plus proche d’une conférence traditionnelle orientée clients
- Ce changement se comprenait d’un point de vue financier, car les rassemblements de plus de 2 000 personnes coûtent très cher, mais il estime que l’expérience sociale y a perdu en intérêt
- La gestion des ordinateurs portables a aussi été une source récurrente de tensions
- GitLab a exigé ou envisagé d’exiger l’installation d’un logiciel de gestion à distance sur les machines de l’entreprise ou sur le matériel personnel utilisé pour accéder aux ressources GitLab
- L’outil proposé avait un caractère intrusif, pouvant servir par exemple à enregistrer l’activité des utilisateurs, et il jugeait les garanties contre les abus insuffisantes
- De nombreux retours des employés semblaient ignorés jusqu’à ce que des salariés clés mettent la pression
- GitLab a finalement choisi une solution de gestion de laptops basée sur SentinelOne
- Avec les changements culturels et personnels, sa motivation et sa productivité ont diminué, tandis que le stress augmentait
- Après le départ de son manager bien évalué vers un autre rôle et l’arrivée d’un nouveau manager à la tête de l’équipe, des tensions sont apparues et un performance enablement plan a été mis en place
- Le PEP était l’étape précédant un PIP, censée permettre de normaliser à nouveau la relation et le travail
- Présenté au départ comme un processus d’amélioration des deux côtés, il a eu le sentiment qu’en pratique l’accent était mis uniquement sur les changements attendus de sa part
- Prévu pour durer un mois, il a été prolongé d’un mois, puis jugé satisfaisant au bout de deux mois
- Il a ensuite eu le sentiment que GitLab et lui évoluaient dans des directions différentes, ce qui l’a amené à envisager son départ
- L’introduction en bourse de GitLab et le moment où il a pu exercer ses stock-options ont rendu possible son départ en décembre 2021
- À l’époque, aux Pays-Bas, l’exercice de stock-options était taxé à 52 % d’impôt sur le revenu sur l’écart entre le prix d’exercice et la valeur estimée, qu’il y ait ou non liquidité
- La charge fiscale était donc trop importante pour exercer avant l’IPO de GitLab
- La loi a depuis changé et permet de choisir entre l’imposition au moment de l’exercice ou au moment de la liquidité des actions
- En décembre 2021, il a quitté GitLab pour se consacrer à plein temps à Inko
Leçons tirées de l’expérience GitLab
-
La scalabilité doit faire partie de la culture d’entreprise
- Il estime que GitLab n’a pas suffisamment priorisé la scalabilité, et que ce problème persistait encore au moment de son départ
- Les principaux revenus de GitLab ne venaient pas de GitLab.com, mais des clients qui auto-hébergeaient GitLab Enterprise Edition
- GitLab.com coûtait bien plus d’argent qu’il n’en rapportait, ce qui poussait l’entreprise à privilégier le marché du self-hosting
- Beaucoup des problèmes de performance de GitLab.com ne concernaient pas directement de nombreux clients self-hosted
- Beaucoup de développeurs voulaient améliorer les performances, mais n’avaient ni le temps ni les ressources pour le faire
-
Les équipes doivent être guidées par les données et centrées sur les développeurs
- GitLab avait une forte culture pilotée par les product managers, et les fonctionnalités à implémenter étaient principalement décidées par les product managers et les directors
- Certaines décisions étaient pertinentes, mais d’autres donnaient l’impression qu’il fallait construire ce qui avait été vu comme une bonne idée sur Hacker News
- Il pense qu’une hiérarchie plus simple mise en place plus tôt, avec davantage de pouvoir donné aux team leads et plus d’interactions avec les utilisateurs, aurait pu produire de meilleurs résultats
- Il considère que le rôle d’un product manager devrait consister à contribuer techniquement à la construction du produit tout en faisant le lien entre l’équipe et les utilisateurs
-
Sans données, il est difficile de juger ce qui est « minimal viable »
- L’un des principes clés de GitLab était de toujours commencer par le minimal viable change
- Le problème était que chacun avait sa propre définition de « minimal »
- Certaines équipes considéraient la performance ou une bonne expérience utilisateur comme faisant partie du viable, tandis que d’autres n’y accordaient pas d’importance
- Il en est résulté, selon lui, des fonctionnalités peu utiles pour les utilisateurs
- une plateforme serverless non demandée et finalement abandonnée
- un support de gestion de clusters Kubernetes resté inutilisable pendant 3 semaines sans que personne ne s’en aperçoive
- une solution de chatops construite sur la CI au lieu d’utiliser une solution existante
- une fonctionnalité de gestion des exigences permettant uniquement la création et la consultation, sans modification ni suppression
- GitLab réalisait une enquête utilisateur trimestrielle et certaines équipes avaient accès à des données d’engagement utilisateur, mais d’après ses souvenirs et ses échanges avec d’anciens collègues, ces données étaient utilisées de manière ponctuelle plutôt qu’au cœur du workflow des équipes
-
Il est difficile d’exploiter en parallèle SaaS et self-hosting
- GitLab proposait à la fois des installations self-hosted et une offre SaaS
- Ces deux modèles diffèrent par leur structure de revenus, leurs exigences et leur façon d’appliquer les mises à jour
- Le SaaS nécessite des déploiements rapides et la capacité de traiter de grands volumes de données et de charge de travail sur une infrastructure centralisée
- La plupart des instances self-hosted sont bien plus petites qu’une offre SaaS, donc les problèmes et solutions du SaaS ne s’y appliquent pas tels quels
- Au final, de nombreuses parties de la plateforme devaient prendre en compte deux chemins de code, l’un pour le SaaS et l’autre pour le self-hosting
- Se concentrer sur le SaaS ou sur le self-hosting permettrait de consacrer toute l’attention à l’expérience propre au mode d’exploitation choisi
-
Plus de personnes ne garantit pas de meilleurs résultats
- GitLab a recruté massivement au fil des années et emploie aujourd’hui plus de 2 000 personnes
- Il ne connaît pas le nombre exact de développeurs, mais à en juger par la page des équipes, il l’estime à au moins plusieurs centaines
- Ajouter des personnes à un projet n’améliore pas nécessairement la productivité ni les résultats, ce qui rejoint l’idée de “The Mythical Man-Month”
- Sans données à l’appui, il estime que la plupart des entreprises n’ont pas besoin de plus de 20 développeurs, que certaines peuvent nécessiter 20 à 50, et que seules de très rares justifient 50 à 100
- Au-delà de 100 développeurs, il faudrait selon lui se demander si le périmètre produit n’est pas devenu excessif
- Cette réflexion concerne les développeurs logiciels ; des domaines comme la production de matériel sur mesure, les sales ou le support constituent selon lui des exceptions, car leurs coûts de synchronisation sont différents
-
Son évaluation de Ruby on Rails est ambivalente
- GitLab est construit avec Ruby et Ruby on Rails, et cette combinaison a fortement contribué à son succès
- Mais à mesure que le projet grandit et attire des contributeurs aux niveaux d’expérience variés, Rails facilite aussi la production de code peu performant
- Le problème emblématique est le N+1 query problem
- ActiveRecord de Rails fournit des mécanismes pour y remédier, mais ils reposent sur un opt-in
- Si le développeur l’oublie, les requêtes se font ligne par ligne et des problèmes de performance apparaissent
- Beaucoup des problèmes de performance résolus pendant les premières années de GitLab étaient des N+1 queries
- Ruby lui-même était aussi un excellent langage, mais sa forte utilisation du meta programming devient difficile à gérer dans les grands projets
- Go, Rust et Node.js peuvent être plus efficaces que Ruby, mais il estime qu’aucun framework n’est aussi puissant que Ruby on Rails
- Python et Django peuvent aussi être des options, mais risquent selon lui de rencontrer en partie les mêmes problèmes que Ruby et Rails
-
Le temps de déploiement est crucial pour la réussite de l’organisation
- Selon lui, le code devrait pouvoir être déployé dans l’heure au plus tard après avoir été pushé vers la branche ou le tag de déploiement
- Il a fallu environ 4 ans à GitLab pour s’en approcher, et il restait encore du chemin à parcourir
- Des déploiements rapides aident à réagir aux incidents
- Si un déploiement prend plusieurs heures, un hot-patch peut devenir nécessaire
- La rapidité des déploiements influe aussi sur la motivation
- Voir et utiliser réellement les changements que l’on a créés procure de la satisfaction
- Travailler plusieurs semaines sur un changement qui n’est déployé que deux semaines plus tard est démotivant
- Une organisation devrait être très agressive dans la réduction du temps de déploiement et de celui passé par la test suite dans le pipeline de déploiement
- L’essentiel n’est pas que tous les tests et déploiements passent sous un seuil fixe, mais que la capacité à déployer aussi vite que possible, dans les limites des exigences métier, soit une priorité
-
Les salaires fondés sur la localisation sont discriminatoires
- Les salaires chez GitLab dépendaient de plusieurs variables, dont la localisation
- Pour une entreprise avec des bureaux physiques devant recruter dans une zone précise, un ajustement selon le lieu peut se comprendre, mais pour une entreprise entièrement à distance, il n’existe selon lui aucune justification légitime à payer deux personnes ayant la même expérience et les mêmes responsabilités différemment uniquement en fonction de leur lieu de résidence
- À son départ, il touchait aux Pays-Bas un salaire d’environ 120 000 € bruts par an, soit environ 8 500 € par mois
- S’il avait vécu dans la Bay Area, il estime qu’il aurait gagné au minimum le double, voire davantage
- La solution consiste à rémunérer en fonction des exigences du poste, et non de la localisation du candidat
- 0xide Computer Company est citée comme exemple d’entreprise qui paie le même montant sans tenir compte du lieu
- Le sujet est abordé dans Compensation as a Reflection of Values
Conclusion
- Son passage chez GitLab a mêlé des expériences très positives et d’autres négatives
- Il éprouve une grande fierté pour ce qu’il a accompli dans plusieurs équipes et pour les personnes avec lesquelles il a travaillé
- Il regrette que la dernière année environ ait laissé un goût amer à l’ensemble de l’expérience
- Il ne regrette pas d’avoir travaillé chez GitLab et, s’il pouvait recommencer, il ferait certaines choses un peu différemment avec le recul
- Malgré ses défauts, il considère que GitLab reste bien meilleur que beaucoup d’autres entreprises et continue de le recommander comme un bon endroit où travailler
1 commentaires
Réactions sur Hacker News
Si une entreprise baissait les salaires en fonction de la couleur de peau ou du sexe, ce serait un énorme problème, mais la comparaison disant qu’il serait acceptable de les baisser selon le lieu de résidence mérite d’être davantage examinée.
Couleur de peau / sexe et lieu de résidence diffèrent sur deux points : la possibilité de les changer, et leur lien réel avec le travail.
Le lieu de résidence est lié au travail, car l’entreprise doit gérer la création d’une entité locale, la compréhension des systèmes juridiques et fiscaux, les fuseaux horaires, les frais de déplacement, etc.
On peut débattre du bien-fondé d’une rémunération par région, mais la comparer au racisme ou au sexisme revient à présenter GitLab comme une organisation raciste ou sexiste, ce qui coupe très vite court à la discussion.
S’il avait vécu dans la Bay Area, il aurait gagné plus du double, et il dit que c’est injuste uniquement parce que son lieu de résidence est différent, mais il n’y a pas vraiment de posture de victime à tirer de cela.
Cela ressemble plutôt à un argument fondé sur une mauvaise compréhension de l’économie.
Le salaire que je touche actuellement aux États-Unis est environ le double de celui que j’avais au Royaume-Uni, mais mon niveau de vie est similaire ; sur certains points il est pire, sur d’autres meilleur.
Même si l’auteur du billet initial était parti dans la Bay Area, il est très possible que son niveau de vie ait en réalité baissé malgré une rémunération plus élevée.
Il faut prendre en compte non seulement le revenu, mais aussi la protection sociale, les impôts et la culture, et je serais même prêt à accepter une forte baisse de salaire pour revenir en Europe afin d’y vivre plus confortablement.
La logique de la rémunération par région chez GitLab est expliquée ici : https://handbook.gitlab.com/handbook/total-rewards/compensat... et elle paraît assez raisonnable.
Si l’on versait jusqu’aux Philippines ou à l’Ukraine des salaires de la Bay Area, les gens pourraient se retrouver enfermés dans des menottes dorées, incapables de partir même quand ils devraient le faire, et finir en burn-out.
À l’inverse, si l’on versait partout un salaire médian mondial, on ne pourrait plus recruter en Californie ou à Londres.
L’idée qu’il ne faut pas de chefs de produit et qu’un produit ne devrait jamais avoir plus de 100 développeurs est également sujette à débat.
L’auteur du billet initial semble être un excellent ingénieur, très autonome, qui aurait probablement été bien plus heureux et plus performant dans une startup relativement petite.
S’il n’avait pas eu à attendre un changement de règles fiscales, il serait peut-être parti plus tôt et aurait pu écrire un témoignage positif.
On peut aussi se demander à quel point il aurait été difficile de quitter l’entreprise s’il avait touché à Amsterdam une rémunération de 300 k$ en plus des actions.
Si l’on imposait une rémunération identique partout dans le monde, les entreprises chercheraient probablement à recruter uniquement sur place, en raison des offsites, du même fuseau horaire et des avantages en matière de communication.
C’est d’autant plus vrai dans une conjoncture où il y a aussi beaucoup de candidats dans les zones à coût de la vie élevé.
Cela pourrait changer à l’avenir, mais il est utile d’observer la structure réelle des incitations.
Les entreprises qui recrutent dans d’autres pays assument aussi des risques, ce qui a également pour effet de laisser sur place des connaissances et les germes de futures entreprises.
Le fait de devoir aller au bureau donne aux salariés un pouvoir de négociation salariale lié au coût de la vie de la région, mais dans une entreprise et une culture entièrement remote, l’entreprise peut recruter n’importe où et verser des salaires proches du plus petit dénominateur commun.
Le travail à distance transforme tout le monde en quasi-indépendants en concurrence avec les talents du monde entier, tandis que le travail au bureau fait surtout concurrencer les gens avec d’autres personnes de la même région.
En tant que 28e employé, il rendait compte directement au CEO, puis des managers se sont progressivement intercalés au-dessus de lui ; l’un d’eux l’aurait placé en PEP, après quoi il aurait compris le signal et serait parti
C’est un déroulé assez standard, et c’est peut-être l’une des raisons pour lesquelles, dans les grandes entreprises, les gens ont du mal à accomplir de grandes choses
Même si on lance un projet en interne et qu’on le mène au succès, l’entreprise finit par y intercaler des gens au-dessus, et on peut se retrouver à devenir le n-ième employé sur le projet qu’on a soi-même lancé, avant d’entendre qu’on ne performe pas assez
Il veut seulement faire des choses amusantes et intéressantes et finit par avoir des opinions très tranchées sur des sujets qui ne sont pas essentiels ; quand un contributeur individuel proche du CEO ne reconnaît pas les choix d’un manager, cela devient un cauchemar à gérer
Il peut créer des problèmes en se déplaçant d’un sujet à l’autre sans assumer la responsabilité des décisions
La sécurité des terminaux et l’usage d’appareils personnels sont l’un des indices
Ce type de culture permissive ne passe pas à l’échelle à cause des coûts de conformité et de productivité du développement
Il est difficile d’arracher un vieux développeur à sa distribution Linux favorite, mais pour le travail il vaut mieux utiliser un ordinateur professionnel et laisser l’entreprise gérer les mises à jour
L’histoire des sauvegardes de base de données, c’est pareil : si c’est l’équipe base de données, les sauvegardes sont la priorité numéro 1
On ne peut pas faire passer « il n’y avait pas de sauvegardes » à la voix passive, et il semblait plus intéressé par des débats sur l’architecture de sharding que par le maintien quotidien du site
Quant à la conclusion selon laquelle GitLab n’aurait pas suffisamment investi dans les performances de son produit hébergé, si ce produit était fortement déficitaire, il peut être tout à fait logique de ne pas y allouer davantage de ressources
Il faut convaincre non pas avec de l’ingénierie « amusante », mais avec de vraies justifications business expliquant pourquoi ce travail est plus important et comment il rapporte de l’argent
Un manager et moi avons lancé ensemble un projet réussi, mais la direction y injecte avec avidité de la politique et des dilemmes sociaux, empile des couches de management et cherche à nous remplacer, lui et moi
J’ai appris qu’il ne faut pas trop se soucier sincèrement du travail, et j’ai l’impression que, pour cette raison, le projet va être abîmé puis démantelé
Il règne ici une ambiance qui suppose que cet employé était réellement très performant, qu’il n’avait pas besoin de manager et qu’il ne méritait pas de PEP, mais ce ne sont pas des hypothèses sûres
J’ai vu des employés des débuts, dans des startups en phase initiale, qui n’arrivaient pas à grandir au rythme de l’entreprise et de l’évolution du poste, ou qui ne le voulaient pas
On les garde souvent à cause du respect pour leurs contributions passées, de connaissances historiques difficiles à remplacer et de leurs relations avec les fondateurs ou avec d’autres premiers employés devenus dirigeants
Mais le fait d’être un employé des débuts et d’avoir participé à des projets importants au départ ne signifie pas qu’on reste la meilleure personne, ni même une personne adaptée, pour continuer à s’en charger
On peut être excellent pour faire tourner quelque chose avec des rustines, des tâches cron et des interventions manuelles, mais dans une grande entreprise ce mode opératoire peut ne plus convenir du tout
Si l’on n’arrive pas à s’adapter, ou si l’on en vient à en vouloir au fait de devoir travailler selon les méthodes d’une grande entreprise, on finit par faire plus de mal que de bien
Toutes les jeunes entreprises ont des employés des débuts qui ne grandissent pas avec elles, mais ce n’est ni la seule issue ni la plus fréquente
GitLab compte aussi beaucoup d’employés de longue date, mais on ne les entend pas dans les billets de blog pleins de ressentiment, donc il faut tenir compte du biais de sélection
J’utilise GitLab depuis longtemps, et le produit continue d’évoluer, donc je ne suis pas d’accord avec l’idée d’un produit stagnant
Ce n’est qu’au bout de trois ans, quand ils ont vu que les releases continuaient d’échouer, que cela est devenu un problème, mais cela ressemblait moins à mon influence qu’au résultat de quelqu’un ayant tapé sur Google « comment éviter les échecs de release »
Je ne connais pas la solution, et je revis encore la même chose aujourd’hui sur un autre sujet
Au départ, on faisait simplement ce qu’il fallait faire, mais plus tard chaque étape doit passer par de nouveaux postes de management intercalés au nom de la vérification qu’on ne fait pas la mauvaise chose
Cela arrive indépendamment des idées et contributions initiales qui ont permis à l’entreprise de grandir
Je me demande si c’est aussi lié au fait qu’il reste, autour de GitLab CI, des problèmes vieux de plusieurs années
Vu de l’extérieur, GitLab donne l’impression d’avoir complètement perdu la capacité de construire de grandes choses, et de ne pas vouloir corriger des bugs vieux de plusieurs années même lorsqu’ils se répètent sans cesse
Le passage expliquant que les employés étaient autorisés à utiliser leur ordinateur personnel est presque surprenant
Même si l’organisation est petite, elle devrait fournir un équipement appartenant à l’entreprise et exiger que tout le travail soit effectué dessus
C’est un gros avantage pour l’entreprise du point de vue du contrôle de la propriété intellectuelle, cela aide aussi beaucoup les employés à séparer temps de travail et temps personnel, et le coût n’est pas si élevé
On peut emporter partout exactement la pile d’outils souhaitée, et la capacité à effacer puis recréer rapidement l’environnement aide aussi à déboguer les problèmes du type « ça marche/ne marche pas sur ma machine »
À une extrémité, il y a l’approche fondée sur la mémoire ; à l’autre, la création de builds entièrement reproductibles partout avec https://nixos.org/
Entre les deux, il existe beaucoup d’options, et j’ai aussi vu des gens gérer un ensemble de fichiers Ansible qui installent ce qu’il faut sur
host: localhostJ’utilise la dernière version d’Ubuntu et je maintiens quelques scripts shell [1] qui installent 80 % de ce que je veux sur une nouvelle installation
Si l’on veut une approche plus scientifique, on peut installer quelque chose comme https://atuin.sh/ pour obtenir des statistiques sur les programmes réellement exécutés le plus souvent à partir de l’historique shell sur le long terme
[1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
Ce n’est pas une solution parfaite, mais au moins, avec du matériel d’entreprise, une fuite devient soit un acte malveillant, soit le résultat d’une incompétence ayant déplacé des données sensibles par un canal non autorisé
Si l’entreprise fait l’objet d’un procès, le contenu des appareils personnels peut lui aussi se retrouver visé par toutes sortes d’assignations
Exiger un appareil distinct n’apporte pas vraiment d’avantage à l’utilisateur en matière d’équilibre vie pro/vie perso ; c’est surtout peu pratique
La séparation entre travail et vie personnelle dépend surtout de ses habitudes, de ses capacités, et au final de ses décisions
Autrefois, je pensais que les salaires ajustés selon la région étaient une forme de discrimination, mais j’ai largement cessé de le croire
Au fond, cela revient à exiger un salaire de SF, et les gens en Inde se mettent alors à demander des salaires des Pays-Bas ou de SF
Cela risque fortement de créer une course vers le bas
Le fait simple, c’est que chacun gagnait de quoi bien vivre là où il se trouve
Si l’on veut davantage, on peut déménager, et si l’on ne le fait pas, c’est probablement pour une bonne raison
Tout le monde veut un salaire de SF avec le coût de la vie de l’Indiana ou de l’Inde, mais pour des raisons évidentes, cela tient difficilement debout
Une fois embauché, qu’on soit à San Francisco, en Pologne ou en Indonésie, on reçoit un salaire au niveau américain
Ces postes sont extrêmement compétitifs
C’est comme ouvrir les portes au monde entier en disant « montrez ce que vous savez faire », ce qui permet d’examiner un vivier de candidats et de talents bien plus vaste, parmi lesquels se trouvent beaucoup de profils exceptionnels, très intelligents et très déterminés, issus de pays plus pauvres
C’est ainsi que fonctionnent l’offre et la demande
En payant davantage, on finit généralement par recruter des candidats d’un niveau plus élevé
Je connais pas mal de gens qui travaillent à distance depuis différents États américains tout en touchant un salaire au niveau de SF
C’est évidemment possible
SF ne devrait pas non plus trop se croire à l’abri
Detroit a elle aussi été autrefois Motor City et Music City, un centre mondial de culture et de technologie, avant que ses compétences clés ne soient fragilisées par une main-d’œuvre moins chère et plus efficace ailleurs
Ce qui est demandé, c’est à travail égal, salaire égal
Si les membres d’une équipe font le même travail, mais que les autres reçoivent la totalité et qu’une personne n’en reçoit qu’une partie, il y a un vrai problème
La contribution à l’équipe ne dépend pas de l’endroit où l’on se trouve actuellement
Le temps passé dans les trajets ne change pas non plus les attentes en matière de livrables
Si l’emplacement du bureau coûte beaucoup trop cher, l’entreprise doit résoudre ce problème en trouvant un lieu moins onéreux ; il n’y a aucune raison que les employés subventionnent un mauvais choix d’implantation
Les 100k perçus par l’employé et le coût pour l’entreprise sont deux choses différentes
Selon les pays, les impôts, cotisations sociales et avantages supplémentaires à la charge de l’entreprise varient, et il faut souvent aussi une entité locale ou une structure d’activité virtuelle, ainsi que des ressources pour assurer la conformité au droit local
Je fais moi-même partie des salariés d’une multinationale payés selon les standards locaux tout en occupant un rôle global, et il y a bien plus d’éléments à prendre en compte qu’il n’y paraît
En gros, elle ajuste non pas en fonction du coût d’embauche, mais du coût de la vie, tout en visant des salaires équivalents
Les mauvais managers sont un fléau du secteur
À l’inverse, beaucoup de startups naissent parce que leurs fondateurs ont eu à subir de mauvais managers dans leur emploi précédent
Cela me rappelle l’histoire des traitorous eight et de Fairchild Semiconductors
Personnellement, je pense que je n’aurais peut-être jamais eu la motivation de créer ma startup si je n’avais pas eu, dans mon ancien poste, un manager non technique, politisé et vindicatif
Avec le recul, je me dis même qu’il aurait été préférable de rencontrer un manager aussi mauvais plus tôt dans ma carrière
Ce serait aussi bien de pouvoir trouver plus facilement des entreprises qui ont vraiment besoin de mes compétences et d’y changer de poste sans subir toute la lourdeur du processus RH
Certains affirment que l’ensemble du modèle de programmation de Ruby reposait sur l’idée que, la plupart du temps, on attend les entrées/sorties ou le réseau, donc que la vitesse du langage importait peu
Mais aujourd’hui, du côté de Node.js et de la JVM, il existe des modèles qui permettent de faire autre chose pendant l’attente des E/S ou du réseau, ou de traiter davantage de requêtes
En 2024, utiliser Ruby/Rails peut être du gaspillage, mais cela peut rester un bon choix pour des applications d’entreprise avec un nombre limité d’utilisateurs, lorsque la vitesse de développement est absolument cruciale, ou pour des prototypes rapides destinés à valider le marché
Rails est un excellent framework et sa productivité est remarquable, mais un projet Rails vieux de 2 à 3 ans est toujours difficile à maintenir
Un projet Rails n’est pas plus difficile qu’un projet Django ou Express
Quelle que soit la codebase, il faut de la discipline et un entretien constant pour éviter qu’elle ne se couvre de mauvaises herbes
S’il y a une faiblesse de Ruby et de Rails, c’est toujours la performance brute du langage ainsi que des besoins et une consommation mémoire plus élevés, ce qui les rend moins attractifs pour les tâches nécessitant une faible latence ou une faible empreinte mémoire
D’après mon expérience, ça fait surtout mal quand le trafic varie soudainement de façon importante, ou quand il y a énormément d’utilisateurs actifs avec des WebSockets, et côté WebSocket, anycable résout la plupart des problèmes
Mais très peu de produits atteignent réellement ces limites, et même lorsqu’ils y arrivent, il est possible d’y remédier
Stripe, GitHub et Shopify sont des exemples emblématiques où Rails est passé à l’échelle sans problème, de multiples façons
Le grand moteur de Rails, c’était la vision de DHH autour du bonheur des développeurs, étroitement liée à la vitesse de développement
S’il y a des discussions sur les E/S dans la communauté Rails, c’est parce que c’est important pour l’exploitation des serveurs web, pas parce que c’est l’unique ou principal critère de choix du langage ou du framework
Si l’objectif est de maximiser l’utilisation CPU d’un serveur web, Rails le permettait aussi en lançant plusieurs processus, une approche utilisée depuis longtemps, de façon similaire au lancement de plusieurs threads sur la JVM
C’est peut-être moins pratique, mais c’est un modèle utilisé depuis les années 90, et comme les requêtes web s’exécutent généralement de manière indépendante, la communication inter-processus n’est souvent pas un problème majeur
Généraliser en parlant de « gaspillage » est excessif
Écrire une application en Rust peut aussi être du gaspillage selon le contexte, tout dépend d’où se situe la pression
Au début, le vrai problème est bien plus souvent de ne pas réussir à livrer, et même ensuite, la vitesse des développeurs reste l’un des facteurs les plus difficiles à faire passer à l’échelle
En tant que CTO d’une entreprise qui utilise un backend Rails et un frontend React, la vitesse de développement est très importante, et celle de Rails reste un avantage majeur
Il y a aussi des problèmes de montée en charge, mais dans 99 % des cas, ce n’est pas un problème de Rails, c’est un problème de base de données
Je considère qu’une entreprise qui veut payer les ingénieurs en fonction de leur localisation pratique une autre forme de discrimination
Elle devrait payer selon les compétences de l’employé, pas selon son lieu de résidence
Les règles publiques disent de ne pas discriminer selon le sexe, la religion, l’orientation sexuelle, etc. ; alors la discrimination salariale selon la localisation est-elle juste ?
J’ai vu des amis occupant le même poste partir d’Europe vers l’Asie et être moins payés uniquement parce que leur localisation avait changé, alors qu’il s’agissait de la même personne et du même rôle
S’il déménage vers un marché moins compétitif où il lui est plus difficile de trouver un autre emploi, il est plus probable qu’il accepte un salaire plus bas
Même si le travail à distance donne l’impression de ne pas être lié au marché local, les gouvernements imposent souvent d’importantes barrières au recrutement international, ce qui fait que certains pays deviennent des marchés moins compétitifs
Si quelqu’un faisait le même travail dans la même entreprise mais a changé de pays et a vu son salaire baisser, c’est presque certainement pour cette raison qu’il a accepté cette baisse
Je pense qu’une entreprise devrait payer en fonction de la capacité de l’employé à vivre confortablement et en bonne santé, plutôt que selon une quelconque échelle de valeur universelle
Je pense qu’une telle valeur universelle est impossible
Dire qu’il faut payer uniquement selon les compétences détruit involontairement les communautés et aggrave la gentrification ainsi que l’érosion de la cohésion sociale par les inégalités
La localisation compte
Elles servent à offrir la même qualité de vie, le même type de logement, la possibilité de faire vivre une famille et d’envoyer ses enfants dans des écoles comparables
Comme le coût de ces choses varie selon les pays, le revenu nécessaire varie aussi
Une entreprise a besoin de certaines compétences, et elle ne paie que ce que le marché estime qu’elles valent, pas davantage
Comme le marché attribue un prix différent aux mêmes compétences selon la localisation, le salaire diffère lui aussi
La religion est une exception ambiguë, mais juste ou non, ce n’est pas de la discrimination
GitLab.com a toujours coûté bien plus qu’il ne rapportait, et si l’entreprise gagnait surtout son argent avec ses clients GitLab Enterprise Edition en self-hosted, on peut se demander si ne pas investir suffisamment dans la scalabilité était vraiment une erreur
En priorité, une entreprise devrait investir pour gagner de l’argent plutôt que pour en perdre
On peut soutenir, à un niveau plus abstrait, qu’un gitlab.com plus performant pourrait apporter plus de clients et de réputation, mais si l’activité réelle consiste à vendre du logiciel self-hosted, il est logique de concentrer les ressources de développement là-dessus
En pratique, j’ai acheté une licence GitLab, puis j’ai découvert que le coût par siège était identique que l’hébergement soit assuré par GitLab ou par nous, et je me suis demandé pourquoi c’était à nous de supporter les coûts d’infrastructure
Si GitLab.com doit être fait à moitié, alors soit il faut le faire correctement, soit il vaudrait peut-être mieux supprimer le produit et se concentrer à long terme uniquement sur les clients en self-hosting, comme GitLab Enterprise Edition
Mais personne dans la direction ne voudra probablement prendre une telle décision
Le produit se retrouve donc exploité de façon bancale
Pour les gens qui se soucient vraiment du produit lui-même, cette situation peut être frustrante
À chaque arrivée d’un nouveau développeur, il dira qu’« il faut accorder plus d’attention à la scalabilité », et les seniors répondront « oui oui, on sait… »
Si, d’un point de vue économique, un développeur à Amsterdam apporte la même valeur qu’un développeur de la Bay Area, il est probablement logique de lui verser le même salaire
Le prix du marché local pour un développeur à Amsterdam est plus bas, mais on construit une entreprise mondiale et on est en concurrence avec d’autres entreprises mondiales
Même si, aujourd’hui, on peut encore obtenir un développeur à Amsterdam à prix réduit, au final un concurrent finira par proposer un montant plus proche de la valeur apportée, ou bien cette personne partira travailler à son compte
Les entreprises les plus solides finiront probablement par offrir une rémunération indépendante de la localisation aux talents
Au bout du compte, ce qui compte, c’est la valeur apportée
Si l’on veut vendre à de grandes entreprises qui accordent de l’importance aux performances et à la fiabilité, tout en traînant une grosse base de code Ruby comme GitLab, on paierait sans doute ce type de profil plus de 120 k€ par an
Comme la plupart des ingénieurs qui privilégient les performances, la sûreté des types et la fiabilité ne s’intéressent pas à Ruby, la valeur de marché de cette combinaison de compétences est clairement plus élevée
Je ne sais pas si cela correspond aux 500 k$ annuels de la Bay Area, mais les entreprises solides qui veulent recruter des talents de tout premier plan finiront par les perdre si elles ne lient pas la rémunération à la valeur apportée plutôt qu’à la localisation
Le temps nécessaire pour déployer du code est, à mon avis, l’un des indicateurs les plus importants — peut-être le plus important — pour maintenir la vitesse des développeurs quand une startup passe à l’échelle
Le changement de contexte est l’une des activités les plus coûteuses du quotidien des développeurs, et pourtant l’une des plus faciles à ignorer
Les managers aiment souvent organiser le planning de l’équipe en fonction de leur propre agenda, mais cela perturbe fréquemment le « maker schedule » des contributeurs individuels
Beaucoup d’organisations s’en rendent compte et se concentrent sur le coût du changement de contexte lié au planning, mais pour les développeurs, le temps entre le build et le déploiement est tout aussi important, voire davantage