Comprendre avant de construire
Je commence par comprendre l’usage, les besoins et les contraintes du produit. Les échanges avec l’équipe hardware m’aident à relier les choix logiciels à ce qui se passe sur le terrain.

J'aime comprendre comment un produit fonctionne, du matériel au logiciel. Mon travail se construit aussi dans les échanges avec l'équipe, les choix que l'on partage et ce que l'on transmet.
Je commence par comprendre l’usage, les besoins et les contraintes du produit. Les échanges avec l’équipe hardware m’aident à relier les choix logiciels à ce qui se passe sur le terrain.
Je travaille par étapes, avec des échanges et des revues de code. Partager les questions et les résultats au fil du développement permet de confronter les choix et d’avancer ensemble.
Je cherche une solution adaptée aux contraintes, que l’équipe pourra maintenir et faire évoluer. Je valide progressivement sur le matériel réel, en gardant en tête la vie du produit après son déploiement.
Je documente les décisions, les étapes de build et les points utiles à la maintenance. Pour pouvoir reprendre mon travail quelques mois plus tard, et pour qu’un collègue puisse prendre le relais.
Pendant mon alternance chez FDI, cette approche a pris forme dans le développement et la maintenance de systèmes Linux embarqués.
Mon travail chez FDI