Je prépare une présentation avec mon collègue Théotime pour la conférence Cloud Nord 2024 à Lille, après Devoxx Belgique 2024. Je viens de me rendre compte que cela fait 10 mois. 10 mois que j’ai rejoins Back Market comme Principal Engineer. J’ai eu envie d’écrire cet article pour expliquer comment j’ai intégré ce rôle. Il pourra aider ceux qui changent d’entreprises, et qui prennent de nouvelles fonctions. Prenez un bon café et bonne lecture !
La première semaine
J’étais attendu. J’ai rejoins l’entreprise car celle-ci est en pleine migration. C’est d’ailleurs impressionnant, et l’une des motivations pour moi, c’est de comprendre « mais comment font-ils ? ».
Durant cette première semaine, je comprends que l’entreprise est actuellement :
- en pleine migration du monolithe vers des services, le tout programmé sur 9 mois, avec un Technical Program Manager, 1 Senior Staff Engineer, et l’ensemble des développeurs backend. Ce monolithe est une application Django en Python, sur laquelle il n’y a presque plus de frontend
- en pleine migration de l’ancien monolithe Frontend, une application en Vue2 et en Nuxt2 pour le backend, vers 6 applications Vue3/Nuxt3 dans un monorepo.
- en pleine migration d’AWS vers GCP, programmé pour se terminer au 2ème trimestre de cette année
En arrivant, je reçois un document préparé par notre CTO, Dawn Baker. Elle m’indique une liste de personnes à rencontrer, et je me retrouve rapidement à faire des 1-1 avec des managers, des développeurs, la CPO, un chef marketing, etc.
Si vous venez à accueillir des Staff dans votre équipe, je trouve que l’exercice est sympa. Il de partager rapidement les points en cours, et de donner les noms des personnes à contacter.
En parallèle de cela, je retrouve Dimitri Baeli, un vieil ami avec qui j’avais travaillé entre 2000 et 2003 chez Dotvision. Il sera mon « buddy » pour m’accompagner durant les premiers mois chez Back Market.
D’ailleurs j’annonce la couleur lors du premier « All-Hands » devant toute les personnes de la tech : je m’appelle Nicolas et venez faire un café virtuel avec moi. Cela va m’amener une dizaine de rendez-vous. J’ai discuté avec beaucoup de personnes, l’effet curiosité étant réciproque.
La première semaine se passe dans les bureaux de Back Market à Paris. Je suis avec l’ensemble des personnes qui démarrent en janvier. Nous avons une semaine de présentations, pour se familiariser avec l’entreprise, les outils et les différentes équipes.
Sans rien changer, voici ma 2eme semaine ci-dessous :
Le code couleur :
- en orange c’est l’équipe Checkout que je rejoins, pour bosser sur les assurances
- en bleu foncé, j’indique les 1-1
- en bleu clair je met « le reste »
- en vert ce qui concerne le recrutement, car je suis mis dans la boucle du recrutement d’un VP Platform (qui est arrivé cet été) dès le début
Le vendredi 19 je recontacte Loïck le Digabel (Loki), qui a quitté Back Market, mais qui a été le lead Frontend l’année précédente. Je vois qu’il y a un sujet autour des équipes Frontend, et que cela va certainement devenir un programme à traiter.
Démarrage dans une équipe comme « stagiaire »
Je démarre dans l’équipe « Checkout », après avoir discuté avec la CTO, qui avait anticipé le sujet avant mon arrivée. Je rejoins une équipe sans développeur sénior mais avec un super développeur junior, Arnaud, qui est un peu seul pour migrer un service important. J’ai été son « stagiaire » à temps partiel, et j’ai pu apprendre et monter en compétences rapidement. Ma volonté était d’apprendre à coder avec Django et Python, et aider l’EM à réussir cette grosse migration. Cette première activité va remplir 60% de mon temps, jusqu’au mois d’avril. Nous réussirons à écrire le code et à faire la bascule de fournisseurs sans perdre un seul client. J’utilise ce projet pour découvrir le monolithe historique, la C.I, la mise en prod, l’observabilité, les tests end-to-end, etc.
Le premier mois
A la fin du mois de janvier, je suis lancé. Je code et développe en Python sur le monolithe « historique ». Mon code est vraiment pas très compliqué, cela vous rend très modeste quand vous avez aussi une vingtaine d’années d’expériences. Mais après 2 ans de Ruby (mon niveau était mauvais), j’avoue que je préfère rapidement mon expérience avec Python (il y a des Types !) et Django (le cousin de Play! Framework). J’en fait assez pour comprendre, découvrir la C.I, la mise en prod, et le fonctionnement de l’entreprise sur ce point.
Je fais encore pas mal de 1-1, et j’arrive à discuter avec des gens du marketing, de la partie SEO, du business, et de la sécurité. Je vois aussi qu’il y a un sujet autour de Datadog, mais je me suis promis de ne pas refaire encore de la Plateforme, comme je l’ai fait chez Doctolib l’année précédente. Restez jusqu’à la fin, car je vais faire une rechute dans 5 minutes…
Le deuxième gros sujet sur lequel on m’invite, c’est la migration de la stack Frontend. Le projet avance, mais on sent une forte tension entre les équipes produits et les développeurs. C’est un peu dans le dur.
Il y a bien un programme qui est piloté par un des directeurs, mais c’est difficile pour lui de tout mener. Les personnes qui restent et qui doivent gérer la migration ont beaucoup de pression. Certaines équipes métiers ont profité de cette migration pour refaire de A à Z leurs écrans. Pas de souci à cela. Mais chez moi, on appelle cela une évolution produit, et ici parfois , c’est du temps technique utilisé pour faire une nouvelle version du produit… Il va être urgent de reprendre le contrôle.
Alors un Principal Engineer adore ce genre de sujet :
- impact important sur 25 développeurs
- enjeux business à venir
- des tonnes de promesses comme « Vue3 avec TypeScript, ça sera mieux que Vue2 avec JS » à tenir
- des gens qui ne comprennent rien et qui ont un avis sur ce qu’il faudrait faire (mes préférés)
- un programme avec des listes de pages à migrer, des réunions, un suivi (le rêve pour un TPM)
On garde le sourire, on attache sa ceinture, et on reprend le lead sur cette migration. Je passe du temps à lire du code, à relire sur Confluence tout le travail qui a été fait, à interviewer des développeurs, et à mettre enfin une stratégie en place.
Le premier semestre
Je termine mon « stage » dans l’équipe Checkout peu avant Devoxx France, en avril. Deux nouveaux développeurs ont été embauché, et je peux passer la main sans soucis.
Autre « tips » aussi que j’utilise lorsque je rejoins une équipe : je demande à passer du temps avec chacun des développeurs, que ce soit backend, frontend ou mobile. Cela permet de voir comment chacun travaille, et on passe toujours un moment intéressant.
La grosse différence entre Doctolib et Back Market ? Il n’y a pas de développeurs « full-stack ». Chacun est « Backend » (python/go), « Frontend » (Vue3/Nuxt3/TypeScript) ou « Mobile » (Android et iOS). Cela va jusqu’à l’ajouter sur le titre et la signature. Je regrette parfois de ne pas avoir de personnes full-stack, mais quelques développeurs se baladent entre les deux. Il y a des développeurs « Back » qui font du « Front ». Mais l’inverse semble une hérésie… C’est dommage, et j’espère changer cela dans les mois qui viennent. A titre personnel, j’ai toujours essayé de faire « tout » et de ne pas m’enfermer dans un domaine.
La « Back-Con »
A votre avis, que se passe-t-il quand l’un des gars qui organise Devoxx France, se retrouve dans votre entreprise ? Et bien il va vous aider à organiser une conférence interne ! Je rencontre 2 développeuses de nos équipes de Bordeaux, Jessica et Estelle. Elles ont lancé l’idée d’organiser une conférence interne, avec l’ensemble des développeurs. Je trouve l’idée géniale (ok, je suis facile à convaincre…) et je leur propose de l’aide.
Mardi 18 juin 2024, Back Market a organisé sa premiere conférence en interne, à Bordeaux ! Plus de 60 personnes, des sujets courts, des sujets longs, et des hands-on labs… C’était génial.
Je ne me suis pas arrêté là.
Cet été je souffle une idée à Guillaume Amat, un des leads Frontend de Back Market.
Dis-donc, ça serait sympa de faire un événement avec l’ensemble des développeurs Frontend, et aussi de faire un Meetup le soir avec la communauté Front de Bordeaux…
Il a envoyé directement et je vous annonce que nous serons sur Bordeaux la semaine du 14 octobre, avec une soirée le 15 octobre dans nos locaux de Bordeaux… hé hé hé.
Il faut tuer Pastrami, le monolithe Frontend
Nous arrivons vers le mois de juin. J’ai repris complètement le programme de migration de l’ancien monolithe (appelé « Pastrami », Vue2/Nuxt2/JS) vers « Front-apps » (Vue3/nuxt3 et TypeScript). Le tout empaqueté dans un projet appelé « FSM ».
Cher lecteur, à ton avis que veut dire FSM ?
Les gens dans la boîte avaient chacun une traduction, mais jamais la bonne. Cela donnait « Frontend Stack Migration » ou « Frontend Stack Modernization« … D’autres pensaient que c’était le nom du projet (perdu), le nom du repository (re-perdu), le nom du projet sur JIRA (gagné ! mais Jira en meme temps…)
On se retrouve dans un projet de migration. Une trentaine d’équipes, et 26 développeurs Frontend. Pourquoi tuer l’ancien monolithe ? Vue2 est « end-of-life » depuis décembre 2023 et Nuxt2 depuis le 30 juin 2024. C’est aussi l’occasion de rembourser une dette technique…
L’expérience de développement sur Pastrami est assez… comment le dire gentiment ? … curieuse. On remercie Apple d’avoir proposé des M1 et M2 pour donner une dernière chance à ce repository… mais rien ne va. Vite, il faut débrancher et tout migrer. 6 mois après le démarrage de ce projet, 85% des équipes ont terminé.
Je vous vois là, dans le fond de la classe… Il y a toujours quelques équipes qui « découvrent » qu’il faut migrer, qui n’ont pas de développeurs frontend (pas de bras, pas de chocolat) et sinon, qui en ont globalement pas grand chose à faire…
Chez Doctolib, j’ai piloté le programme de migration pour passer de NewRelic à Datadog APM. 49 équipes. Des gens qui adorent NewRelic (comme moi) et qui ne veulent pas passer sur Datadog. On a travaillé avec une TPM (coucou Jessica), des SRE (coucou Kévin et Ali), et ce projet s’est réalisé. J’ai déjà vu le film sur des projets de migration « musclés ». Je sais que les 20% restant seront les plus compliqués à migrer.
C’est super facile de « démarrer » une migration vers Vue3. C’est bien plus compliqué de terminer et de faire en sorte que tout le monde soit passé de l’autre côté.
Mais là, mon ami, va falloir être créatif.
11 façons de migrer du code, la 7ème va vous étonner…
Je m’invite dans une équipe qui développe les outils du support (pour les clients Back Market). Je tente un peu d’insuffler de l’énergie, mais je sens bien que ça pousse pas très fort. Une de mes frustrations c’est de ne pas maitriser Vue3 (et Nuxt3). Je me rend compte qu’il sera difficile d’aider et de comprendre sans ce passage initiatique. Je décide de me former sur Vue3.
Me voilà fin juillet à prendre un des tickets de migration, sans trop que l’EM comprenne ce qui va se passer (coucou Léo !). Je code, je discute avec d’autres développeurs, je bidouille, je tente aussi d’utiliser Claude.AI pour faire une migration « automatique » (… qui ne marche pas), je passe pas mal de temps et finalement j’arrive à une PR correcte en août, avec une trentaine de fichiers modifiés, des tests en veux-tu, en voilà, et un truc tout à fait honnête.
Début septembre, le temps de fixer quelques problèmes de type, de polish le code, je réussis à terminer la pull-request principale. Comme je suis un gars sportif, je fais exprès d’aller chercher une revue du code par Enguerran, qui est l’un des gars qui sait le mieux faire des revues de code techniques, et qui est capable d’expliquer le pourquoi du comment. Une fois le code mergé, il reste encore des tâches à faire.
La Product Manager n’a pas le temps de préparer le plan de la QA ? Je lui fais tout le plan avec tous les tests. Il faut tester un cas particulier avec le marché Japonais ? Je fais le test avec un collègue à Tokyo un matin, et je prends une vidéo pour valider. Le développeur n’a pas le temps ? Je vais voir le manager pour libérer du temps, et faire en sorte qu’il ait du temps… etc.
Je continue à aider les équipes qui doivent migrer avant la fin novembre. J’ai préparé une décision d’architecture en juillet, validée par tous, dans lequel en substance « on congèle Pastrami au moment de Black Friday (29 nov 2024) et on ne le décongèle jamais…« . L’objectif étant de passer le repository en lecture seule. Entre mai et septembre j’ai des petites victoires. On passe de 4 millions de requêtes par jour à 300 000 req/jour. Mais je vois bien que cela stagne depuis début septembre…
J’entame une visite des 7 équipes concernées, pour comprendre pourquoi cela n’avance pas.
« Alors nous, on n’a pas de développeur frontends…«
Je récupère un Freelance (coucou Pascal) et je recrute un deuxième freelance (coucou Bakary) pour créer une équipe dédiée uniquement à la migration. On démarre sur des migrations 1-1 sans changer un pixel, mais en essayant d’améliorer la qualité et les tests lors de la migration.
J’ai eu ensuite un Manager qui visiblement, s’est dit qu’il fallait escalader pour gagner du temps :
- « … mais si on veut repousser la migration, à qui on doit demander ? »
- » à moi »
- « …. et pas à la CTO ? »
- « non c’est moi qui me charge de ce programme »
Same player, shoot again.
Ce travail de migration est plutôt un programme technique, qui aurait été géré parfaitement je pense par un Technical Program Manager. Il faut cependant l’impact d’un Principal Engineer (ou d’un Senior Staff aussi) pour que cela avance, et se termine. A mon avis, le combo des deux aurait été efficace ici.
Bref, cher lecteur, c’est non sans émotion que je t’annonce que j’ai validé mon badge de « Problem Solver« . On vise la fin du programme pour janvier 2025.
Bon la photo est belle, mais c’est un badge que j’avais eu chez Doctolib…. hé hé hé !
Les prochains mois ?
En septembre, en plus de ce que vous venez de lire, j’ai pris le rôle d’Engineering Manager par intérim, dans l’équipe « Search&Reco ». Celle-ci n’avait plus de manager et je me suis proposé, pour comprendre le fonctionnement des EM chez Back Market. Après avoir fait du backend au départ, puis du frontend cet été, je prends maintenant le rôle d’EM. C’est temporaire et une de mes premières actions a été de relancer le recrutement pour ce poste. Littéralement. Et j’ai bon espoir qu’une personne prenne le poste en novembre, dans nos équipes de Barcelone.
[Update] Nous avons recruté Anna qui démarre en janvier chez Back Market.
Pour conclure
Je n’ai pas raconté tout ce que j’ai fait depuis mon arrivée. J’ai participé à la renégociation sur le contrat Datadog, et j’ai lancé un programme « Greedy Dog » pour optimiser les coûts. Avec Théotime, Sami et Guillaume nous avons aussi créé Staff42, un meetup francophone pour les Staff Engineers. Il y a déjà plus de 200 personnes sur notre Slack. Nous organisons aussi des événements sur Paris, Bordeaux et Lyon. Côté conférence, Back Market sera sponsor et exposant à BDX.io le 8 novembre. Pour information, le siège de l’entreprise est à Bordeaux et il y a environ 30 développeurs (+8 remotes) sur le site de Bordeaux, à coté du musée du vin. Paris c’est 80 développeurs (+87 remotes) et enfin 25 personnes à Barcelone (+6 remotes) (note: merci Dimitri pour les chiffres)
Ce que je vois pour les mois prochains : tout d’abord ce sera le premier Black Friday pour Back Market avec Google Cloud Computing, avec 200 services au lieu d’un monolithe, et avec un frontend moderne basé sur Vue3/Nuxt3. En ce moment, nous travaillons pour préparer et s’assurer que cette période d’activité (qui va de novembre à début janvier) se passe bien pour la plate-forme.
Derriere cela, je retrouve un sujet sur lequel j’avais bossé chez Doctolib, avec le projet « Robinson mapping« . Je prendrai le temps de vous raconter cela dans un autre article. Ca parlera de DDD, de domain, de produit, et d’architecture logicielle…
Stay tuned !
3 likes
Leave a Comment