Catégorie : Technique
-
Lecture de Steve Yegge : « The Death of the Stubborn Developer »
De « The Death of the Stubborn Developer »
Here’s the rub: As of about May, LLMs can now execute most of the leaf tasks and even some higher-level interior tasks, even on large software projects. Which is great. But what’s left over for humans is primarily the more difficult planning and coordination nodes. Which are not the kind of task that you typically give junior developers.
C’est peut être là que je diverge. C’est vrai pour les développeurs « code », un peu moins pour les développeurs « produit ».
However, some junior engineers pick this new stuff up and fly with it, basically upleveling themselves. And many senior engineers seem to be heading towards being left behind. So what is it, then?
(…)
Chat-Oriented Programming, 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 starting 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 generic autonomous software agents will solve the problem of chop being too difficult and toilsome. In fact some people claim that agents can take over the task graph entirely, perhaps at least for small businesses, allowing non-technical CEOs to launch apps themselves without having to hire any pesky developers.
I think those people are smoking some serious crack.
-
Lecture de Steve Yegge : « The Death of the Junior Developer »
De « The Death of the Junior Developer »
Gene, as an accomplished and senior author, is delighted with his productivity gains with his LLM of choice, Claude Opus. He showed me a big writing project that he’d just finished, in which he had spent easily 45+ minutes crafting the prompt, refining it until he had a 7500-word narrative that could serve as a starting point for rewriting, editing, and adjustment. (In comparison, this blog post is about half that size.) And that draft was fantastic. I’ve read it and it’s glorious.
On a good day, Gene can write 1,000 words per day. His estimate 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 forcement 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 majoritairement de lui permettre de se concentrer sur sa tâche réelle, son vrai métier. C’est vrai même pour celui dont la tâche est l’écriture.
My senior colleagues have recently recounted similar chat scenarios in which a more junior dev would have been completely taken in, potentially losing days to weeks of work going the wrong direction.
Or worse.
Chat, it seems, is safer for senior programmers than it is for junior ones. And a lot of companies are going to interpret « safer » to mean « better. »(…)
Briefly, 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 narrowed to a few reasonable options.
– You can detect when it is giving you bad guidance.J’ajouterais : savoir utiliser l’outil. Ça reste un outil. Comprendre ses limites, sa zone d’efficacité et comment en obtenir le meilleur peut faire la différence.
Rien que : aujourd’hui les tâches répétitives finissent toujours par dérailler mais qu’il est parfait pour créer le code qui va faire cette tâche répétitive (comme un développeur en fait).
-
Lecture d’Anne Vella : « Dear Software Engineer: It’s Time to Reclaim Your Role »
Citations d’Anne Vella :
I totally agree that software engineering should be a lot more than just writing code. When I studied computer science at university, they taught us how to elicit requirements, write user stories, design user interfaces and apply UX principles, architect complex systems, create test plans, execute test cases and so much more. The whole shebang.
De mon temps on appelait ça de façon méprisante les pisseurs de code. Et pourtant, à cause de la spécialisation, je vois énormément d’ingénieurs tomber dans cette catégorie de « développeur expert ».
J’en ai même vu s’indigner qu’on arbitre trop souvent en faveur du produit et des utilisateurs plutôt qu’en faveur d’une qualité de code interne.
Rien qu’à dire ça je sais que je vais avoir quelques réactions assez fortes.
Personne n’a raison mais ça devient des métiers différents.
Steve Yegge recently wrote a follow-up to his controversial article The Death of the Junior Developer, reframing his position as The Death of the Stubborn Developer. He talks about how if you’re not adopting Chat-Oriented Programming, or CHOP, you’re getting left behind
Je ne jouerai pas à qui va devoir changer.
Je suis convaincu que les développeurs « produit » vont devoir changer de façon de travailler. Pour autant, le besoin ne va pas disparaî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 renouvellement permanent de techno vont eux avoir du soucis à se faire parce que leur valeur ajoutée va devenir faible.
On ne remplacera pas les développeurs « code » experts. L’IA tant vantée n’est quand même qu’un outil statistique et je ne la vois pas de si tôt créer du code profond tel qu’on peut en trouver dans les bibliothèques de code qui forment les briques de base. On aura besoin de personnes qui comprennent le fonctionnement de tout ça pour savoir quoi faire (éventuellement assistés par de l’ia s’ils le veulent). Là ce sont les juniors qui vont avoir du mal à trouver une place.
Pour être franc je ne sais pas si tout ça est vraiment neuf. L’IA va juste démultiplier un effet déjà existant, mais peut être au point de rendre certains positionnements très difficiles à tenir.
So dear software engineer, please take heed. If you’re not a “product engineer” and have specialised in writing code, AI may indeed take your job. But this isn’t just a warning – it’s an opportunity. It’s time to reclaim your role and return to what software engineering was always meant to be: a craft that combines technical expertise with problem-solving, user empathy, and business acumen. The future belongs to those with curiosity who can see beyond the code.
Mes propos semblent peut être trop alarmistes, ou trop futuristes. J’ai l’impression qu’on passe des paliers très vite.
Je ne saurais trop conseiller aux développeurs 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’accélèrera pas grand chose aujourd’hui, savoir comment utiliser ses outils correctement demande un changement de paradigme et donnera plusieurs longueurs d’avance d’ici quelques années au plus.
Si vous avez vu le sex appeal des développeurs « no code » (non, il n’y a pas contradiction), ça va vite de démultiplier.
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 énergétiques. J’aimerais bien qu’on puisse les ignorer mais je ne le crois pas. Je ne les mets pas de côté.
Maintenant considé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 refuser mais il faudra au mieux se préparer à oublier les périodes fastes du point de vue emploi et salaire, pour ceux qui trouveront un emploi.
Je n’ai pas la solution à tout ça. Je me contente d’observer.
-
Prude IA
Le contrôle des réseaux et de l’informatique par les États-Unis me saute à la figure de plus en plus souvent.
Il y a peu, je lis que les États-Unis interdisent TikTok si l’activité n’est pas revendue à un tiers. L’enjeu c’est est celui de la sécurité nationale avec le fait que c’est une base chinoise et pas une base américaine. En même temps il y a une pression qui commence à se constituer de la part des États-Unis pour que l’Europe ne bride pas les services américains, voire qu’ils considèrent les amendes de régulation de X ou de Meta comme du protectionnisme au titre des règles de libre échange. Si l’impérialisme numérique se faisait par influence, maintenant on est dans le rapport de force clair et net.
Ce n’est pas qu’une question économique. Les libertés et interdits font partie de ce qui nous est imposé. C’est vrai autant pour le légal que pour le légal. Il est intéressant de voir que les IA n’ont pas de filtre avancée pour gérer la vie privée mais qu’elles sont incapables de parler de corps féminin 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 motiver à devenir developpeur: fuyez! Reduisez vos dettes. Votre train de vie. […] investissez tout et preparez vous pour l’hiver.
Je vous garantie que avant la fin de votre carrière (voir de la décennie) il faudra se reconvertir. Préférablement dans un truc manuel.
On lit toujours plein de choses alarmistes sur le futur. Tout avance très vite mais les métiers disparaissent rarement en moins d’une génération. Jusqu’à présent.
Et pourtant, vu d’où je l’ai lu, ça m’a fait cogiter.
J’ai repris un peu mes tâches pénibles habituelles via Cursor. Rien de neuf. Je le fais régulièrement. Si je trouve la complétion automatique magique, pour moi c’est un outil en plus, pas de quoi éteindre le métier.
Là j’ai suivi les traces de Simon Willison. J’ai utilisé l’agent et lui ai tout dicté, refusant de toucher à un quelconque fichier directement, de résoudre un quelconque problème technique moi-même.
J’ai plein de positif et plein de négatif mais… mon dieu je ne conseillerai pas à mon fils de faire du développement. C’est foutu pour lui. Je ne sais pas s’il aurait pu tout réaliser sans rien savoir, mais ça n’en était pas loin. Dans 2 ans, 10 ans… oui la moitié des tâches de développement au moins se passeront probablement d’experts tech.
Ok, c’est de la boule de cristal. Je peux me tromper. 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évolution se fera pendant ma vie professionnelle, et elle sera lourdement impactée.
-
[Lecture] How decentralized is Bluesky really?
Je n’ai pas de citation à mettre en lumière. Le contenu est probablement trop long pour le permettre.
Je recommande toutefois très chaudement la lecture du billet de Christine Lemmer-Webber sur Bluesky, le Fediverse, et la décentralisation à tous ceux qui s’intéressent au sujet.
Il y a de la technique 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 recommande le premier.
Je note d’ailleurs que l’espace de l’ingé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’impression d’être un vieux con
J’ai déjà l’impression d’être un vieux con. Il y a des choses impressionnantes sur l’IA mais ce qui risque surtout de bouleverser mon monde à court terme c’est ce que je vois à travers des expérimentations de Simon Willison.
Il cherche un prompt pour que Gemini identifie l’emplacement d’animaux sur une image. Pourquoi pas.
Là où ça m’intéresse c’est qu’il utilise Claude pour visualiser ensuite si les coordonnées obtenues sont bien pertinentes.
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 corriger par Claude jusqu’à obtenir le résultat attendu.
Il y a eu quelques questions liées à l’orientation des images, et là c’est ChatGPT qui l’aide à déboguer le tout puis générer le code qui modifie l’orientation des images.
Et là… je me sens vieux. J’aurais probablement tout fait à la main, en beaucoup plus de temps, peut-être abandonné au milieu si c’était un projet perso peu important. L’arrivée de l’IA pour tous les petits outils et les petites tâches va vraiment changer la donne pour ceux qui savent l’utiliser.
-
Nouveau tour dans les CSS-in-JS
L’histoire
J’ai abandonné mes premiers amours qu’étaient les feuilles de style séparées avec des nommages bien sémantiques. Je travaille par les applications front-end par composants, j’ai besoin que les styles fonctionnent de façon similaire.
BEM était une bonne idée mais impraticable. Le nommage est pénible et il fallait encore garder une synchronisation entre la feuille de style et les composants. J’ai eu plaisir à trouver CSS Modules mais on continue à 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 composants, toujours synchronisés, mis à jour en même temps, limités chacun au composant ciblé.
Tailwind a trouvé une solution à tout ça en générant statiquement la feuille de style à partir des composants eux-mêmes. Je comprends pourquoi ça plaît mais je n’arrive pas à considérer que redéfinir tout un pseudo-langage parallèle puisse être une bonne idée. On finit toujours par devoir apprendre CSS, que ce soit pour exprimer quelque chose que le pseudo-langage ne permet pas, ou simplement pour comprendre pourquoi le rendu n’est pas celui qu’on imagine.
Je suis parti vers les solutions CSS-in-JS quand je code du React. Faire télécharger et exécuter toute une bibliothèque comme Emotion est loin d’être idéal mais ça reste finalement assez négligeable sur une application front-end moderne.
Entre temps j’ai quand même découvert Goober, qui implémente le principal en tout juste 1 ko. L’élimination des styles morts contrebalance probablement largement ce 1 ko de Javascript. On aurait pu en rester là.
La mise à jour
Je suis quand même gêné de devoir embarquer une bibliothèque Javascript. 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’aller vers du plus simple. On parle de zero-runtime. Les styles de chaque composant sont extraits à la compilation pour créer une feuille de style dédiée. Les parties dynamiques sont faites soit avec des variantes prédéfinies, soit avec des variables CSS qui sont ensuite manipulée par Javascript via les attributs `style`.
Le vénérable c’est Vanilla-extract mais on a juste une version plus complexe et entièrement Javascript des CSS-Modules. C’est d’ailleurs le même auteur, et le même problème fondamental : deux fichiers distincts à manipuler et à synchroniser.
Vient ensuite Linaria qui semble une vraie merveille. Il a l’essentiel de ce que proposent les CSS-in-JS avec de l’extraction statique avec tout ce qu’on attend au niveau de l’outillage : typescript, source maps, préprocesseur et vérification de syntaxe, ainsi que l’intégration avec tous les cadres de travail classiques.
Linaria c’est aussi WyW-in-JS, qui opère toute la partie extraction et transformation, au point de permettre à qui veut de créer son propre outil concurrent à Linaria. Je trouve même cette réalisation bien plus significative que Linaria lui-même.
L’équipe de MUI en a d’ailleurs profité pour faire Pigment-CSS et convertir tout MUI. Pigment reprend tout le principe de Linaria avec la gestion des thèmes, la gestion des variantes, et quelques raccourcis syntaxiques pour ceux qui aiment l’approche de Tailwind. En échange, ces fonctionnalités ne sont possibles qu’en écrivant les CSS sous forme d’objets Javascript plutôt que sous forme de texte CSS directement. La bibliothèque est aussi plus jeune et la compatibilité avec tous les cadres de travail ne semble pas assuré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’utilitaires et de variables par défaut, et injecte beaucoup d’utilitaires dans le Javascript qui sera exécuté avec l’application. C’est un croisement entre Emotion, Tailwind et Linaria, mais qui du coup me semble un peu Frankenstein. À vouloir tout à la fois, on finit par ne rien avoir de franc.
Si c’est pour utiliser avec MUI, le choix se fait tout seul. Dans le cas contraire, au moins pour quelques mois le temps que Pigment-CSS se développe un peu plus, Linaria me semble un choix plus sage. S’il y a quoi que ce soit qui coince, Goober reste une solution pragmatique et tout à fait acceptable.
-
Arrêtons avec les frameworks 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 manifeste agile met en avant « Les individus et leurs interactions, de préférence aux processus et aux outils ».
Prétendre cadrer les individus et les interactions via des processus et des outils méthodologiques est un contre-sens total de ce qu’on a appris depuis le manifeste.
Quand on me demande ma méthode de prédilection je parle de Kanban, parce que l’implémentation dans le logiciel revient juste à limiter le flux et donner une priorité à ce qui est déjà en cours, avec une grande liberté d’implémentation. S’il s’agissait de chercher une implémentation « comme dans la littérature », je rayerais d’un trait et rangerai Kanban avec les autres.
Appliquer des outils et des processus tout faits ça rassure quand on n’a pas confiance dans les individus et leurs interactions.
Le fond c’est la défiance, souvent du top management, même si parfois elle se diffuse jusqu’aux équipes elles-mêmes à force de leur poser des exigences contradictoires.
L’idée c’est souvent que si les résultats ne sont pas ceux espérés c’est que les équipes travaillent mal, alors on va leur expliquer comment il faut travailler en imposant une recette sans chercher à approfondir les problèmes eux-mêmes.
Rien que le présupposé me semble toxique.
Ne vous méprenez pas. Je trouve formidable que Basecamp formalise la façon dont ils fonctionnent. Ce n’est pas une critique de leur fonctionnement. Il y a plein de choses à penser dans la lecture de Shape-up.
Le transposer tel quel avec des rituels, par contre, c’est probablement une mauvaise idée. Transposer quoi que ce soit tel quel est probablement une mauvaise idée d’ailleurs. Le cargo-cult est bien trop présent dans l’univers logiciel, et encore plus dans l’univers startup.
Chaque équipe a ses besoins, des aspirations, ses contraintes, ses individus. Croire que ce qui fonctionne à côté fonctionnera chez nous en le recopiant c’est se tromper de priorité entre les individus et les processus. C’est d’autant plus vrai qu’en général on en applique les artefacts visibles mais pas la philosophie 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’accumuler, surtout qu’ils appartiennent à « la méthode ». S’il faut commencer c’est probablement par SLAP.
Tout n’est pas à jeter. Il y a plein d’idées intéressantes à 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 fonction des besoins, j’aurais tendance à conseiller les points suivants :
- Des rétrospectives régulières, à date fixe
- Des itérations de durée relativement fixe
- Des points de synchro internes fréquents voire quotidiens
- Des démos aux utilisateurs et parties prenantes
- Une notion d’appétit pour les sujets qu’on veut livrer
- Une estimation d’ordre de grandeur de l’effort pour la priorisation
Bref, un kanban avec des cycles qui permettent de régulièrement sortir la tête du guidon, prendre du recul, voir ce qu’on veut changer dans notre fonctionnement, décider quelle direction on veut prendre pour la suite, et de vrais échanges amonts pour expliciter la complexité et l’appétit pour les différents items.
Le reste s’ajoute avec grande prudence. Sauf besoin spécifique j’aurais tendance à déconseiller les items suivant :
- Les engagements de livraison, hors besoin absolu (on ne décalera pas Noël)
- Les estimations autres que des ordres de grandeur
- Les backlogs (oui oui, vous avez bien lu)
- Avoir plus d’un objectif par itération
- Avoir déjà étudié la solution avant de commencer
- Tenter d’appliquer ce que d’autres équipes font dans d’autres contextes au sein d’autres cultures