Voilà 9 mois que j’ai recommencé à programmer, depuis que j’ai rejoins Zenride en juillet dernier, pour qui j’occupe le poste de directeur technique (j’y reviendrais dans un autre article). Me voilà donc à nouveau plongé dans le code à longueur de journée !

Ce n’est pas un souci car au fond j’ai toujours aimer coder. J’ai commencé au lycée je crois, et dès la première, à l’été 2003, une agence Web m’avait fait confiance pour travailler l’été (coucou Stéphane !). Le hasard a fait que pendant mes études d’ingénieur, j’ai co-fondé Owlient, dont le succès m’a amené au bout d’un an à m’éloigner du code. Si j’ai passé la douzaine d’années suivante dans des fonctions de direction générale, j’ai toujours été proche au quotidien des équipes produisant les logiciels (ingénieur, chef de projet, directeur artistique, graphiste, etc…). C’est ce qui m’a amené l’an dernier à réaliser que ce qui me plait le plus, c’est concevoir un produit, et en être responsable.

Après 9 mois à concevoir et surtout développer, je me rend compte que j’aime toujours ça, pas de doute ! Et surtout, je comprend mieux les enjeux du métier après avoir géré des équipes de production. Il y a beaucoup de choses que je savais, mais que je n’avais pas vécu personnellement. Maintenant je les comprends 🙂

Voici donc en vrac quelques réflexions qui me sont venues lors de ces derniers mois. Cela paraitra sûrement évident pour beaucoup, mais ça va mieux en le disant !

Mon poste de travail pendant le confinement. Je suis content d’avoir récupéré un écran juste avant…

Concentration

J’ai très vite réalisé à quel point ce travail demande beaucoup de concentration. À Owlient, Vincent avait trouvé la notion de tâche atomique, qu’il invoquait régulièrement pour ignorer royalement mes demandes de réunion. Maintenant je comprends ! Quand on est dérangé, cela coûte en temps pour se re-concentrer, pour retrouver le fil. Mon cauchemar, c’est la journée avec une réunion à 10h30 et une autre à 15h… J’ai besoin d’avoir des demi-journée, idéalement des journées pleines pour travailler sérieusement et efficacement.

Importance du sommeil

Il n’est jamais bon de manquer de sommeil, quelque soit le métier. Mais quand celui-ci demande justement de la concentration, c’est critique. J’ai vite réalisé l’impact du sommeil sur mon travail. Non pas que je travaille moins en quantité si je manque de sommeil. Mais je suis moins concentré, je manque d’attention, et cela se traduit par plus de bug, et au global plus de temps pour faire ce que j’ai à faire. Quand on parle de productivité, il n’y a pas que les outils, les environnements de travail ou le management. On peut commencer par un bon sommeil 🙂

Technique et business

Être dérangé c’est une chose. Mais être dérangé pour des questions business demande en plus de jongler entre deux univers de pensées très différents. Étant associé chez Zenride, on a quotidiennement des discussions sur le business et ses enjeux, c’est inhérent au rôle de fondateur. Cela me passionne toujours autant et je suis à l’aise avec cela. Mais je n’avais pas réalisé qu’en tant que directeur technique, on avait tout un autre monde à penser, et que passer de l’un à l’autre, à fortiori plusieurs fois par jours, demande beaucoup d’effort pour se concentrer sur l’un ou l’autre.

Tester et implémenter

Voilà typiquement quelque chose que je savais, mais que je ne comprenais pas (ou n’admettais pas !). Je parle de la différence entre tester une solution, et l’implémenter complètement dans un système d’information. Qui n’a pas entendu les fameux “notre API se branche en quelques minutes”, “notre outil s’intègre en quelques heures”, etc. Et moi j’y croyais quand j’étais du côté du demandeur 🙂 Souvent ce n’est pas faux d’ailleurs, c’est très rapide de “faire joujou” avec et comprendre le fonctionnement. Et puis après, il y a l’intégration propre dans le système d’information de façon pérenne, avec toute sa logique métier. Et là, on change radicalement d’ordre de grandeur en terme de délai…

Solution sans problème

Même si j’ai toujours codé un peu et me suis tenu informé sur le développement Web, cela relevait du passe temps, et j’ai donc du me remettre rapidement à niveau. Ce n’est pas évident cela dit de faire le tri dans toutes les technos “à la mode” et distinguer ce qui est réellement utile dans mon cas, de ce qui relève du nice-to-have. Cela commence par être réaliste sur les besoins réels de “scalabilité” du logiciel, et ne pas sur-architecturer. Aussi sexy et en vue soit une solution ou une technologie, si je ne constate pas le problème qu’elle adresse et n’ai pas de conviction que je vais le rencontrer à court ou moyen terme, alors je ne l’utilise pas. J’essaye de m’en tenir à ce bon sens, car étant pour l’instant seul à développer, je n’ai pas d’autres choix que de faire simple.

J’aurai sûrement d’autres réflexions au fur et à mesure que j’avancerai dans ma seconde vie de développeur 🙂