Carnet de notes

Catégorie : Carrière

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

  • On a parlé carrière, mana­ge­ment et exper­tise

    J’ai écrit plusieurs fois ce billet avant de finir sur cette unique formule :

    La ques­tion n’est pas de savoir si vous êtes mana­ger, lead, expert ou mouton à cinq pattes, la ques­tion c’est quel impact vous avez.

    Il n’y a pas besoin d’être mana­ger ou lead pour progres­ser dans sa carrière. Il est tout à fait imagi­nable d’avoir un déroulé de carrière aussi rapide et aussi poussé via de l’ex­per­tise tech­nique.

    Vos connais­sances et compé­tences expertes n’ont toute­fois de valeur que si elles ont un impact pour l’en­tre­prise. L’enjeu c’est d’avoir cet impact et le simple fait d’être expert tech­nique n’en dit pas grand chose.

    ⁂

    Viser l’im­pact c’est d’abord comprendre l’ef­fet de levier : Passé un certain cap le collec­tif prime très large­ment sur l’in­di­vidu. Il est juste plus facile de faire progres­ser de 1 % une équipe de 30 personnes que de progres­ser soi-même de 30 %.

    Si vos connais­sances et compé­tences n’amé­liorent que votre travail indi­vi­duel, votre progres­sion de carrière sera certai­ne­ment moins rapide que le lead ou le mana­ger qui eux béné­fi­cient d’une démul­ti­pli­ca­tion.

    Je pense que l’in­com­pré­hen­sion vient de là : Un expert seul n’a pas grand impact. Il arrive même que son impact soit néga­tif si sa présence a tendance à dimi­nuer l’au­to­no­mie ou l’ini­tia­tive des autres (pire encore si elle génère des guerres internes).

    Sauf à avoir une connais­sance poin­tue qui se trouve diffi­ci­le­ment ailleurs et qui est essen­tielle au déve­lop­pe­ment de l’en­tre­prise, la progres­sion de carrière de l’ex­pert tech­nique passe aussi par l’en­ca­dre­ment des plus jeunes, la commu­ni­ca­tion non-violente, la colla­bo­ra­tion, la prise d’ini­tia­tives, la prise de respon­sa­bi­li­tés, et beau­coup de savoir-être qui permettent de faire rayon­ner cette exper­tise.

    Ce n’est pas tant qu’on ne peut pas progres­ser en tant qu’ex­pert, c’est que ça demande autre chose que simple­ment être le sachant dans sa grotte.

    L’im­por­tance de ces à-côtés va de plus gros­sir avec le temps. La plupart des entre­prises n’ont besoin d’ex­per­tise que jusqu’à un certain point. Au-delà, les connais­sances ou compé­tences ultra-poin­tues n’ap­por­te­ront qu’une valeur ajou­tée réduite.

    Si vous tenez abso­lu­ment à une progres­sion de carrière conti­nue, il faudra soit déve­lop­per d’autres atouts, proba­ble­ment du leader­ship et des prises de respon­sa­bi­li­tés (pas forcé­ment du mana­ge­ment), soit viser les quelques boites qui ont abso­lu­ment besoin d’une R&D à la pointe (sachant que vous ne serez pas le seul à postu­ler et que les autres auront peut-être déve­loppé ces compé­tences de rayon­ne­ment, donc seront donc plus inté­res­sants que vous).