perri.to: Un méli-mélo de choses (by Horacio Duran)

Professionnellement, si je devais le résumer en une seule phrase, je dirais ceci :

J’ai toujours choisi les outils que quelqu’un était prêt à me payer le plus cher pour les utiliser.

Tout a commencé avec Visual Basic 6.

À l’époque, du moins dans mon pays, c’était le langage dominant pour les applications de gestion. Cabinets comptables, entreprises de taille moyenne, systèmes de gestion internes : tout tournait sous VB6. Je suis devenu très efficace avec lui. Pas seulement productif : j’ai appris comment il fonctionnait en profondeur, ses limites, ses bizarreries.

Avec le temps, les gens ont commencé à m’appeler pour optimiser des programmes qui avaient grossi au-delà de ce qu’un simple « développeur de logique métier » pouvait gérer.

Qu’est-ce que cela signifiait ?

Les applications démarraient petites, grandissaient en même temps que l’entreprise, et finissaient par se heurter à un mur de performance. Visual Basic 6 n’était pas vraiment conçu pour du traitement lourd, mais à l’époque les « grosses charges de travail » n’étaient pas aussi grosses qu’aujourd’hui. Le matériel avait des contraintes bien réelles, et savoir comment en extraire de la performance faisait la différence.

J’ai toujours été curieux de la façon dont les outils fonctionnent à bas niveau. Cette curiosité m’a permis d’optimiser du code qui avait été écrit en pensant aux règles métier, mais pas nécessairement en mettant l’accent sur les modèles de mémoire, les coûts d’exécution ou le comportement interne.

Bien sûr, il y avait des alternatives comme Java, utilisées par les plus grandes entreprises et les équipes plus formelles. Mais je me suis concentré sur la niche qui avait le plus de sens pour moi professionnellement. Et cette niche était simple : partout où beaucoup de développeurs travaillaient, des goulots d’étranglement de performance finissaient par apparaître. C’est là que j’intervenais.

Le passage au web

Vers 2003 ou 2004, j’ai remarqué un changement. Les développeurs qui construisaient autrefois des applications de bureau en VB6 passaient à PHP.

Jusque-là, le web était surtout un moyen de publier de l’information. Mais après la bulle des dot-com, quelque chose a commencé à changer : les applications ont commencé à migrer du bureau vers le navigateur. Elles étaient primitives, mais de toute évidence, quelque chose se produisait.

Alors j’ai appris PHP.

Et une fois de plus, j’ai fait ce que je savais faire : optimiser, trouver les goulots d’étranglement, comprendre les limites du runtime. Les premières versions de PHP étaient sujettes à des problèmes de mémoire, en partie parce qu’elles étaient conçues pour des cycles d’exécution de courte durée -afficher une page et sortir- et non pour des processus de longue durée ou des charges de travail lourdes.

Cela m’a ouvert une niche semblable à celle que j’avais auparavant, mais dans un domaine complètement différent.

PHP a explosé en popularité. Ironiquement, c’est ce qui m’a fait commencer à réfléchir : plus il devenait grand public, moins il y aurait de place pour une spécialisation poussée. Les marchés saturés compriment les marges.

Alors j’ai recommencé à regarder devant moi.

Python et la compréhension approfondie du langage

Grâce à mon groupe local d’utilisateurs de Linux, j’ai découvert Python ; je crois que c’était la version 2.1 à l’époque.

J’étais fasciné.

Il avait des bizarreries intéressantes, et j’ai passé beaucoup de temps à affiner ma compréhension de celui-ci. Quelque part durant ces années, un ami à moi, Diego Sarmentero, a lancé un éditeur appelé Ninja IDE. Je l’ai aidé, et ce projet m’a forcé à vraiment comprendre de nombreux aspects de bas niveau de Python.

Python m’a toujours frappé comme intéressant d’une manière particulière : le code le plus académiquement « correct » n’était pas toujours le plus efficace. Instancier de nombreux objets en suivant strictement les paradigmes orientés objet pouvait être élégant, mais dans des scénarios de forte contention (comme des endpoints REST très sollicités), la pression sur la mémoire peut devenir importante.

Il y avait beaucoup de marge pour progresser avec Python. Le langage évoluait rapidement et semblait prometteur.

Mais alors une autre opportunité s’est présentée.

Canonical, Juju et la découverte de Go

J’ai rejoint Canonical pour travailler sur Juju, un système d’orchestration cloud qui a fini par perdre la course face à Kubernetes (certains soutiendraient qu’ils n’étaient pas du tout dans la même course).

Quel que soit ce résultat, cette période m’a fait découvrir Go.

J’ai tout de suite senti que Go avait quelque chose de spécial dans l’espace du cloud. Je me suis spécialisé autant que possible et j’ai passé de nombreuses années à travailler avec lui. Aujourd’hui encore, quand je démarre un nouveau projet personnel, Go est souvent mon choix par défaut, à moins qu’une autre technologie ne soit clairement plus adaptée.

Chance ou schéma ?

Professionnellement, on pourrait dire que je suis comme un chat : j’ai tendance à retomber sur mes pattes.

Peut-être (et probablement) est-ce plus de la chance que du talent, mais je me suis constamment orienté vers des outils qui sont ensuite devenus commercialement viables. Cela dit, en y réfléchissant plus attentivement, peut-être que je ne choisis pas des langages de programmation.

Peut-être que je choisis le prochain outil qui permet de construire des produits que quelqu’un est prêt à acheter.

Et maintenant ?

Aujourd’hui, je ne pense pas que la prochaine étape soit un langage, ni même un framework.

C’est un LLM. Ou une combinaison d’outils assistés par l’IA.

La question n’est plus « Quel langage devrais-je utiliser ? », mais plutôt :

Quelle combinaison d’outils me permet de construire des services viables, maintenables et commercialement pertinents ?

Le langage devient une simple cible de compilation pour les idées.

Cette fois, ma niche réside peut-être dans l’expérience architecturale. Dans le fait de savoir quoi demander à ces outils de générer. Dans le fait de les guider vers quelque chose qui non seulement fonctionne aujourd’hui, mais reste maintenable demain.

C’est peut-être la fois où je me trompe.

Mais il n’y a qu’une seule façon de le savoir.