Carnet de notes

Catégorie : Développement informatique

  • Fin ou trans­for­ma­tion d’un métier

    BD tirée de CommitStrip. Première case: le chef/commercial parle avec l'ingénieur informaticien. Case 1 : le commercial vient voir l'informaticien, un mug à la main. L'informaticien est sur son PC, un mug à côté aussi. Commercial : un jour on n'aura plus besoin de codeur. On aura juste à définir des spécifications et ça générera automatiquement une application. Case 2 : le commercial est en train de boire dans son mug. Infoteux, devant son PC et un mug de café : T'as raison, il suffira simplement d'écrire des spécifications complètes et précises et pouf, plus besoin de codeur ! Commercial, l'air satisfait : c'est ça ! Case 3. Infoteux : Et tu sais comment on appelle des spécifications suffisamment complètes et précises pour qu'un programme puisse générer une application ? Commercial, dubitatif : Euh... Non ? Case 4. Informaticien, l'air blasé, pointant son clavier : Du code. On appelle ça du code. Le commercial est tellement surpris qu'il penche son mug par inadvertance et renverse un peu le breuvage sacré. (le alt n'est pas de moi et à été honteusement repompé)
    « Il suffira d’écrire des spéci­fi­ca­tions complètes et précises »

    Je revois cette planche de BD dans une conver­sa­tion et je trouve qu’elle passe à côté d’un élément fonda­men­tal : On ne trans­met pas juste­ment pas de spéci­fi­ca­tions complètes et précises au déve­lop­peur.

    Complé­ter, préci­ser

    Une grosse partie du boulot de déve­lop­peur c’est complé­ter et préci­ser ces spéci­fi­ca­tions incom­plètes et impré­cises.

    Complé­ter, préci­ser, le tout à partir du contexte projet, des habi­tudes et de l’im­pli­cite courant… C’est le cas d’usage exact des LLM.

    On essaie de leur faire faire « de l’IA » mais ces outils sont en premier lieu de formi­dables outils de complé­tion à partir d’un contexte et de l’im­pli­cite habi­tuel pour un type de tâche donnés. Bref, le travail d’un déve­lop­peur.

    Refor­mu­ler dans un langage plus formel

    Que fait le déve­lop­peur d’autre ? Il traduit ça dans un langage formel (le code).

    Refor­mu­la­tion, ça aussi c’est le cas d’usage parfait pour les LLM.

    La dernière tâche du déve­lop­peur est très tech­nique. C’est de l’in­gé­nie­rie logi­cielle, réus­sir à tout agen­cer pour que ce soit faci­le­ment testable, main­te­nable, évolu­tif, etc.

    Une grosse part de cette dernière tâche est basée sur l’ap­pren­tis­sage et la repro­duc­tion de motifs ou de pratiques. Le LLM est aussi parfait pour ça.

    Il reste aussi qu’il s’agit de rendre les choses testables, main­te­nables et évolu­ti­ves… par des humains. Peut être qu’une partie de ce besoin va dispa­raître ou du moins évoluer le jour où le code sera plus mani­pulé par des LLM que par des humains. Leurs besoins, faci­li­tés et diffi­cul­tés sont forcé­ment diffé­rents des nôtres.

    Appren­tis­sage

    Oui il faudra faire des aller-retours avec l’ou­til pour complé­ter ou corri­ger sa complé­tion. Il en va de même du déve­lop­peur, surtout lors de sa première arri­vée dans une équipe ou dans un projet.

    Oui un LLM fera des erreurs d’in­ter­pré­ta­tion. Un déve­lop­peur aussi.

    Est-ce que les allers-retours et erreurs seront plus impor­tants que ceux avec un déve­lop­peur ? Aujourd’­hui proba­ble­ment, demain je n’en sais rien, peut-être.

    Est-ce que ces allers-retours et correc­tions seront plus coûteux qu’un déve­lop­peur ? Alors là je n’en sais rien, mais je ne parie­rai pas dessus.

    Besoin d’ex­per­tise

    Est-ce qu’on aura toujours besoin d’un déve­lop­peur et d’ex­per­tise pour accom­pa­gner l’ou­til auto­ma­tique ? Très proba­ble­ment sur une partie, oui, mais proba­ble­ment moins en propor­tion qu’on n’en a besoin aujourd’­hui.

    Très certai­ne­ment aussi que le travail sera diffé­rent de celui d’aujourd’­hui, et que savoir inter­agir avec les outils auto­ma­tiques sera essen­tiel dans les compé­tences requises. C’est déjà partiel­le­ment le cas aujourd’­hui. On ne code pas comme au temps des cartes perfo­rées. C’est juste que les outils vont chan­ger et vont très proba­ble­ment prendre une plus grande place.

    Certi­tudes

    Je ne donne que mes certi­tudes, mes croyances et mes craintes. Je ne connais pas plus le futur que d’autres. J’ai juste le senti­ment, sans aucune tech­no­béa­ti­tude, qu’il est en train d’ar­ri­ver.

    On fait faire, dire ou espé­rer plein de choses quand on parle d’IA. Il ne s’agit pas de voiture volantes et autres IA sentientes ici.

    Ici je parle LLM, complé­tion et refor­mu­la­tion de textes. Je peux me trom­per et je ne mets ma main au feu à propos de rien, mais je me base sur des capa­ci­tés qui sont déjà là aujourd’­hui.

    Juger le futur

    Est-ce souhai­table socia­le­ment ? Est-ce soute­nable pour la planète ? Comment va-t-on gérer la tran­si­tion au niveau de la société ?

    Ce sont honnê­te­ment d’ex­cel­lentes ques­tions dont j’ai­me­rais avoir les réponses.

    Le fond n’est pas si je souhaite ou pas ce futur, c’est que je constate qu’il est en train d’ar­ri­ver, et que je veux pas faire semblant de l’igno­rer.

    Pour les futurs déve­lop­peurs

    Je crains une vraie crise dans le métier dans quelques années. Certains, beau­coup, vont rester sur le carreau.

    Je ne sais pas si j’en­cou­rage les plus jeunes à se lancer dans le déve­lop­pe­ment infor­ma­tique. Si vous le faites, je vous encou­rage à à la fois deve­nir très vite expert (parce que j’ima­gine qu’on aura besoin des experts pour complé­ter les LLM), et apprendre à coder via les LLM (pas juste « avec ») même si ce n’est pas rentable aujourd’­hui.

    Je suis conscient de la contra­dic­tion à deman­der aux juniors de deve­nir immé­dia­te­ment expert.

    Je ne suis pas certain qu’il y ait un avenir pour les déve­lop­peurs moyens, ou pour les junior. Leur valeur ajou­tée sera faible et il y aura dans un premier temps suffi­sam­ment de déve­lop­peurs formés pour jouer les experts sans devoir inves­tir des années dans des compé­tences inter­mé­diaires qui pour­raient deve­nir experts un jour.

    Pour choi­sir son futur

    Si vous êtes très tech, faites des maths, de la mani­pu­la­tion de données, des statis­tiques, et globa­le­ment de l’IA. Les places seront peut être chères et deman­de­ront des compé­tences plus avan­cées que pour être déve­lop­peur, mais il y aura du travail.

    Si vous avez envie de créer, pour moi l’ave­nir est plus dans les métiers du produit, des product mana­ger avec une colo­ra­tion et un inté­rêt tech­nique. Ça veut dire savoir parler busi­ness, marché, client, etc.

    Pour les déve­lop­peurs actuels

    Pour ceux qui sont encore majo­ri­tai­re­ment les mains dans le code, je vous conseille de passer au plus tôt dans le déve­lop­pe­ment via les LLM.

    Je sais que vous n’en ressen­tez pas le besoin, que ces outils font des erreurs que vous ne faites pas, que ça ne vous accé­lère pas aujourd’­hui.

    Le fond c’est que les plus jeunes ça les accé­lère, que demain ils auront déve­loppé leur exper­tise mais sauront aussi utili­ser ces outils, et qu’ils en compren­dront assez les limites et les défauts pour être l’ex­pert dont le métier aura besoin.

    Il y aura encore long­temps de la place pour des vieux experts du code pour la main­te­nance et pour les gros groupes qui ont plusieurs géné­ra­tions de retard. Il y a aujourd’­hui toujours besoin de déve­lop­peurs et Cobol. La vraie ques­tion : Est-ce le posi­tion­ne­ment auquel vous aspi­rez ?

    Et moi, direc­teur tech­nique ?

    Honnê­te­ment je ne sais pas. Je ne sais pas bien quel sera mon avenir.

    Le mana­ge­ment de grandes équipes de déve­lop­pe­ment risque d’être aussi has been demain que les vieux DSI dépas­sés d’aujourd’­hui. Est-ce que je veux être de ceux là ? Je ne sais pas.

    J’ado­re­rais prendre la tête d’équipes de data science, mais j’ima­gine qu’il y a une batte­rie de docteurs sur les rangs, avec une exper­tise qui me ferait défaut.

    Entre temps je vais proba­ble­ment au moins essayer d’in­té­grer des équipes qui ont sont alignées avec tout ce que je viens d’écrire.

  • Lecture de Steve Yegge : « The Death of the Stub­born Deve­lo­per »

    De  « The Death of the Stub­born Deve­lo­per »

    Here’s the rub: As of about May, LLMs can now execute most of the leaf tasks and even some higher-level inter­ior tasks, even on large soft­ware projects. Which is great. But what’s left over for humans is prima­rily the more diffi­cult plan­ning and coor­di­na­tion nodes. Which are not the kind of task that you typi­cally give junior deve­lo­pers.

    C’est peut être là que je diverge. C’est vrai pour les déve­lop­peurs « code », un peu moins pour les déve­lop­peurs « produit ».

    Howe­ver, some junior engi­neers pick this new stuff up and fly with it, basi­cally uple­ve­ling them­selves. And many senior engi­neers seem to be heading towards being left behind. So what is it, then?

    (…)

    Chat-Orien­ted Program­ming, CHOP for short (or just chop). Chop isn’t just the future, it’s the present. And if you’re not using it, you’re star­ting to fall behind the ones who are.

    Ne croyez pas qu’on a à faire à encore un rêveur qui imagine un futur avec des voitures volantes. On parle du présent.

    They believe these gene­ric auto­no­mous soft­ware agents will solve the problem of chop being too diffi­cult and toil­some. In fact some people claim that agents can take over the task graph enti­rely, perhaps at least for small busi­nesses, allo­wing non-tech­ni­cal CEOs to launch apps them­selves without having to hire any pesky deve­lo­pers.

    I think those people are smoking some serious crack.

  • Lecture de Steve Yegge :  « The Death of the Junior Deve­lo­per »

    De  « The Death of the Junior Deve­lo­per »

    Gene, as an accom­pli­shed and senior author, is deligh­ted with his produc­ti­vity gains with his LLM of choice, Claude Opus. He showed me a big writing project that he’d just fini­shed, in which he had spent easily 45+ minutes craf­ting the prompt, refi­ning it until he had a 7500-word narra­tive that could serve as a star­ting point for rewri­ting, editing, and adjust­ment. (In compa­ri­son, this blog post is about half that size.) And that draft was fantas­tic. I’ve read it and it’s glorious.

    On a good day, Gene can write 1,000 words per day. His esti­mate is that Claude did for him in 90 minutes what would normally have taken him ten days. It solves the « blank-page problem » and gets him to the 20-yard line, where the fun begins.

    Il y a d’autres histoires. Je note un motif que ceux qui répondent « qualité » ne semblent pas voir.

    L’IA est un outil. On ne lui demande pas force­ment de savoir tout faire, ni même de le faire bien. On lui demande de savoir faire assez pour amener le donneur d’ordre plus loin, ou plus vite, et majo­ri­tai­re­ment de lui permettre de se concen­trer sur sa tâche réelle, son vrai métier. C’est vrai même pour celui dont la tâche est l’écri­ture.

    My senior colleagues have recently recoun­ted simi­lar chat scena­rios in which a more junior dev would have been comple­tely taken in, poten­tially losing days to weeks of work going the wrong direc­tion.

    Or worse.

    Chat, it seems, is safer for senior program­mers than it is for junior ones. And a lot of compa­nies are going to inter­pret « safer » to mean « better. »

    (…)

    Brie­fly, what do I mean by « senior » here? Really just two things:

    –  You know what you want before the AI writes it. You already have a vision for how you would write this by hand, or have it narro­wed to a few reaso­nable options.
    –    You can detect when it is giving you bad guidance.

    J’ajou­te­rais : savoir utili­ser l’ou­til. Ça reste un outil. Comprendre ses limites, sa zone d’ef­fi­ca­cité et comment en obte­nir le meilleur peut faire la diffé­rence.

    Rien que : aujourd’­hui les tâches répé­ti­tives finissent toujours par dérailler mais qu’il est parfait pour créer le code qui va faire cette tâche répé­ti­tive (comme un déve­lop­peur en fait).

  • 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.

  • 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.