2 points par GN⁺ 2024-12-24 | 1 commentaires | Partager sur WhatsApp
  • Julius, que le narrateur a croisé à plusieurs reprises entre l’université et le monde du travail, est un personnage sûr de lui et très à l’aise à l’oral, mais dont la compréhension technique et les contributions réelles suscitent constamment des doutes
  • Dans un projet en C, il a parlé d’une machine virtuelle C ou affirmé à un client qu’un serveur sur Internet n’avait pas d’adresse IP, multipliant les propos incompatibles avec les concepts de base
  • L’équipe devait à chaque fois relire son code et ses documents, puis rattraper jusqu’aux promesses faites aux clients, tandis que les managers et les RH appréciaient surtout sa présentation et son attitude
  • À chaque changement d’entreprise, Julius a renforcé son CV et sa rémunération, entretenant sur LinkedIn et dans les médias une image de grand contributeur
  • Quand l’entreprise a déployé plusieurs logiciels d’IA au nom de la hausse de productivité et interdit de les désactiver, le narrateur a eu de plus en plus de mal à supporter un environnement de travail qui lui donnait l’impression d’être entouré de dizaines de Julius

Première rencontre avec Julius à l’université

  • Julius était un camarade rencontré à l’université, calme, gentil et toujours souriant
  • Il ne coupait pas la parole, acceptait qu’on le corrige et répondait aux questions sans hésiter
  • Il assistait à tous les cours et demandait souvent les notes des autres étudiants en disant vouloir les comparer aux siennes

Première fissure révélée dans un projet en C

  • Une équipe d’étudiants a mené un projet consistant à développer un logiciel système relativement complexe en langage C
  • Julius participait à toutes les réunions, mais le narrateur ne se souvient pas l’avoir vu écrire une seule ligne de code
  • Au final, Julius semblait s’être occupé de la mise en forme du rapport, et ce travail était très bien fait
  • Julius s’est aussi chargé de la présentation finale, qu’il a menée avec beaucoup d’assurance
  • Pendant l’exposé, il a parlé de la machine virtuelle C utilisée pour le projet et montré des captures d’écran sans rapport, avec un logo inconnu
    • Le C est un langage compilé, il n’a donc pas besoin de machine virtuelle
    • Parler d’une machine virtuelle C revient à parler du carburateur d’une voiture électrique
  • Le narrateur s’est levé pour interrompre Julius, puis a improvisé en faisant passer cela pour une blague
  • Parmi les professeurs, certains trouvaient Julius brillant, d’autres estimaient qu’il manquait de compréhension fondamentale ; il a échoué à certaines matières, mais ils ont fini par obtenir leur diplôme ensemble

Retrouver Julius en entreprise

  • Quelques années plus tard, le narrateur occupait un poste à responsabilités dans une grande entreprise quand son manager a annoncé que les recruteurs avaient trouvé un profil rare pour l’équipe
  • Le nouvel arrivant était Julius, son ancien camarade d’université, toujours aussi charismatique et sûr de lui
  • Il n’était resté longtemps dans aucune de ses entreprises précédentes, généralement un an ou moins
  • Son CV était impressionnant et donnait l’impression d’une expérience couvrant de nombreux domaines de l’informatique
  • Plus tard, le narrateur a découvert que Julius avait été recruté à un salaire deux fois supérieur au sien malgré un niveau hiérarchique comparable, avec en plus des bonus dont il ignorait l’existence

Le coût de relecture assumé par l’équipe

  • Au début, le narrateur a formé Julius aux projets et aux processus internes, puis lui a confié du travail
  • Julius posait beaucoup de questions, mais elles n’étaient pas toujours pertinentes
  • Il écrivait du code et des documents, répondait à des questions sur divers sujets, mais ses livrables étaient parfois bons, souvent médiocres et, dans certains cas, complètement absurdes
  • L’équipe a fini par comprendre que toutes les contributions de Julius devaient être intégralement relues et corrigées par un autre membre
    • Lorsqu’il s’agissait d’un domaine hors de l’expertise de l’équipe, une relecture externe était nécessaire
    • Une règle officieuse est apparue : les documents de Julius devaient être relus par deux personnes avant de sortir de l’équipe
  • En revanche, il excellait dans la mise en forme, les présentations et l’animation des réunions, au point que le manager le considérait comme un grand contributeur de l’équipe

