From Software Engineers to Product Engineers

Je me suis souvent posé la question de la place d’un développeur dans cette ère de l’IA. La question de la formation des juniors, qui sont censés être les seniors de demain. La question de la répartition des rôles dans ce qu’on appelle encore une feature team : le PO qui s’occupe de comprendre le besoin, de le traduire en specs plus ou moins techniques, et les Software Engineers qui se chargent de comprendre, de déchiffrer ce besoin plus ou moins clair en se basant sur leur expérience technique, mais surtout sur leur connaissance du contexte, de l’environnement, du produit dans lequel s’inscrit ce besoin, et d’un dernier truc : leur intuition business & tech.

Pour moi, un bon Software Engineer a toujours été celui qui ne se limite pas à écrire du code de façon bête et méchante. Ça a toujours fait partie du job, mais personnellement, j’ai toujours trouvé que ce n’est pas là où on attend un Software Engineer, notamment un Software Engineer senior ou un tech lead. Le pourquoi a toujours été plus important que le comment, ou mieux : la compréhension du quoi et du pourquoi intuitent de la qualité du comment.

Les agents sont aujourd’hui de plus en plus excellents sur le comment, sur la rédaction de stacks techniques qui répondent au comment. Mais la vraie question qui demeure est le quoi. Le pourquoi. Pourquoi cette nouvelle feature ? Qu’est-ce qui donne le sentiment que c’est un besoin réel, présent ou futur, de l’utilisateur ?

Ces questions ont trop souvent été considérées comme l’affaire du PO et de la discovery. Si les agents font le comment, à quoi servent alors les Software Engineers ? Ils sont censés comprendre finement, de pair avec leur PO, le quoi. Ils sont censés comprendre la valeur business e2e, et a minima dans leur scope.

Ce que vivent aujourd’hui les Software Engineers me fait penser au shift qui a commencé il y a quelques années avec le rôle de Data Engineer (oui, je suis un peu biaisé, car je suis Data Engineer de base). Dans la sphère data, le Data Engineer qui se chargeait uniquement de faire des pipelines d’ETL capables, à partir de sources a, b, c, de produire des tables et des vues x, y sur la base de descriptions techniques des sources et de l’attendu final fournies par un Data/Business Analyst qui, lui, comprenait le business, avait son importance et toute sa place quand il était hyper compliqué de faire ces pipelines. Le scaling avec le calcul distribué (spark 🧟‍♂️) était hyper complexe, le java/scala était le langage de base pour le faire, et surtout il y avait peu d’outils et d’abstractions facilitant ce travail-là.

Avec l’avènement des data platforms, d’outils d’ETL en no-code, low-code ou full sql-friendly, le coût de création de pipelines d’ETL efficaces a drastiquement baissé. Le métier de Data Engineer a dû se réinventer, pour être plus business oriented. C’est ainsi qu’on a vu naître le métier d’Analytics Engineer : une fusion entre le Data Analyst (business-focused) et le Data Engineer (tech-focused).

C’est exactement ce qui se passe pour les Software Engineers. Code is now cheap, so the main part of the work is understanding business, the needs, challenge them, and then write the specs, prompt them to agent, and then deploy x scale features in production.

Tout comme les Data Eng se sont transformés en Analytics Engineers, les Software Eng devront faire leur mue en Product Engineers.