Carnet de notes

Catégorie : Technique

  • Lecture d’Anne Vella : « Dear Soft­ware Engi­neer: It’s Time to Reclaim Your Role »

    Cita­tions d’Anne Vella :

    I totally agree that soft­ware engi­nee­ring should be a lot more than just writing code. When I studied compu­ter science at univer­sity, they taught us how to elicit requi­re­ments, write user stories, design user inter­faces and apply UX prin­ciples, archi­tect complex systems, create test plans, execute test cases and so much more. The whole shebang.

    De mon temps on appe­lait ça de façon mépri­sante les pisseurs de code. Et pour­tant, à cause de la spécia­li­sa­tion, je vois énor­mé­ment d’in­gé­nieurs tomber dans cette caté­go­rie de « déve­lop­peur expert ».

    J’en ai même vu s’in­di­gner qu’on arbitre trop souvent en faveur du produit et des utili­sa­teurs plutôt qu’en faveur d’une qualité de code interne.

    Rien qu’à dire ça je sais que je vais avoir quelques réac­tions assez fortes.

    Personne n’a raison mais ça devient des métiers diffé­rents.

    Steve Yegge recently wrote a follow-up to his contro­ver­sial article The Death of the Junior Deve­lo­per, refra­ming his posi­tion as The Death of the Stub­born Deve­lo­per. He talks about how if you’re not adop­ting Chat-Orien­ted Program­ming, or CHOP, you’re getting left behind

    Je ne joue­rai pas à qui va devoir chan­ger.

    Je suis convaincu que les déve­lop­peurs « produit » vont devoir chan­ger de façon de travailler. Pour autant, le besoin ne va pas dispa­raître, loin de là. Les juniors vont vite avoir des super-pouvoirs. Les seniors qui se reposent un peu trop sur leur savoir acquis, sur la complexité du code set sur le besoin de renou­vel­le­ment perma­nent de techno vont eux avoir du soucis à se faire parce que leur valeur ajou­tée va deve­nir faible.

    On ne rempla­cera pas les déve­lop­peurs « code » experts. L’IA tant vantée n’est quand même qu’un outil statis­tique et je ne la vois pas de si tôt créer du code profond tel qu’on peut en trou­ver dans les biblio­thèques de code qui forment les briques de base. On aura besoin de personnes qui comprennent le fonc­tion­ne­ment de tout ça pour savoir quoi faire (éven­tuel­le­ment assis­tés par de l’ia s’ils le veulent). Là ce sont les juniors qui vont avoir du mal à trou­ver une place.

    Pour être franc je ne sais pas si tout ça est vrai­ment neuf. L’IA va juste démul­ti­plier un effet déjà exis­tant, mais peut être au point de rendre certains posi­tion­ne­ments très diffi­ciles à tenir.

    So dear soft­ware engi­neer, please take heed. If you’re not a “product engi­neer” and have specia­li­sed in writing code, AI may indeed take your job. But this isn’t just a warning – it’s an oppor­tu­nity. It’s time to reclaim your role and return to what soft­ware engi­nee­ring was always meant to be: a craft that combines tech­ni­cal exper­tise with problem-solving, user empa­thy, and busi­ness acumen. The future belongs to those with curio­sity who can see beyond the code.

    Mes propos semblent peut être trop alar­mistes, ou trop futu­ristes. J’ai l’im­pres­sion qu’on passe des paliers très vite.

    Je ne saurais trop conseiller aux déve­lop­peurs qui veulent prévoir leur avenir de sauter sans filet et de passer au CHOP et BATON décrits dans le billet cité.

    Si ça n’ac­cé­lè­rera pas grand chose aujourd’­hui, savoir comment utili­ser ses outils correc­te­ment demande un chan­ge­ment de para­digme et donnera plusieurs longueurs d’avance d’ici quelques années au plus.

    Si vous avez vu le sex appeal des déve­lop­peurs « no code » (non, il n’y a pas contra­dic­tion), ça va vite de démul­ti­plier.

    C’est une croyance de ma part mais elle est très forte.

    Oui, je sais. Il y a aussi à côté d’énormes enjeux éner­gé­tiques. J’ai­me­rais bien qu’on puisse les igno­rer mais je ne le crois pas. Je ne les mets pas de côté.

    Main­te­nant consi­dé­rant le coût des ingé­nieurs, celui de l’usage de ces outils, la valeur qu’on en tire, le futur sera quand même celui là. On peut refu­ser mais il faudra au mieux se prépa­rer à oublier les périodes fastes du point de vue emploi et salaire, pour ceux qui trou­ve­ront un emploi.

    Je n’ai pas la solu­tion à tout ça. Je me contente d’ob­ser­ver.

  • Prude IA

    Le contrôle des réseaux et de l’in­for­ma­tique par les États-Unis me saute à la figure de plus en plus souvent.

    Il y a peu, je lis que les États-Unis inter­disent TikTok si l’ac­ti­vité n’est pas reven­due à un tiers. L’enjeu c’est est celui de la sécu­rité natio­nale avec le fait que c’est une base chinoise et pas une base améri­caine. En même temps il y a une pres­sion qui commence à se consti­tuer de la part des États-Unis pour que l’Eu­rope ne bride pas les services améri­cains, voire qu’ils consi­dèrent les amendes de régu­la­tion de X ou de Meta comme du protec­tion­nisme au titre des règles de libre échange. Si l’im­pé­ria­lisme numé­rique se faisait par influence, main­te­nant on est dans le rapport de force clair et net.

    Ce n’est pas qu’une ques­tion écono­mique. Les liber­tés et inter­dits font partie de ce qui nous est imposé. C’est vrai autant pour le légal que pour le légal. Il est inté­res­sant de voir que les IA n’ont pas de filtre avan­cée pour gérer la vie privée mais qu’elles sont inca­pables de parler de corps fémi­nin ou de sexe. On importe à la fois leur free speech et leurs tabous.

    Où est-ce que ça nous mène ? Je ne sais pas, mais voyant quelle place est amenée à prendre l’IA, le fait qu’elle se fixe sur des règles du jeu d’un seul pays me met quelque part très mal à l’aise.

  • Outil ou collègue

    Mon conseil pour les rares qui me suivent encore et que j’ai pu moti­ver à deve­nir deve­lop­peur: fuyez! Redui­sez vos dettes. Votre train de vie. […] inves­tis­sez tout et prepa­rez vous pour l’hi­ver.

    Je vous garan­tie que avant la fin de votre carrière (voir de la décen­nie) il faudra se recon­ver­tir. Préfé­ra­ble­ment dans un truc manuel.

    On lit toujours plein de choses alar­mistes sur le futur. Tout avance très vite mais les métiers dispa­raissent rare­ment en moins d’une géné­ra­tion. Jusqu’à présent.

    Et pour­tant, vu d’où je l’ai lu, ça m’a fait cogi­ter.

    J’ai repris un peu mes tâches pénibles habi­tuelles via Cursor. Rien de neuf. Je le fais régu­liè­re­ment. Si je trouve la complé­tion auto­ma­tique magique, pour moi c’est un outil en plus, pas de quoi éteindre le métier.

    Là j’ai suivi les traces de Simon Willi­son. J’ai utilisé l’agent et lui ai tout dicté, refu­sant de toucher à un quel­conque fichier direc­te­ment, de résoudre un quel­conque problème tech­nique moi-même.

    J’ai plein de posi­tif et plein de néga­tif mais… mon dieu je ne conseille­rai pas à mon fils de faire du déve­lop­pe­ment. C’est foutu pour lui. Je ne sais pas s’il aurait pu tout réali­ser sans rien savoir, mais ça n’en était pas loin. Dans 2 ans, 10 ans… oui la moitié des tâches de déve­lop­pe­ment au moins se passe­ront proba­ble­ment d’ex­perts tech.

    Ok, c’est de la boule de cris­tal. Je peux me trom­per. Je me suis déjà trompé par le passé. Oui ça ne remplace pas tout mais on a passé un sacré cap. Il me reste 20 ans au moins, la révo­lu­tion se fera pendant ma vie profes­sion­nelle, et elle sera lour­de­ment impac­tée.

  • [Lecture] How decen­tra­li­zed is Bluesky really?

    Je n’ai pas de cita­tion à mettre en lumière. Le contenu est proba­ble­ment trop long pour le permettre.

    Je recom­mande toute­fois très chau­de­ment la lecture du billet de Chris­tine Lemmer-Webber sur Bluesky, le Fedi­verse, et la décen­tra­li­sa­tion à tous ceux qui s’in­té­ressent au sujet.

    Il y a de la tech­nique donc ça demande un peu de bagage mais pas besoin d’être un ingé­nieur non plus.

    Il y a une réponse d’un ingé­nieur de Bluesky, auquel il y a une réponse à nouveau mais si vous ne devez en lire qu’un, je recom­mande le premier.

    Je note d’ailleurs que l’es­pace de l’in­gé­nieur Bluesky n’a pas de RSS. Pour moi ce n’est pas un élément absent de sens.

  • IA : J’ai déjà l’im­pres­sion d’être un vieux con

    J’ai déjà l’im­pres­sion d’être un vieux con. Il y a des choses impres­sion­nantes sur l’IA mais ce qui risque surtout de boule­ver­ser mon monde à court terme c’est ce que je vois à travers des expé­ri­men­ta­tions de Simon Willi­son.

    Il cherche un prompt pour que Gemini iden­ti­fie l’em­pla­ce­ment d’ani­maux sur une image. Pourquoi pas.

    Là où ça m’in­té­resse c’est qu’il utilise Claude pour visua­li­ser ensuite si les coor­don­nées obte­nues sont bien perti­nentes.

    Mais, surtout, il décide d’en faire un petit outil sur une page web. Pour ça aussi, il passe par Claude qui lui génère tout le code de zéro. Il y a quelques erreurs mais il ne les corrige pas lui-même, il les fait corri­ger par Claude jusqu’à obte­nir le résul­tat attendu.

    Il y a eu quelques ques­tions liées à l’orien­ta­tion des images, et là c’est ChatGPT qui l’aide à débo­guer le tout puis géné­rer le code qui modi­fie l’orien­ta­tion des images.

    Et là… je me sens vieux. J’au­rais proba­ble­ment tout fait à la main, en beau­coup plus de temps, peut-être aban­donné au milieu si c’était un projet perso peu impor­tant. L’ar­ri­vée de l’IA pour tous les petits outils et les petites tâches va vrai­ment chan­ger la donne pour ceux qui savent l’uti­li­ser.

  • Nouveau tour dans les CSS-in-JS

    L’his­toire

    J’ai aban­donné mes premiers amours qu’é­taient les feuilles de style sépa­rées avec des nommages bien séman­tiques. Je travaille par les appli­ca­tions front-end par compo­sants, j’ai besoin que les styles fonc­tionnent de façon simi­laire.

    BEM était une bonne idée mais impra­ti­cable. Le nommage est pénible et il fallait encore garder une synchro­ni­sa­tion entre la feuille de style et les compo­sants. J’ai eu plai­sir à trou­ver CSS Modules mais on conti­nue à jongler sur deux fichiers distincts avec des imports de l’un à l’autre. Il fallait faire mieux.

    J’ai besoin que les styles soient édités au même endroit que les compo­sants, toujours synchro­ni­sés, mis à jour en même temps, limi­tés chacun au compo­sant ciblé.

    Tail­wind a trouvé une solu­tion à tout ça en géné­rant statique­ment la feuille de style à partir des compo­sants eux-mêmes. Je comprends pourquoi ça plaît mais je n’ar­rive pas à consi­dé­rer que redé­fi­nir tout un pseudo-langage paral­lèle puisse être une bonne idée. On finit toujours par devoir apprendre CSS, que ce soit pour expri­mer quelque chose que le pseudo-langage ne permet pas, ou simple­ment pour comprendre pourquoi le rendu n’est pas celui qu’on imagine.

    Je suis parti vers les solu­tions CSS-in-JS quand je code du React. Faire télé­char­ger et exécu­ter toute une biblio­thèque comme Emotion est loin d’être idéal mais ça reste fina­le­ment assez négli­geable sur une appli­ca­tion front-end moderne.

    Entre temps j’ai quand même décou­vert Goober, qui implé­mente le prin­ci­pal en tout juste 1 ko. L’éli­mi­na­tion des styles morts contre­ba­lance proba­ble­ment large­ment ce 1 ko de Javas­cript. On aurait pu en rester là.

    La mise à jour

    Je suis quand même gêné de devoir embarquer une biblio­thèque Javas­cript. J’ai fouillé voir si rien de mieux que Goober et Emotion n’avait pointé le bout de son nez depuis la dernière fois que j’ai tout remis en cause. Il se trouve que le paysage a sacré­ment évolué en cinq ans.

    D’autres que moi ont eu envie d’al­ler vers du plus simple. On parle de zero-runtime. Les styles de chaque compo­sant sont extraits à la compi­la­tion pour créer une feuille de style dédiée. Les parties dyna­miques sont faites soit avec des variantes prédé­fi­nies, soit avec des variables CSS qui sont ensuite mani­pu­lée par Javas­cript via les attri­buts `style`.

    Le véné­rable c’est Vanilla-extract mais on a juste une version plus complexe et entiè­re­ment Javas­cript des CSS-Modules. C’est d’ailleurs le même auteur, et le même problème fonda­men­tal : deux fichiers distincts à mani­pu­ler et à synchro­ni­ser.

    Vient ensuite Lina­ria qui semble une vraie merveille. Il a l’es­sen­tiel de ce que proposent les CSS-in-JS avec de l’ex­trac­tion statique avec tout ce qu’on attend au niveau de l’ou­tillage : types­cript, source maps, prépro­ces­seur et véri­fi­ca­tion de syntaxe, ainsi que l’in­té­gra­tion avec tous les cadres de travail clas­siques.

    Lina­ria c’est aussi WyW-in-JS, qui opère toute la partie extrac­tion et trans­for­ma­tion, au point de permettre à qui veut de créer son propre outil concur­rent à Lina­ria. Je trouve même cette réali­sa­tion bien plus signi­fi­ca­tive que Lina­ria lui-même.

    L’équipe de MUI en a d’ailleurs profité pour faire Pigment-CSS et conver­tir tout MUI. Pigment reprend tout le prin­cipe de Lina­ria avec la gestion des thèmes, la gestion des variantes, et quelques raccour­cis syntaxiques pour ceux qui aiment l’ap­proche de Tail­wind. En échange, ces fonc­tion­na­li­tés ne sont possibles qu’en écri­vant les CSS sous forme d’objets Javas­cript plutôt que sous forme de texte CSS direc­te­ment. La biblio­thèque est aussi plus jeune et la compa­ti­bi­lité avec tous les cadres de travail ne semble pas assu­rée.

    J’ai aussi traversé Panda-CSS mais sans être convaincu. Panda génère tout en statique mais il génère tout une série d’uti­li­taires et de variables par défaut, et injecte beau­coup d’uti­li­taires dans le Javas­cript qui sera exécuté avec l’ap­pli­ca­tion. C’est un croi­se­ment entre Emotion, Tail­wind et Lina­ria, mais qui du coup me semble un peu Fran­ken­stein. À vouloir tout à la fois, on finit par ne rien avoir de franc.

    Si c’est pour utili­ser avec MUI, le choix se fait tout seul. Dans le cas contraire, au moins pour quelques mois le temps que Pigment-CSS se déve­loppe un peu plus, Lina­ria me semble un choix plus sage. S’il y a quoi que ce soit qui coince, Goober reste une solu­tion prag­ma­tique et tout à fait accep­table.

  • Arrê­tons avec les frame­works agiles

    Jetez moi SCRUM, Shape-up et les autres, et encore plus leurs versions dites « at-scale » type SAFe.

    Je ne comprends même pas comment on en est arrivé là alors que le mani­feste agile met en avant «  Les indi­vi­dus et leurs inter­ac­tions, de préfé­rence aux proces­sus et aux outils ».

    Prétendre cadrer les indi­vi­dus et les inter­ac­tions via des proces­sus et des outils métho­do­lo­giques est un contre-sens total de ce qu’on a appris depuis le mani­feste.

    Quand on me demande ma méthode de prédi­lec­tion je parle de Kanban, parce que l’im­plé­men­ta­tion dans le logi­ciel revient juste à limi­ter le flux et donner une prio­rité à ce qui est déjà en cours, avec une grande liberté d’im­plé­men­ta­tion. S’il s’agis­sait de cher­cher une implé­men­ta­tion « comme dans la litté­ra­ture », je raye­rais d’un trait et range­rai Kanban avec les autres.

    Appliquer des outils et des proces­sus tout faits ça rassure quand on n’a pas confiance dans les indi­vi­dus et leurs inter­ac­tions.

    Le fond c’est la défiance, souvent du top mana­ge­ment, même si parfois elle se diffuse jusqu’aux équipes elles-mêmes à force de leur poser des exigences contra­dic­toires.

    L’idée c’est souvent que si les résul­tats ne sont pas ceux espé­rés c’est que les équipes travaillent mal, alors on va leur expliquer comment il faut travailler en impo­sant une recette sans cher­cher à appro­fon­dir les problèmes eux-mêmes.

    Rien que le présup­posé me semble toxique.

    Ne vous mépre­nez pas. Je trouve formi­dable que Base­camp forma­lise la façon dont ils fonc­tionnent. Ce n’est pas une critique de leur fonc­tion­ne­ment. Il y a plein de choses à penser dans la lecture de Shape-up.

    Le trans­po­ser tel quel avec des rituels, par contre, c’est proba­ble­ment une mauvaise idée. Trans­po­ser quoi que ce soit tel quel est proba­ble­ment une mauvaise idée d’ailleurs. Le cargo-cult est bien trop présent dans l’uni­vers logi­ciel, et encore plus dans l’uni­vers star­tup.

    Chaque équipe a ses besoins, des aspi­ra­tions, ses contraintes, ses indi­vi­dus. Croire que ce qui fonc­tionne à côté fonc­tion­nera chez nous en le reco­piant c’est se trom­per de prio­rité entre les indi­vi­dus et les proces­sus. C’est d’au­tant plus vrai qu’en géné­ral on en applique les arte­facts visibles mais pas la philo­so­phie sous-jacente.

    Je ne suis même pas convaincu que ce soit un bon point de départ pour ensuite itérer. Les rituels ont tendance à ne pas bouger, voire à s’ac­cu­mu­ler, surtout qu’ils appar­tiennent à « la méthode ». S’il faut commen­cer c’est proba­ble­ment par SLAP.

    Tout n’est pas à jeter. Il y a plein d’idées inté­res­santes à reprendre à droite et à gauche. Mon problème c’est la reprise d’un cadre complet comme si ça allait résoudre les problèmes.

    Dans mes boites à outils, en fonc­tion des besoins, j’au­rais tendance à conseiller les points suivants :

    • Des rétros­pec­tives régu­lières, à date fixe
    • Des itéra­tions de durée rela­ti­ve­ment fixe
    • Des points de synchro internes fréquents voire quoti­diens
    • Des démos aux utili­sa­teurs et parties prenantes
    • Une notion d’ap­pé­tit pour les sujets qu’on veut livrer
    • Une esti­ma­tion d’ordre de gran­deur de l’ef­fort pour la prio­ri­sa­tion

    Bref, un kanban avec des cycles qui permettent de régu­liè­re­ment sortir la tête du guidon, prendre du recul, voir ce qu’on veut chan­ger dans notre fonc­tion­ne­ment, déci­der quelle direc­tion on veut prendre pour la suite, et de vrais échanges amonts pour expli­ci­ter la complexité et l’ap­pé­tit pour les diffé­rents items.

    Le reste s’ajoute avec grande prudence. Sauf besoin spéci­fique j’au­rais tendance à décon­seiller les items suivant :

    • Les enga­ge­ments de livrai­son, hors besoin absolu (on ne déca­lera pas Noël)
    • Les esti­ma­tions autres que des ordres de gran­deur
    • Les back­logs (oui oui, vous avez bien lu)
    • Avoir plus d’un objec­tif par itéra­tion
    • Avoir déjà étudié la solu­tion avant de commen­cer
    • Tenter d’ap­pliquer ce que d’autres équipes font dans d’autres contextes au sein d’autres cultures

  • Rust, première jour­née

    Je suis le circuit de Compre­hen­sive Rust.

    Le jour 1 ce sont les struc­tures de contrôle et les types. Rien d’ex­tra­or­di­naire mais je me tiens à ma réso­lu­tion d’al­ler lente­ment sans griller des étapes.

    J’avais déjà tenté de me mettre à Rust il y a quelques années mais je me suis retrouvé un peu noyé. Je crois que j’ai voulu aller trop vite, tout lire sans mani­pu­ler jusqu’à me retrou­ver bloqué par manque de réflexes. Là je vais prendre l’op­tion oppo­sée.

    J’ai beau­coup aimé le retour impli­cite de Ruby. La dernière instruc­tion de chaque bloc est sa valeur de retour. Rust a choisi un méca­nisme un peu plus expli­cite, proba­ble­ment pour simpli­fier la gestion des types de retour : Il s’agit d’une valeur de retour si la dernière instruc­tion n’est pas suivie d’un point virgule.

    Je trouve ce choix trop discret, et cassant l’au­to­ma­tisme du point virgule systé­ma­tique. J’ai bien conscience que le compi­la­teur va m’évi­ter l’es­sen­tiel des erreurs mais quitte à ne pas avoir un retour impli­cite systé­ma­tique j’au­rais proba­ble­ment préféré avoir un retour plus expli­cite avec un symbole ou un mot clef en début de ligne, quitte à faire un return complet.

    Et, juste­ment, les points virgules en fin de ligne me sortent par les yeux. C’est quelque chose dont j’ai réussi à me débar­ras­ser en JS et en Ruby, que je ne retrouve pas en Python non plus. Je suis dans l’in­com­pré­hen­sion qu’un langage conçu rela­ti­ve­ment récem­ment ait fait le choix de les rendre obli­ga­toires.

    Tout le monde m’avait loué le compi­la­teur. Je n’ai pas fait d’er­reur assez forte pour vrai­ment juger des messages mais j’ai l’im­pres­sion de reve­nir plusieurs années en arrière telle­ment c’est lent. C’est pour moi un vrai point noir dans l’uti­li­sa­tion alors que je n’en suis qu’à des équi­va­lents « hello world ». Comment les déve­lop­peurs Rust font-ils pour accep­ter des attentes de ce type à chaque compi­la­tion ?

    Pas que du néga­tif. En fait à part ces trois points de détails, je retrouve mes petits assez faci­le­ment et ça semble assez fluide sur les méca­nismes de base.

  • Leet­code

    Je cherche un bon moyen d’éva­luer la compé­tence tech­nique d’un déve­lop­peur. Aujourd’­hui j’ai un test qui semble bien fonc­tion­ner pour notre usage mais que je trouve clai­re­ment trop long avec 4 heures.

    J’ai toujours été réti­cent aux exer­cices tableau blanc de type parcours d’arbre, calculs sur tableau et autres jeux d’al­go­rithme. J’ai quand même voulu tester un peu les clas­siques leet­code que certains utilisent comme lors des tests d’en­trée.

    Quelques conclu­sions après une ving­taine d’exer­cices de diffi­cul­tés variables d’un parcours qui m’est présenté comme repré­sen­ta­tif :

    Ces exer­cices dépen­dant plus du bacho­tage préa­lable que de l’ex­pé­rience ou de la compé­tence.

    Pour une bonne partie, le faire bien demande d’avoir vu le truc une fois, ou de connaître le bon algo. Ce ne sont pas des choses qui se trouvent simple­ment en réflé­chis­sant, a fortiori pas pendant un test tech­nique en temps limité avec une dose de stress.

    J’en ai un ou deux dont je ne connais­sais pas l’al­go­rithme et je n’ai pas été capable de trou­ver une bonne solu­tion en termes de récur­si­vité, complexité de calcul ou espace mémoire. Ça ne s’in­vente pas.

    À l’op­posé, sur la plupart je connais­sais le truc et le temps passé était sur la syntaxe ou des erreurs d’inat­ten­tion. Zéro inté­rêt. Même là où l’ex­pé­rience a pu jouer, sur les parcours avec des poin­teurs, je classe ça dans les connais­sances qui ne m’ont presque jamais servi et pas dans les acquis de l’ex­pé­rience.

    Je suis convaincu qu’un débu­tant sorti d’école avec un peu de bagage théo­rique et pas mal de bacho­tage s’en sortira bien mieux, y compris à expliquer sa solu­tion, qu’un déve­lop­peur senior avec un super impact en entre­prise.

    Je ne vois pas comment ça va aider à justi­fier de ma valeur ou à évaluer celle des autres

    Je ne dis pas qu’on n’a jamais à jouer avec les poin­teurs, les tris, les parcours et ce genre de choses, mais ce n’est clai­re­ment pas repré­sen­ta­tif des problé­ma­tiques qui seront rencon­trées.

    Le cas échéant, ce sont juste­ment des problèmes pour lesquels on va utili­ser des biblio­thèques exis­tantes ou pour lesquels on trou­vera très bien la réponses sur un moteur de recherche.

    Il est évident que l’exer­cice va permettre de faire un tri dans les candi­dats mais je n’ai pas l’im­pres­sion que ce soit sur le bon critère.

    Bien évidem­ment ça doit dépendre des métiers. Un ingé­nieur sur le cœur d’une base de données doit certai­ne­ment être assez près de ces problé­ma­tique, mais ça ne me semble pas être le cas de 90% des ingé­nieurs.

    Peut-être que je n’ai pas vu les bons tests, mais je reste assez dubi­ta­tif.

    Pour ceux qui utilisent ces tests ou des simi­laires, y compris ceux à l’as­pect un peu plus ludique, qu’y cher­chez-vous exac­te­ment ?

  • Comment déve­lop­pera-t-on demain ?

    Les déve­lop­peurs de mes équipes demandent depuis un moment des licences Github Copi­lot. J’ai vu quelques personnes parler de l’édi­teur Cursor.sh.

    J’avoue que j’ai eu envie de tester un peu. Sur un projet perso j’ai tenté l’ap­proche « allons-y tota­le­ment ». Je suis bluffé.

    Bon, j’ai encore le réflexe de cher­cher tout ce que je ne sais pas dans les docs. Ça veut dire que je demande prin­ci­pa­le­ment des choses que je saurais déjà faire, et poten­tiel­le­ment aussi rapi­de­ment seul qu’en saisis­sant ma demande dans l’in­ter­face. Je ne sais pas si je gagne vrai­ment du temps mais, même ainsi, l’in­ves­tis­se­ment de 2x 20$ par mois me semble une évidence.

    Avec le temps je risque de me repo­ser vrai­ment dessus et là ça fera certai­ne­ment une énorme diffé­rence. Pour un débu­tant qui apprend à coder direc­te­ment avec ces outils, ça doit être juste une révo­lu­tion.

    Le métier de déve­ve­lop­peur est en train de chan­ger radi­ca­le­ment. Je ne sais pas s’il sera le même dans 10 ans. Je ne sais même pas si ça a du sens d’en­sei­gner le code à mon fils de 11 ans.

    ⁂

    On est en train de tester ça au boulot, plus Code rabbit pour les revues de code. Si je trouve d’autres choses perti­nentes j’ai une propen­sion assez forte à ajou­ter aussi. Même sur un budget total de 100 ou 150 $ par mois et par déve­lop­peur, ce serait assez mal avisé de reje­ter la chose.

    Reste l’éner­gie néces­saire à tout ça, et là on touche vite la limite du modèle :

    « OpenAI’s CEO Sam Altman on Tues­day said an energy break­through is neces­sary for future arti­fi­cial intel­li­gence, which will consume vastly more power than people have expec­ted.

    Reuters, 16 janvier 2024

    Je n’ai pas de conclu­sion. L’as­pect produc­ti­vité ne fait aucun doute. La limite éner­gé­tique aussi. Malheu­reu­se­ment les deux ne vont pas du tout dans le même sens.