L’équipe qui rattrapait les promesses faites aux clients

  • Le narrateur a tenté sans succès d’expliquer à son manager que Julius ne comprenait pas le travail de l’équipe
  • L’équipe envoyait parfois Julius dans des réunions inutiles pour l’occuper quelques heures, mais cette stratégie avait ses limites
  • Après que Julius a promis à un client qu’il serait possible de simplifier l’interface en un seul bouton accomplissant exactement ce qu’il voulait, l’équipe a dû enchaîner une semaine de réunions de gestion de crise pour apaiser un client déçu
    • Ils ont expliqué que satisfaire des besoins complexes avec un seul bouton reviendrait pratiquement à développer une machine capable de lire dans les pensées
  • À un client inquiet du piratage, Julius a affirmé que, pour des raisons de sécurité, les serveurs connectés à Internet n’avaient pas d’adresse IP
    • Le « I » de IP signifie Internet
    • Internet est un réseau interconnecté d’ordinateurs possédant des adresses IP
    • Dire qu’on est sur Internet sans adresse IP revient à dire qu’on peut être joint par téléphone sans numéro
  • L’équipe a fait en sorte que Julius ne rencontre jamais un client seul
  • Un développeur a directement signalé le problème au manager, mais celui-ci y a vu de la jalousie ; le développeur a été réprimandé puis a quitté l’entreprise peu après

Le départ de Julius et l’expansion de sa carrière

  • Julius a quitté l’entreprise en disant avoir reçu une offre impossible à refuser
  • Le manager et les RH ont sincèrement regretté son départ
  • Son compte LinkedIn était très actif et recevait des centaines de commentaires
  • L’année passée avec l’équipe a été résumée sur LinkedIn comme une expérience remarquable qui, sans mentir sur les faits, donnait l’impression qu’il avait énormément contribué à l’équipe
  • Par la suite, Julius est devenu vice-CEO d’une startup rachetée par une multinationale, puis CEO par intérim
  • La presse économique a parlé de lui, avant qu’il ne rejoigne ensuite l’équipe d’une personnalité de rang ministériel

Les « dizaines de Julius » devenus logiciels d’IA

  • Le narrateur essayait d’oublier Julius, mais après avoir rencontré un commercial, son manager s’est enthousiasmé pour un logiciel d’intelligence artificielle censé améliorer la productivité
  • L’entreprise a déployé plusieurs outils d’IA
    • un logiciel d’IA pour aider à coder
    • un logiciel d’IA pour aider à rechercher des informations
    • un logiciel d’IA pour résumer et rédiger des e-mails
  • Le narrateur n’a pas la possibilité de désactiver ces outils
  • Il a l’impression d’être entouré en permanence de dizaines de Julius, et a le sentiment que chaque clic de son ordinateur ou chaque notification de son téléphone vient de Julius
  • Son manager lui dit que la productivité de l’équipe baisse dangereusement et qu’il faut utiliser l’IA plus efficacement
  • Il ajoute que les concurrents utilisent sûrement les IA les plus récentes et qu’un consultant a été embauché pour installer une nouvelle IA de gestion du temps et de la productivité
  • Quand le narrateur fond en larmes en disant « encore un autre Julius », son manager répond que Julius lui manque aussi et qu’il aurait aidé à traverser cette période difficile

