La courbe d’apprentissage est vraiment déraisonnable. En échange de la garantie de reproductibilité, il exige un niveau élevé.
Même avec flake, c’est compliqué.
Il semble aussi utiliser SQLite en interne, et comme les performances sont assez irrégulières, il y a une certaine fluctuation du temps nécessaire pour reproduire à nouveau un environnement.
Qu’est-ce qu’un bon leader, un bon manager, ou un bon membre d’équipe ? Parfois, une personne qui est manager est aussi le coéquipier de quelqu’un d’autre…
Oui, en ce moment, deux points de vue s’affrontent. Celui dont on parle le plus est la thèse du remplacement, et de temps en temps revient un optimisme comme dans cet article.
Personne ne peut connaître l’avenir, bien sûr, mais si la thèse dominante est celle du remplacement, je pense qu’il est aussi utile d’examiner l’argument inverse.
Il existe de nombreux arguments du côté optimiste, mais j’ai voulu reprendre l’une des vieilles théories, le paradoxe de Jevons.
Sur le marché actuel, avec la transformation des développeurs indépendants en entreprises unipersonnelles, les prix baissent rapidement, depuis les simples pages de présentation web. Du coup, même des petits commerçants ou des PME qui n’auraient jamais envisagé de créer un site web commencent à avoir chacun un site tout à fait correct.
Autrement dit, j’ai jugé que la tendance allait bien dans le sens d’un élargissement du marché lui-même. En particulier, les SaaS sortent à un rythme effréné, et la concurrence par les prix s’intensifie aussi, parfois sans qu’on s’en rende compte. Si les prix baissent, le nombre d’entreprises et de particuliers qui adoptent ces solutions augmentera, et le marché dans son ensemble grandira clairement, à mon avis.
Ensuite, la direction pourrait être l’une des deux suivantes. Soit une seule personne continue d’augmenter le nombre de services qu’elle gère, soit un autre développeur apparaît pour absorber cette demande.
Comme la quantité qu’un humain peut traiter et gérer a forcément des limites, je me demandais si, au bout du compte, on ne pourrait pas revenir vers une dynamique d’embauche de développeurs juniors pour absorber cette demande — puisque la ressource qui a été laissée de côté par le marché jusque-là, ce sont justement les développeurs juniors.
Bien sûr, les compétences demandées à ces développeurs juniors seront alors très différentes de celles d’aujourd’hui. Et je ne sais pas non plus si la question des salaires sera comparable à ce qu’on a connu par le passé. Pour être honnête, je ne sais pas non plus à quel moment cela pourrait arriver...
Et merci d’avoir lu mon message et d’en avoir fait une analyse aussi attentive~ C’était vraiment enrichissant.
Pour inclure la perspective du paradoxe de Jevons, il faut d’abord définir ce qui constitue la ressource.
Puisqu’il s’agit d’un texte qui analyse les perspectives de la demande de développeurs, la ressource dans ce texte doit donc être le développeur.
L’industrie décrite classiquement par le paradoxe de Jevons (machine à vapeur <-> charbon) et l’industrie logicielle présentent de nombreuses différences.
Les biens numériques sont des biens non rivaux, dans une industrie où le coût marginal est presque nul. Autrement dit, c’est une industrie centrée sur les coûts fixes.
Dans ce type d’industrie, les gains de productivité se traduisent généralement par une réduction ou un gel des effectifs, ainsi que par un renforcement de l’effet de levier des équipes existantes.
Pour que le paradoxe de Jevons s’applique, la demande doit être très sensible au prix, et la baisse des coûts doit entraîner directement une explosion de la demande.
Le développement logiciel ne se fait pas par le développeur seul. Le goulot d’étranglement n’est pas le « coût du code », mais les coûts de planification, de risque, d’exploitation, d’organisation et de conformité réglementaire.
Jusqu’à présent, la plupart des logiciels qui n’ont pas été développés ne l’ont pas été parce qu’ils n’étaient pas nécessaires / qu’ils n’offraient pas de ROI / qu’ils ne pouvaient pas être exploités, et non parce qu’ils étaient trop coûteux à produire.
Il existe un effet d’optique dans les indicateurs de productivité.
Les indicateurs utilisés dans le texte (hausse du volume de code généré, hausse des PR, hausse du volume des déploiements) sont tous des indicateurs « d’activité ».
Une hausse du volume de code n’augmente pas la valeur. Une augmentation des PR entraîne une hausse des coûts de revue et de validation, et le code généré par l’IA accroît les risques en matière de qualité et de sécurité.
En d’autres termes, le code produit par l’IA augmente la dette technique, les coûts de débogage et la complexité opérationnelle.
Par conséquent, les gains de productivité pourraient ne pas augmenter de façon aussi spectaculaire que les indicateurs d’activité le laissent penser.
Reconnaître une « falaise des juniors » tout en restant optimiste est contradictoire.
Contrairement au charbon, les développeurs évoluent d’un statut junior vers un statut senior.
Si le nombre de juniors diminue, le nombre de futurs seniors diminue aussi. Par conséquent, à moyen et long terme, le vivier global de développeurs se contractera.
La croissance de la taille du marché et la croissance de l’emploi ne sont pas identiques.
En particulier, l’IA est une industrie intensive en capital, non pas une industrie qui « emploie plus de personnes », mais une industrie qui « crée une plus grande échelle avec moins de personnel ».
Les développeurs sont des personnes, et les salaires humains ont des caractéristiques différentes du prix du charbon.
Sur le marché du travail, les salaires ne baissent pas de manière parfaitement flexible, de sorte que la baisse des coûts ne se transmet pas suffisamment à la baisse des prix.
Les salaires présentent en pratique une rigidité à la baisse. Cela tient au salaire minimum, au droit du travail, aux structures contractuelles, à l’équité interne des organisations, ainsi qu’aux risques de démotivation et de départ.
En d’autres termes, lorsque la productivité augmente, les entreprises ne baissent pas les salaires ; elles réduisent les recrutements.
« Le problème, c’est que cela nous fait prendre une vague impression (vibe) pour une abstraction précise » — je trouve ça très parlant. L’abstraction, justement, n’est possible que pour ceux qui ont compris le bas niveau dans une démarche bottom-up.
C’est embêtant quand ce qui fonctionnait ne fonctionne plus, mais rien que le fait d’avoir débarrassé tout ce spaghetti bricolé sur X11 pour faire en sorte que ça marche suffit largement à lui accorder du crédit.
Cela dit, quand on cherche pourquoi certaines choses ne fonctionnent toujours pas, le problème est au fond l’absence de standardisation, et il est vrai que ce processus prend plus de temps que prévu.
On dira sans doute encore en 2030 qu’on est loin d’une version vraiment aboutie, mais un retour à X11 sera impossible.
Même si le changement d’écosystème provoque une phase de confusion, n’importe quel remplaçant entendra exactement les mêmes reproches, et un retour en arrière risque surtout de susciter une réaction de rejet dans un écosystème auquel les gens se seront habitués.
J’avais déjà vu quelque part une suggestion disant qu’en coréen, au lieu de « manger sa propre nourriture pour chien », on pourrait dire « manger les repas faits maison », et je trouvais aussi que « manger les repas faits maison » sonnait plutôt bien.
Je pense qu’il faut voir si cela peut être remplacé par d’autres méthodes de validation. Plus on est proche du front, plus on peut probablement vérifier que cela fonctionne bien rien qu’avec de l’E2E via le comportement du navigateur. En revanche, plus le code est proche du back et de l’infrastructure, plus la revue de code me semble indispensable. Sinon, il sera difficile de valider des effets de bord invisibles, comme des transactions qui s’ouvrent et se ferment ou des appels d’API qui partent.
S'il vous plaît, donnez beaucoup d'amour à RollerCoaster Tycoon.
La courbe d’apprentissage est vraiment déraisonnable. En échange de la garantie de reproductibilité, il exige un niveau élevé.
Même avec
flake, c’est compliqué.Il semble aussi utiliser SQLite en interne, et comme les performances sont assez irrégulières, il y a une certaine fluctuation du temps nécessaire pour reproduire à nouveau un environnement.
Censé fonctionner, mais chez moi ça ne marche pas :'(
Qu’est-ce qu’un bon leader, un bon manager, ou un bon membre d’équipe ? Parfois, une personne qui est manager est aussi le coéquipier de quelqu’un d’autre…
Merci de normaliser ça avec Electron...
Il sort tellement de projets tous les jours que s’il y avait au moins une capture d’écran, ça me donnerait envie de l’essayer tout de suite.
Partout, les gens se ressemblent finalement un peu, on dirait. :)
Linux n’est pas pris en charge 😭
Ouiii~ le simple fait d’écrire un texte qui suscite ce genre de débat suffisait déjà à faire passer l’intention.
Les IDE et les PR sont tous morts, mais le code, lui, a ressuscité ?
Oui, en ce moment, deux points de vue s’affrontent. Celui dont on parle le plus est la thèse du remplacement, et de temps en temps revient un optimisme comme dans cet article.
Personne ne peut connaître l’avenir, bien sûr, mais si la thèse dominante est celle du remplacement, je pense qu’il est aussi utile d’examiner l’argument inverse.
Il existe de nombreux arguments du côté optimiste, mais j’ai voulu reprendre l’une des vieilles théories, le paradoxe de Jevons.
Sur le marché actuel, avec la transformation des développeurs indépendants en entreprises unipersonnelles, les prix baissent rapidement, depuis les simples pages de présentation web. Du coup, même des petits commerçants ou des PME qui n’auraient jamais envisagé de créer un site web commencent à avoir chacun un site tout à fait correct.
Autrement dit, j’ai jugé que la tendance allait bien dans le sens d’un élargissement du marché lui-même. En particulier, les SaaS sortent à un rythme effréné, et la concurrence par les prix s’intensifie aussi, parfois sans qu’on s’en rende compte. Si les prix baissent, le nombre d’entreprises et de particuliers qui adoptent ces solutions augmentera, et le marché dans son ensemble grandira clairement, à mon avis.
Ensuite, la direction pourrait être l’une des deux suivantes. Soit une seule personne continue d’augmenter le nombre de services qu’elle gère, soit un autre développeur apparaît pour absorber cette demande.
Comme la quantité qu’un humain peut traiter et gérer a forcément des limites, je me demandais si, au bout du compte, on ne pourrait pas revenir vers une dynamique d’embauche de développeurs juniors pour absorber cette demande — puisque la ressource qui a été laissée de côté par le marché jusque-là, ce sont justement les développeurs juniors.
Bien sûr, les compétences demandées à ces développeurs juniors seront alors très différentes de celles d’aujourd’hui. Et je ne sais pas non plus si la question des salaires sera comparable à ce qu’on a connu par le passé. Pour être honnête, je ne sais pas non plus à quel moment cela pourrait arriver...
Et merci d’avoir lu mon message et d’en avoir fait une analyse aussi attentive~ C’était vraiment enrichissant.
Pour inclure la perspective du paradoxe de Jevons, il faut d’abord définir ce qui constitue la ressource.
Puisqu’il s’agit d’un texte qui analyse les perspectives de la demande de développeurs, la ressource dans ce texte doit donc être le développeur.
« Le problème, c’est que cela nous fait prendre une vague impression (vibe) pour une abstraction précise » — je trouve ça très parlant. L’abstraction, justement, n’est possible que pour ceux qui ont compris le bas niveau dans une démarche bottom-up.
Merci pour la version Canary
C’est embêtant quand ce qui fonctionnait ne fonctionne plus, mais rien que le fait d’avoir débarrassé tout ce spaghetti bricolé sur X11 pour faire en sorte que ça marche suffit largement à lui accorder du crédit.
Cela dit, quand on cherche pourquoi certaines choses ne fonctionnent toujours pas, le problème est au fond l’absence de standardisation, et il est vrai que ce processus prend plus de temps que prévu.
On dira sans doute encore en 2030 qu’on est loin d’une version vraiment aboutie, mais un retour à X11 sera impossible.
Même si le changement d’écosystème provoque une phase de confusion, n’importe quel remplaçant entendra exactement les mêmes reproches, et un retour en arrière risque surtout de susciter une réaction de rejet dans un écosystème auquel les gens se seront habitués.
C'est agréable de manger un repas fait maison.
J’avais déjà vu quelque part une suggestion disant qu’en coréen, au lieu de « manger sa propre nourriture pour chien », on pourrait dire « manger les repas faits maison », et je trouvais aussi que « manger les repas faits maison » sonnait plutôt bien.
Je pense qu’il faut voir si cela peut être remplacé par d’autres méthodes de validation. Plus on est proche du front, plus on peut probablement vérifier que cela fonctionne bien rien qu’avec de l’E2E via le comportement du navigateur. En revanche, plus le code est proche du back et de l’infrastructure, plus la revue de code me semble indispensable. Sinon, il sera difficile de valider des effets de bord invisibles, comme des transactions qui s’ouvrent et se ferment ou des appels d’API qui partent.
Je me demande quand le WYSIWYG de WinUI 3 sortira enfin.
Waouh !! Garry Tan a retweeté GeekNews.
https://x.com/garrytan/status/2035898375934300353