đȘđïž 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 đ