1 commentaires

 
GN⁺ 2024-12-24
Avis sur Hacker News
  • J’ai vu plusieurs fois des profils optimisés pour leur carrière un peu comme Julius, mais c’est difficile à expliquer.
    Quand on rejoint une nouvelle équipe, il y a un ingénieur senior, appelons-le Pete, présenté comme le génie qui a créé la première version du nouveau produit. Mais quand on ouvre la base de code, on découvre un tas de boue spaghetti qui tient à peine debout pour une démo, sans documentation ni tests, et il faut déjà du temps rien que pour comprendre. Pourtant, la direction se dit : « Pete l’a fait en deux semaines, pourquoi l’ajout de fonctionnalités prend-il autant de temps ? »
    Même si l’on explique la situation à la direction, elle aime tellement Pete qu’elle n’accepte pas les critiques. Pete est vu comme quelqu’un qui a sauvé l’entreprise à plusieurs reprises, et ce sont plutôt les autres qui sont jugés incapables de le suivre. Au final, pendant que ceux qui restent paient le coût du bazar créé par Pete, lui passe à un projet plus gros, puis part avec une promotion et une augmentation avant que les problèmes n’apparaissent. Ce schéma est tellement spécifique qu’il ressemble à un comportement intentionnel ; je me demande comment on appelle ce genre de personne.

    • Ah, je le connais, ce type… c’est moi.
      Ça fait une vingtaine d’années que je fais du « travail lié aux ordinateurs » dans de petites entreprises : câblage réseau, support, programmation, tâches administratives, un peu de tout. Dans mon poste actuel, il m’arrive même de conduire un chariot élévateur dans l’entrepôt.
      En dix ans dans la même entreprise, j’ai construit une grande partie de son écosystème logiciel, mais vu par un professionnel, c’est une machine de Rube Goldberg tenue au ruban adhésif. Rien n’a été correctement planifié, implémenté ou testé, et il arrivait souvent que le patron débarque le vendredi après-midi avec « la fonctionnalité X / le problème Y à résoudre / le bug Z, c’est vraiment urgent ». Et bien souvent, la cause était un effet de bord d’un correctif urgent précédent.
      Mais je l’ai fait, et ça tourne. J’ai souvent dit au patron que « ce système ferait mieux d’être traîné derrière l’entrepôt et abattu pour mettre fin à ses souffrances », mais enfin, il tourne. Peut-être que je dois maintenant apprendre la technique à la Pete : quitter le navire et récupérer promotion et augmentation.
    • John Osterhout appelle ce genre de personne une tornade tactique. Autrement dit, un programmeur qui ne développe que tactiquement.
      Son livre, “A Philosophy of Software Design”, fournit un bon vocabulaire pour réfléchir à l’aspect technique du problème. Le chapitre 3, “Working Code isn't Enough”, est particulièrement utile et peut donner suffisamment de langage pour commencer à traiter le problème sans attaquer les personnes.
      Sur la psychologie de ces personnes, je n’ai pas trouvé de bonne source unique, mais il est clair que le système dans lequel elles évoluent fournit des boucles de rétroaction qui renforcent leur comportement. Des éléments de modèles de personnalité comme les Big Five, par exemple l’ordre/la discipline, doivent aussi jouer un rôle.
    • Ce n’est pas vraiment un problème Pete, c’est plutôt un échec de management.
      Si l’on a demandé à Pete de produire une démo aussi vite que possible, alors il a fait ce qu’on lui demandait. En pratique, dans beaucoup de cas, ce n’est même pas forcément mauvais que la direction donne ce genre d’instruction, parce que trouver l’adéquation produit-marché peut généralement passer avant la dette technique.
      En revanche, la direction doit savoir combien de temps et d’efforts il faut pour transformer une démo bricolée en système réellement exploitable.
    • J’ai vu un schéma similaire dans de grandes entreprises. Ce sont généralement des ingénieurs intermédiaires que les managers apprécient parce qu’ils « font avancer les choses », alors qu’en réalité ils ressemblent davantage à des bulldozers qui écrasent le code, avec à côté un collègue qui valide en disant « ship it ».
      La raison pour laquelle ils peuvent « aller vite », c’est que les autres essaient de limiter la complexité, tandis qu’eux percent des trous dans les abstractions et passent au travers. Puis, une fois promus, ils deviennent le Pete du commentaire initial.
    • Le « sens de quitter le navire avant que les problèmes ne se révèlent » n’est pas une astuce, mais une compétence manipulatoire acquise avec le temps.
      C’est une manière de faire briller sa propre réputation au prix du sacrifice des collègues, et les gens comme Pete sont vraiment détestables.
  • La fin se voyait venir depuis un moment, mais le texte est bien écrit et je l’ai lu avec plaisir. En tant que maître de conférences en informatique, je me reconnais pas mal dans cette histoire.
    Les grands modèles de langage sont un problème pour les étudiants à plusieurs niveaux. Au début, ils semblent meilleurs qu’eux et sapent leur confiance ; cela les pousse à vouloir utiliser l’outil plutôt qu’apprendre ; et, au bout du compte, cela commence à devenir une prophétie autoréalisatrice. Je m’inquiète de l’impact que cette technologie aura à l’avenir. Une société remplie de Julius ne peut pas durer longtemps.

  • Excellent, drôle, et beaucoup trop parlant.
    Peut-être que je deviens trop cynique en approchant de l’âge mûr, mais ce phénomène me semble venir du fait que, dans les entreprises, les personnes qui ont le dernier mot sont des gens du business. Les entreprises existent au service de l’ego et des objectifs de ceux qui les dirigent, et dans cette perspective, produire des résultats business ou impressionner la hiérarchie compte souvent davantage que la compétence technique ou l’honnêteté. Julius fait cela bien mieux que les tristes programmeurs qui savent seulement bien coder.
    J’aimerais croire qu’une autre voie est possible, mais le monde semble avoir de fortes incitations à aller dans cette direction. Pour beaucoup de gens, le mieux est peut-être un emploi pas trop cassé, qui respecte les limites personnelles et paie correctement. On peut s’estimer heureux de travailler dans ce genre d’endroit tout en continuant à rêver d’autres possibilités.

    • La réfutation classique, c’est : « s’il existait une meilleure alternative, par exemple une entreprise dirigée par des gens qui comprennent les bases de ce qu’ils construisent réellement, elle battrait en concurrence les business people paresseux et égocentriques ».
      En réalité, beaucoup de ces entreprises sont apparues et ont dominé leurs concurrents, mais on les a ensuite vues se faire infiltrer par les mêmes profils business qu’elles avaient vaincus.
      Ce qui est frustrant, c’est de voir cela tout en ne pouvant rien y faire. Il y a vraiment beaucoup de Julius. Mais le travail n’a pas besoin d’être toute votre identité. Si vous avez eu la chance d’être au bon endroit au bon moment, vous avez peut-être vécu une expérience qui vous marquera toute votre vie ; sinon, ce n’est pas grave. Vous pouvez encore faire un travail dont vous êtes fier, et il vaut mieux ne pas trop se laisser emporter par tout ça. Julius, lui, n’a peut-être pas cette option.
    • Qu’on l’aime ou non, Elon Musk a assez bien montré que le marché peut aussi récompenser un leader technique autiste qui met tout le monde en colère.
      Une vidéo récemment devenue virale où Andrej Karpathy décrit le style de management d’Elon : https://www.youtube.com/watch?v=aSiJ4YTKxfM
      Bien sûr, les défauts d’Elon sont bien connus, et il ne faut pas le vénérer. Mais je reste sceptique face à l’idée que les pratiques de management traditionnelles seraient inévitables à cause des incitations.
  • Je suis devenu beaucoup plus heureux depuis que j’ai commencé à m’adapter un peu plus au côté Julius dans ce domaine
    Les développeurs et les ingénieurs peuvent ajuster leurs outils très précisément à leurs besoins, si bien qu’ils ont tendance à supposer que les autres peuvent en faire autant. Mais ce n’est pas vrai. La plupart des gens vivent au milieu d’un assemblage hétéroclite de solutions techniques qui fonctionnent mal, et ont donc des attentes extrêmement faibles quant à la façon dont un logiciel devrait fonctionner
    Une fois que j’ai compris ça, je suis devenu Julius. Les dirigeants ne se soucient pas de savoir comment ni pourquoi un logiciel fonctionne ou ne fonctionne pas. Ils veulent des maximes de développement personnel et du charisme
    Le passage où l’on envoie Julius en réunion pendant que les autres règlent le problème m’a particulièrement parlé. Les réunions ne servent à rien, mais c’est là que tout le monde se serre la main et tisse des relations. Les gens qui savent bien se fondre dans ce cadre font bonne impression
    La différence, c’est que je pense quand même être plutôt bon dans mon travail. J’admets simplement que les seules compétences de développeur de haut niveau ne suffisent pas à construire une carrière. Elles peuvent même être un obstacle. C’est peut-être une réaction cynique

    • Si les dirigeants ne se soucient pas de savoir comment ni pourquoi un logiciel fonctionne ou non, et ne veulent que des maximes et du charisme, c’est qu’il y a quelque chose qui cloche dans le secteur, dans la façon de sélectionner les managers, et plus largement dans la manière dont la richesse, l’influence et les opportunités sont réparties
  • Ça vaut vraiment la peine d’être lu, et c’est très bien écrit
    Il me semble que le texte dit à la fois que les vrais Julius existent, et que les mécanismes utilisés pour faire entrer l’IA au travail sont les mêmes que ceux dont se servent les Julius de ce monde pour réussir

  • C’était vraiment excellent. J’ai croisé pas mal de Julius tout au long de ma carrière
    L’univers semble produire et faire tourner ce genre de personnes en abondance, et il les apprécie probablement beaucoup

  • Dans les domaines non techniques, on appelle ce genre de personnes des lèche-bottes
    C’étaient d’anciens sportifs, ou des gens qui avaient de la répartie, étaient beaux, parlaient bien ou avaient un côté arrogant. Tout le monde savait qu’ils étaient incompétents, mais comme ils étaient sympathiques, ils semblaient toujours s’en sortir
    Quand ils se retrouvaient dépassés sur un projet, il y avait toujours quelqu’un pour venir les sauver, ce qui augmentait la charge de travail des autres et leur valait de l’antipathie. En général, le moment où ils devenaient utiles, c’était quand ils étaient promus : à partir de là, nous pouvions reprendre le contrôle du projet, et ils devenaient paradoxalement utiles

  • Nous aussi, nous avons embauché un Julius. Un an plus tard, les personnes productives ont été licenciées, les grands bavards sont restés, le chiffre d’affaires n’a pas augmenté, et nous avons dépensé plus que nous n’avons gagné
    Il reste six mois de trésorerie à l’entreprise. Julius, mais pourquoi fais-tu ça ? La présentation était incroyable, on aurait dit un film

    • Dans ce genre de situation, le problème ne vient-il pas plutôt des managers qui l’ont embauché et ont mal compris sa contribution, plutôt que des Julius eux-mêmes ?
  • Julius ressemble à une application répétée du principe de Peter, à ceci près qu’il n’a jamais atteint un niveau de compétence au départ
    C’est quelqu’un de raffiné, mais incompétent

  • C’était vraiment bon et agréable à lire
    J’ai rencontré pas mal de Julius à l’université et au travail, et à chaque fois, cela m’a souvent amené à me demander pourquoi je devrais me soucier de ce que je fais