Techlead Conférence : comment évoluer en IT?
Le 9 et 10 mars 2023 s’est tenue la TechLead Conférence. Un événement entièrement en ligne axé sur le développement des carrières professionnelles en IT, les conseils pour devenir Tech Lead et gagner en maturité dans le monde de la Tech. La Techlead Conférence a rassemblé 19 orateurs : ingénieurs, managers et responsables des ressources humaines travaillant dans des entreprises reconnues de notre domaine. Ils offrent ainsi différents points de vue sur la gestion de projets techniques. J’ai choisi de revenir dans cet article sur les deux conférences qui m’ont le plus enthousiasmé, à savoir le Dev Rel de Zan Markan et le Pair Programming d’Octave Rimbault.
Focus sur la conférence sur le »Dev Rel » de Zan Markan (UK)
Conférence d’ouverture sur un rôle en pleine expansion dans les entreprises : le DevRel. Le « Developer Relations » est un rôle, porté par une ou plusieurs personnes au sein d’un projet. Il consiste à créer une communauté autour des développeurs d’une entreprise, permettant de combler les lacunes de communication et d’assurer une coordination optimale des projets. Il y a un rapprochement bénéfique entre l’informatique et les métiers. Le rôle des développeurs s’étend et devient de plus en plus complexe. Le développeur doit aujourd’hui être en lien et collaborer avec toutes les parties prenantes du projet et être intégrer dans le processus décisionnel. Cela créé un cadre de confiance pour le développement professionnel des développeurs. Bien qu’il existe différents noms pour les administrateurs de la communauté, tels que « Developer Advocate », « Developer Evangelist », etc., le but derrière reste le même.
Retour sur les conférences de la Techlead Conférence sur le « Pair Programming » d’Octave Rimbault (FR) et Mo Khazali (UK)
Qu’est-ce que le Pair Programming?
Ensuite, j’ai eu le plaisir de découvrir Octave Rimbault, un ancien Peaksien pour une analyse du « Pair Programming », technique de développement de logiciels en binôme. Souvent sujet à débat car jugée couteuse par les directions, elle est néanmoins plébiscitée par les développeurs. Pour commencer, Octave a abordé les avantages de cette pratique :
- Un code plus robuste. En effet, le fait d’avoir une autre personne avec soi permet de combler les éventuels oublis que l’on pourrait avoir
- Une amélioration des compétences de l’équipe
- Un meilleur moral
- Un gain de productivité
Suivi des inconvénients :
- Il y a un coût de développement (+15 % selon une étude réalisée par Alistair Cockburn et Laurie Williams dans les années 2000). Cependant, ce coût sera très probablement rattrapé dans le futur, que ce soit lors de la revue, des tests, des bugs (un regard extérieur aide à remonter les anomalies potentielles) et surtout dans la maintenance du code (connue par les deux protagonistes).
- Incompatibilités entre les développeurs (méthodes de travail trop différentes…)
Quand et comment utiliser le Pair programming ?
La suite de son discours portait sur quand et comment utiliser le « Pair Programming ». Par exemple, c’est une méthode qui s’applique mieux lorsqu’on travaille sur des tâches complexes, lorsqu’on veut partager des connaissances ou même lors de l’intégration d’un nouveau membre dans l’équipe.
Pour se faire, il est essentiel de se mettre dans les bonnes conditions. Tout d’abord, il est important de trouver le bon partenaire qui possède des compétences complémentaires aux vôtres et avec qui vous pouvez facilement communiquer. Ensuite, il faut choisir le bon outil pour travailler ensemble. Que ce soit via un éditeur de texte partagé, un appel vidéo ou tout simplement en travaillant sur le même ordinateur.
Il est également recommandé de penser à inverser régulièrement les rôles entre le conducteur et l’observateur. Cela permet de maintenir un haut niveau d’implication des deux parties et d’éviter la lassitude. Enfin, il est important de se donner des objectifs clairs et de travailler ensemble pour les atteindre.
Octave n’est pas le seul à avoir abordé ce sujet. Mo Khazali (UK) nous a présenté sa méthode pour effectuer les tests techniques dans son entreprise en utilisant le « Pair Programming ».
Tests techniques avec le Pair Programming
Selon lui, les entretiens techniques traditionnels qui passent souvent par des plateformes (comme Coding Game, LeetCode, …) ne permettent pas un échange réel avec le candidat. Pour y remédier, il propose la mise en place d’un environnement de test tel que celui-ci :
- Créer un projet dans lequel le candidat peut ajouter de nouvelles fonctionnalités, résoudre les bugs, ajouter des tests,…
- Donner les objectifs à atteindre pendant l’entretien sur ce projet (qui peuvent varier selon le niveau technique attendu)
- Inverser les rôles d’observateur et de conducteur à plusieurs reprises pour créer un échange réel
- Une fois les objectifs atteints, échanger avec le candidat pour savoir s’il pense à des améliorations possibles du code
- Obtenir des retours sur la session qui vient de se dérouler afin de s’améliorer potentiellement lors d’un prochain entretien
Cette méthode présente de nombreux avantages, même si elle nécessite un important travail préparatoire. Principalement, elle met le candidat dans de bonnes conditions, de le rassurer et de l’accompagner dans sa réflexion, obstruée parfois par le stress que représente un entretien. De plus, elle permet de découvrir la personnalité du candidat, là où des tests techniques à travers les plateformes ne le permettent pas. Alternative intéressante aux méthodes traditionnelles, elle permet aux recruteurs de mieux évaluer les compétences et la personnalité des candidats.
Pour conclure, la Techlead Conférence a réellement permis aux participants de découvrir des pratiques novatrices que je n’ai pas pu toutes malheureusement explorer dans cet article. Nous avons pu échanger des idées sur les meilleures façons d’améliorer la productivité et la qualité dans le domaine du développement informatique. J’ai hâte de découvrir la prochaine édition et je recommande aux leads développeurs d’y participer.
Plus d’information à découvrir sur :
la Conférence
le rôle de Dev rel
