Un an en tant que développeur chez Microsoft
Introduction
En septembre 2020 j’ai publié un article à propos de mon expérience en tant que Program Manager plutôt bien reçu par la communauté. Cela m’a permis de réaliser que la communauté était curieuse et intéressée par le rôle. Dans cet article, je vais partager mon expérience en tant que développeur.
Avant de se plonger dans le sujet, gardez à l’esprit que cet article reflète uniquement mon expérience personnelle, cette expérience peut être radicalement différente d’une équipe à l’autre, d’un produit à l’autre et dépend d’autres circonstances (travail à distance, culture, etc…).
Qu’est-ce qu’un développeur logiciel?
Voici ma définition personnelle : quelqu’un qui est responsable de l’architecture, de l’écriture du code et des tests ainsi que du support de solutions digitales à des problèmes du monde réel.
Bien sûr, cela peut prendre de multiples formes, spécialement dans de larges entreprises comme Microsoft.
Sur quoi tu travailles?
SDK Java
Ma première assignation fut le SDK Java du Microsoft Graph. Je n’avais pas écrit de Java pendant plus de 12 ans, depuis SUPINFO en fait, et j’étais un peu rouillé. Vous trouverez les détails de mon expérience dans l’article : refonte du SDK Java du Microsoft Graph.
Projet Kiota
Je me suis maintenant recentré sur un nouveau projet que Darrel a démarré : nous sommes en train de bâtir un nouveau générateur de SDK chainé (fluent SDK) pour OpenAPI. Ce nouveau générateur supporte divers langages et permet à n’importe qui travaillant avec une API possédant une description OpenAPI de générer leur propre SDK chainé. Si vous voulez en savoir plus, vous pouvez regarder cette vidéo de démonstration.
Conseil des API
Le Conseil est une équipe d’architectes et de développeurs définissant les bonnes pratiques et lignes directrices pour Microsoft Graph. J’ai l’occasion d’apprendre énormément de choses sur les standards de l’industrie et de monter en compétences sur l’architecture d’API. En retour, j’essaie de retourner la faveur en prenant en charge une partie de ce qui est « simple » comme la rédaction de spécifications à partir des notes de réunion.
Revue de code
Que les pull/merge requests soient créées par des bots (dependabot, générateur…), des membres de l’équipe, ou bien par des membres de la communauté, les revues de code représentent une étape importante pour l’assurance qualité.
Vous devriez faire en sorte que la revue de code, via des pull requests, deviennent une habitude dans votre équipe car cela permet à tout le monde d’apprendre les uns des autres.
Croissance de l’équipe
Depuis que j’ai joint cette équipe, plus de 20 personnes s’y sont ajoutées. Cette croissance n’est pas limitée à mon équipe et notre organisation a beaucoup grandi durant la dernière année. Jeremy est en train de bâtir une équipe d’expérience partenaires (CPX), nous avons aussi une toute nouvelle équipe de program managers gérée par Kristen.
Cette croissance est gratifiante car cela conduit à beaucoup de recherche de solutions et d’opportunités d’apprentissage pour tout le monde.
Courriels? Réunions?
Il se passe régulièrement des journées sans que je ne reçoive aucun courriel, et j’ai environ 5h de réunion par semaine. 😊
Culture
Notre organisation est éparpillée dans le monde entier, avec des regroupements à Nairobi et Redmond. Cette situation nous force à communiquer de manière asynchrone, ce qui me convient personnellement. Le travail asynchrone, lorsque correctement implémenté, se traduit par une meilleure productivité et permet aux membres de l’équipe de vivre au rythme qui leur convient.
Durant cette dernière année j’ai énormément appris : non seulement j’ai pu dépoussiérer mes compétences en Java et apprendre en profondeur http/OData/OpenAPI/… sur le plan technique, mais j’ai aussi pu m’initier aux notions de diversité et d’inclusion grâce à des formations internes.
Conclusion
J’espère que cet article a apporté des réponses à certaines des questions que vous pouviez vous poser sur qu’est-ce qu’être un développeur chez Microsoft. Je suis certain que cette réalité est différente pour les développeurs travaillant sur un service et peut être que je l’explorerai plus tard dans ma carrière. A la prochaine!