La fixation délirante d’Elon Musk sur le code Twitter.

Vendredi après-midi, nous avons appris qu’Elon Musk avait demandé à n’importe quel employé de Twitter qui “écrivait réellement un logiciel” d'”envoyer un e-mail [him] un résumé à puces de ce que votre code a accompli au cours des ~6 derniers mois, ainsi que jusqu’à 10 captures d’écran des lignes de code les plus remarquables.”

En tant que vice-président de la technologie chez Slate, ma première pensée en lisant ceci a été “quelle énorme perte de temps d’ingénierie”. Juste après “trop ​​de puces à lire”.

Les “commits de code” dans le développement de logiciels sont des modifications que les ingénieurs apportent à une base de code. En règle générale, les ingénieurs logiciels utilisent des systèmes appelés “contrôle de version” qui suivent les modifications qu’ils apportent ainsi que des notes sur les raisons pour lesquelles ils les ont apportées (comme “Suivre les modifications” dans Microsoft Word). Les commits d’isolement peuvent être assez ennuyeux. Par exemple, voici l’un des miens d’il y a quelques jours :

Lignes de code informatique.
Greg Lavallée

Comme vous pouvez le voir, ce commit de code a changé le libellé vrai dans mauvais pour placer une annonce dans l’une de nos newsletters. Des trucs vraiment accrocheurs!

Chaque commit n’est pas une ligne. Certains commits sont énormes ! Pour envoyer une fonctionnalité vraiment importante à un site ou à une application, vous pouvez modifier des milliers de lignes de code. Bien sûr, la plupart des ingénieurs en logiciel vous diront que c’est une pratique terrible. Idéalement, les modifications de code gèrent le moins de lignes possible afin que, lorsque les produits sont définitivement bogués, il soit plus facile de rechercher quel commit a causé le problème et d’isoler le problème.

Si nous plissons les yeux et mettons notre chapeau de PDG de trop nombreuses entreprises, nous pouvons imaginer ce que Musk espérait avec sa demande. C’est comme une auto-évaluation pour les ingénieurs en logiciel. Si vous ignorez la partie “code commits”, vous pouvez la lire comme s’il demandait aux ingénieurs de parler de leurs réalisations. Mais nous ne pouvons pas ignorer cette partie «code commits» car il l’a suivie en demandant des captures d’écran.

Être jugé sur votre capacité à vous auto-promouvoir est une erreur américaine de longue date, mais ajouter un jugement aux captures d’écran de votre code par un gars qui ne s’est jamais engagé dans votre base de code est un niveau supplémentaire de stupidité. L’idée de regarder une capture d’écran d’un morceau de code et de l’utiliser pour juger des capacités d’un ingénieur pose de nombreux problèmes.

Premièrement, Musk n’a pas le contexte de la raison pour laquelle le code a été écrit au moment où il a été écrit et qui l’a écrit. Le code écrit à la dernière minute pour répondre à certaines demandes des annonceurs sera très différent du code résultant de mois de travail acharné pour reconcevoir un système. Il est peu probable que le code écrit par un ingénieur junior soit aussi concis que le code d’un développeur senior.

Un code qui n’a subi qu’une seule itération est susceptible d’avoir l’air pire qu’un produit plus mature qui a été développé au fil du temps. Souvent, le premier commit pour une fonctionnalité est la version la plus simple qui permet à une équipe produit de tester si elle fonctionne, et non si elle est évolutive ou à l’épreuve des balles.
. Les ingénieurs devraient-ils montrer cela à Musk, ou recherche-t-il un code mature qui lui fait dire “wow” ?

Il y a aussi la question du style de codage. Comme nous le disons dans le développement de logiciels, il y a plus d’une façon de le faire (ou TMTOWTDI, prononcé tim-toady). En pratique, les équipes développent souvent des manières préférées de faire les choses afin qu’elles ne deviennent pas une douzaine de variantes des mêmes concepts de base. Certaines équipes sont à l’aise avec la brièveté où beaucoup est fait dans une seule ligne de code (comme les compréhensions de liste en Python, par exemple). D’autres équipes présenteront l’intelligence lors de la révision du code comme difficile à lire et un piège pour les programmeurs plus juniors lorsqu’ils seront initiés à la base de code. Musk comprendra-t-il ces compromis en parcourant les centaines ou les milliers de captures d’écran sur son téléphone alors qu’il voler dans son jet privé?

Encore plus encombré, dans la plupart des bases de code réelles, les mêmes fichiers sont touchés par des dizaines, voire des centaines de développeurs différents au fil du temps. Une capture d’écran est probablement le conglomérat de centaines de codes réalisés sur une douzaine d’années.

Ce dernier point est peut-être le plus gros écueil dans l’approche de Musk et de dire ce qu’il ne semble pas comprendre sur Twitter. Le code est écrit par des équipes. Musk sollicite des présentations de particuliers. De nombreux ingénieurs de Twitter y travaillent depuis longtemps avec les mêmes coéquipiers. Ils ont développé des amitiés, des cultures et des façons de faire.

Vendredi soir, j’ai écrit ceci, cette réunion a peut-être déjà eu lieu. Je ne peux pas m’empêcher de me demander comment c’est arrivé. A-t-il demandé aux ingénieurs de se tenir face à face et d’expliquer leurs captures d’écran ? Sont-ils toujours admis dans le bâtiment ? En a-t-il vraiment tiré quelque valeur ou était-ce un test d’honnêteté ?

En octobre, il y a eu des rapports selon lesquels Musk aurait permis aux ingénieurs de Tesla de revoir le code de Twitter. Faire venir des ingénieurs seniors qui écrivent des logiciels pour les voitures parce qu’ils sont des “programmeurs 10x” ne rend pas nécessairement une équipe plus productive. En fait, cela peut avoir l’effet inverse parce que ceux qui connaissent mieux le produit se sentent mis à l’écart ou comme s’ils devaient perdre leur temps à essayer d’expliquer le contexte de toutes leurs décisions de codage à quelqu’un qui a probablement du mal à taper du code et n’écoutera pas leurs explications.

Musk suit clairement ce qu’il sait (code) et non ce qu’il devrait faire (culture). Supposer qu’il peut lire le code des ingénieurs logiciels de Twitter et l’utiliser pour n’importe quel type de prise de décision est de l’orgueil pur et simple. Mais qu’attendons-nous ? C’est Elon Musk. Il continuera probablement à parcourir Twitter en poussant quiconque sur son chemin à repousser. Il regardait une salle pleine d’ingénieurs et les jugeait silencieusement parce qu’il était sûr qu’il était le plus intelligent de la salle tout en confondant intelligence et sagesse.

Semblable à Musk a déclaré en décembre 2017, j’adore Twitter. J’espère qu’il ne disparaîtra pas. Je ne suis toujours pas sûr de bien comprendre ce qui doit être corrigé à ce sujet. Mais s’il pense que Twitter va résoudre ses problèmes ou que le code était le problème de Twitter en premier lieu, il a quelques surprises devant lui. lui.

Future Tense est un partenariat entre Slate, New America et Arizona State University qui examine les technologies émergentes, les politiques publiques et la société.

Leave a Reply

Your email address will not be published. Required fields are marked *