🍪🎙️ Formé au Wagon en 2014 et aujourd’hui lead dev d’Hosman : ITW de Thibault (+ expérimentation de la lecture bionique)
Parmi les premiers élèves du Wagon (batch #5 !), Thibault dirige aujourd'hui l'équipe technique de Hosman. Il nous éclaire sur deux sujets que nous croisons souvent :
Comment progresser quand on est un développeur junior ?
Comment être un bon lead dév ? Savoir bien coder c'est une chose, bien diriger son équipe en est une autre.
Exceptionnellement aujourd'hui nous avions envie d'expérimenter la lecture bionique avec vous. Pour ceux à qui ça ne parle pas, la lecture bionique ou bionic reading consiste tout simplement à mettre en gras le début de chaque mot. Bien sûr, on ne s'amuse pas à faire ça juste pour le fun ; cette méthode, conçue par le designer typographique suisse Renato Casutt, permet de rendre la lecture plus agréable, plus efficace, plus rapide et plus optimisée. Ce serait non seulement un moyen de lire sans être distrait, mais aussi d’aider les personnes ayant des difficultés à lire et à comprendre des textes. En toute transparence je suis moi-même concernée par ce sujet du fait de ma dyslexie. Un sondage vous attend à la fin de l'interview, pour que vous puissiez nous dire si, oui ou non, vous avez apprécié cette méthode. Également, n'hésitez pas à laisser un commentaire si vous souhaitez partager votre retour d'expérience.
Au programme :
Interview de Thibault Hazard
Le job de tes rêves !
Temps de lecture : 9 min
Hello les petits Biscuits !
Bienvenue sur la 12ème édition de Ruby Biscuit.
Vous êtes maintenant 223 abonnés 🥳 Si vous n’êtes pas déjà inscrit :
Comment es-tu devenu développeur ?
Tout d'abord, je n'étais pas destiné à être développeur. Avant de faire le Wagon en 2014, (j'étais la promo n°5, quand on sait qu'il y en a plus que 1000 aujourd'hui...), je n'avais jamais touché au code, si ce n'est la préparation qu'ils vous demandent de faire dans les semaines qui précèdent la formation.
J'ai fait une prépa et une école de commerce (Neoma à Reims), puis j'ai fait de l'audit au Luxembourg puis de la finance à Paris. Mon travail ne me plaisait pas ; le management était très mauvais ; j'ai donc cherché à m'extirper de cette situation. C'est là qu'un ami m'a parlé du Wagon qui venait de se créer.
J'ai adoré la formation du Wagon. C'était dans les locaux de The Family au début, et j'avais eu en professeurs les cofondateurs, Boris Paillard et Sébastien Saunier.
Ensuite j'ai bossé tout seul 3 mois, mais je me suis rendu compte que mon niveau était trop faible pour que je développe un bon produit ou que je sois un bon freelance. Je manquais de pratique.
Alors comment as-tu progressé ?
J'ai été assez pragmatique. J'aimais développer, mais je n'étais pas encore un atout immédiat pour l'entreprise qui allait m'embaucher. J'ai donc rejoint Capsens, qui était encore une toute petite agence, contre une toute petite rémunération. Notre accord était que si je progressais ils me paieraient en conséquence, et c'est ce qui s'est fait assez rapidement.
Chez Capsens, j'ai passé les premiers mois à travailler à côté d'un dév bien meilleur que moi, qui m'a beaucoup aidé. On ne faisait pas du pair programming en continu mais ça arrivait, et d'autres fois il me montrait la voie quand c'était nécessaire. Ça a vraiment été la clé de mon évolution initiale. Et bien sûr, il faut beaucoup de travail et d'investissement.
Quels conseils donnerais-tu à des juniors ou à des entreprises qui ont des développeurs juniors pour qu'ils progressent ?
C'est un sujet qui m'intéresse, parce qu'en plus d'être passé par là, on a deux développeurs juniors chez Hosman actuellement, et j'en ai formé quelques-uns.
Il faut de l'humilité, se dire qu'il y a beaucoup à apprendre et ne pas chercher à développer trop vite, mais à bien développer. C'est ce que je demande à mes juniors : prendre le temps de bien faire plutôt que d'essayer de coder selon un planning. La vitesse d'exécution viendra avec l'expérience et l'intégration des bonnes pratiques.
Il faut chercher par soi-même les solutions, mais pour pas que ce soit trop frustrant, il faut un sénior qui peut aider. Notamment en montrant des exemples de code, sur un autre projet par exemple.
Lire des articles est super pratique, car d'autres ont souvent déjà rencontré nos problèmes.
Je déconseille aux entreprise de faire coder deux juniors ensemble ou de laisser un junior tout seul. Pour certains ils ne progresseraient pas et prendraient de mauvaises habitudes.
Enfin au début, il ne faut pas hésiter à toucher à plusieurs choses (back, front, technos), trouver ses centres d'intérêt et ne pas hésiter à dire "c'est ça qui m'intéresse" au sein de l'entreprise où l'on travaille.
Maintenant tu es lead dev chez Hosman, en quoi ça consiste ?
J'ai rejoint Hosman il y a 5 ans quand ils n'étaient que 15, maintenant on est 5 fois plus. Au début j'étais le seul dév avec un des cofondateurs qui a codé seul la première version d'hosman.co à la suite du Wagon. Puis, j'ai recruté mon équipe et les ai fait monter en compétences entre autres par des ateliers tous les mois. La taille de l'équipe a un peu varié. Actuellement nous sommes cinq, deux séniors, deux juniors et moi.
Je code peu aujourd'hui, je relis les PR, j'interviens en cas de bug critique, je travaille sur les sujets d'admin sys (on est principalement sur Heroku et on réfléchit à passer chez Google Cloud Platform, notamment pour la relation client qui est meilleure et pour leurs outils d'analyse de données) et je fais le lien entre l'équipe technique et la direction. J'ai un petit bout d'app sur lequel je code encore. Ça me fait du bien, car ça me manque un peu de coder.
C'est très cool de recruter son équipe et la former. Au départ, je faisais un tuto par mois aux dévs, en montrant du code à partir des PR qui sont passées ou de problématiques qu'on a eues.
Ce semestre notre équipe s'est adaptée. Étant donné le ralentissement du marché de l'immobilier, on a réorienté notre roadmap pour aider les équipes marketing et commerciales et repensé notre interface client pour continuer d'améliorer leur expérience. Alors que ces dernières années on a surtout automatisé le métier d'agent immobilier en ligne : publier une annonce en un clic, s'interfacer à des API, ...
Comment est organisée ton équipe ?
Déjà, nous sommes chacun dans une ville différente : Bruxelles, Nantes, Marseille, Lyon, et le Perche. C'est assez particulier, mais on est bien organisés comme ça. Chaque matin, on se retrouve pour un stand-up de 15 min. On explique ce qu'on fait et les obstacles rencontrés. Si deux personnes ont besoin de plus de temps, elles font un point plus long ensemble dans la foulée du stand-up.
Actuellement, je valide toutes les PR de back, et pour celles de front c'est le senior en front qui s'en occupe. Mais tout le monde est tagué sur chaque PR, car j'incite chacun à donner son avis dessus (même les juniors) ; ou simplement à lire du code qui n'est pas le sien. C'est comme pour devenir un grand auteur : il faut lire pour bien écrire.
Comment gardes-tu tes développeurs motivés au quotidien ?
L'élément principal est de leur permettre de travailler sur les sujets qui les intéressent en faisant correspondre cela aux besoins de l'entreprise, bien sûr. Quand quelqu'un travaille sur un sujet qu'il aime, il est tout de suite plus motivé, plus curieux et productif. Ainsi, notre sénior en front s'y est mis progressivement par attrait, et aujourd'hui c'est ce qu'il fait le plus. De même, on essaie de se répartir sur les aspects de l'app que l'on préfère.
Aussi, je joue le rôle d'avocat et de protecteur vis-à-vis du reste de l'entreprise. Même si tout le monde est plein de bonnes intentions, il faut respecter certains principes avec les développeurs (avec mon équipe en tous cas). Par exemple, ne pas déranger les dévs pour des questions non urgentes. Ainsi, le reste de l'équipe pose ses questions aux développeurs en les écrivant sur Trello, et nous prenons du temps pour y répondre au début de chaque journée ou après le déjeuner, afin de ne pas être coupés dans notre travail. Ce sont, d'ailleurs, les moments où l'on relit les PR.
Quelles sont tes deux gems préférées ?
VCR
Description : VCR permet d'enregistrer le résultat d'un test API et de rejouer une requête externe très simplement.
Pourquoi ? La gem est très simple d'utilisation. C'est hyper pratique, car ça fait gagner beaucoup temps quand on fait tourner les tests et ça évite de mocker quelque chose de mal simulé. C'est, d'ailleurs, Nicolas Besnard (déjà interviewé dans une précédente édition de Ruby Biscuit) qui m'a appris à correctement faire mes tests, notamment avec cette gem.
L'avis de Capsens : Paradoxalement chez Capsens nous avons récemment fait le choix de doucement retirer VCR de nos plateformes. Nous avons longtemps utilisé cette gem, mais aujourd'hui nous la trouvons trop difficile à maintenir, car nos requêtes, notamment celles vers les API des prestataires de paiement, sont souvent améliorées. Nous privilégions donc les mocks et les stubs simple avec un découpage stratégique des services.
Prawn
Description : Créateur de PDF en Ruby
Pourquoi ? À la différence d'autres solutions (pdf-forms, wicked_pdf) elle n'implique pas de dépendances. Donc elle est simple. Après notre besoin en génération de PDF est assez simple. Donc ça nous suffit.
L'avis de Capsens : Comment ne pas sauter sur l'occasion pour dire que nous avons développé Doclift.io, une API très facile à utiliser pour générer des PDF (factures, contrats, ...) et surtout pour les éditer en ligne sans toucher au code très pratique pour les PM. La solution est très utilisée, n'hésitez pas à vous y brancher 😉.
Le job de tes rêves !
Comme vous le savez, derrière Ruby Biscuit, il y a Capsens 👋 , nous sommes une agence web spécialisée dans le Ruby on Rails depuis 10 ans.
Avec le temps on s'est rendu compte que beaucoup de dévs choisissent leur entreprise un peu par hasard alors qu'ils pourraient mieux s'épanouir et se valoriser dans des structures qui leur correspondent bien.
Ce qui tombe super bien c'est que chez Capsens nous avons une excellente connaissance de l'écosystème Ruby on Rails en France, avec un réseau d'entreprises considérable.
C'est pourquoi on vous annonce à travers cette newsletter que nous mettons à profit notre connaissance du métier pour vous aider à trouver le poste de vos rêves !
Concrètement :
Tu souhaites trouver le job de tes rêves ? Alors réponds à cet e-mail ! Tu peux dire "Coucou", ça suffit !
On te proposera aussitôt des créneaux pour une visio afin de faire connaissance
Puis nous te proposerons 3 entreprises qui correspondent à qui tu es. Et pour chacun de ces postes :
Tu pourras discuter avec un développeur de l'équipe (pas le recruteur lui-même) afin de savoir comment ça se passe de l'intérieur. No bullshit
Un développeur de Capsens t'aidera à :
Analyser le poste : ce qui a l'air bien, les dangers, quelles conditions poser pour que tout se passe bien
Te préparer pour que tu décroches le bon poste
Tu veux aller vers une vie professionnelle plus épanouie ? 😀 Eh bien, on attend ton e-mail ! Et si tu aimes déjà ton travail, ne nous contacte surtout pas ! Ou alors fais-le pour nous recommander ta boite 😉
Si vous êtes arrivé jusqu'ici, deux options s'offrent à vous :
Soit vous n'êtes pas encore abonné, remédiez-y !
Soit vous l'êtes déjà, dans ce cas je compte sur vous pour partager cette édition !
Bonnes vacances, RDV en septembre
Mélanie, Nicolas et les nombreux relecteurs 🙂