002. Les communautés à distance
Vous n'êtes pas seul !À la table, Michel Martens, Sylvain Abélard, Sonia Prévost et Franzé Jr.
Télécharger l'épisode (16 Mo) - Date de publication : 2017-02-07
- • Elixir Sips
- Learn Elixir like a Pro
- • Women on Rails
Vous n'êtes pas seul !
Sylvain : La première actu qu’on s’est noté, c’est les Elixir Sips.
Franzé : En fait, Elixir Sips, c’est un screencast très bien pour ceux qui aiment bien Elixir et qui voudraient commencer à apprendre. Une nouveauté, c’est que ça va être rebooté et tous les épisodes seront dans DailyDrip.
Sylvain : La deuxième actualité, on n’a pas vraiment la date mais incessamment sous peu, il y aura la reprise du cycle d’apprentissage de Women on Rails.
Sonia : Alors, Women on Rails, c’est une communauté de filles qui développent sur Ruby et particulièrement sur Rails. Et, toute l’année dernière, on a lancé un cycle de formation pour donner envie aux filles qui souhaitent apprendre à coder en Ruby on Rails. Et normalement, je pense, dans quelques mois, on va relancer le cycle.
Sylvain : On va rappeler aussi que Women on Rails, c’est tous les lundis soirs et c’est gratuit. Donc, c’est une formation, ce n’est pas professionnel, c’est pas diplomant. C’est que du bénévole, l’ambiance est très sympa.
Sonia : Et c’est surtout entre filles, avec des supers mentors. Et le but, c’est de partager et d’échanger. De pas rester bloquée.
Sylvain : Et alors aujourd’hui, il y a combien de cycles qui ont été fait et le cycle dure combien semaines d’affilée ? Et est-ce que c’est important d’être là à toutes les séances ou est-ce qu’on peut venir qu’à la moitié ?
Sonia : Alors, pour l’instant, on a fait deux cycles de sept semaines. C’est très dense. Donc, on recommande quand même aux filles de venir toutes les semaines. Mais, après, on a eu des cas où finalement les filles ne sont pas venues et elles ont pu, comme on a fait plein de tutos sur Github, quand même suivre à distance. Sans forcément être présentes.
Sylvain : On va se lancer sur notre sujet de l’épisode 2 : les communautés en remote. Donc, à distance, en télé-travail, en télé-présence, comme vous voulez. C’est vrai qu’on utilise un peu trop souvent les mots anglais donc on va souvent dire “remote”. Et donc, je vais demander à chacun dans quelle communauté il est et notemment des communautés remote.
Franzé : Je suis de Fortaleza, une ville au Brésil au bord de la mer. Et comme je suis ici, j’ai plusieurs amis dans le monde entier. Ici, la communauté Ruby n’est pas très grande et du coup, j’ai senti la nécessité de créer un truc pour m’aider à faire des meetups et aussi à participer à des meetups. Donc, j’ai trouvé un bon nom, je pense : Remote Meetup. L’idée, c’est juste d’aider les gens à créer des meetups et aussi créer une communauté pour les gens qui voudraient commencer un meetup. Ou juste parler de technos. Et avec ça, on a déjà aujourd’hui 1600 subscribers dans notre channel. On a aussi des sponsors qui nous aident, comme BigMarker. Donc, on a à peu près 1600 personnes qui ont déjà participé et qui sont un peu actives. On a aussi un Slack sur lequel on essaie de parler mais ce sont surtout des meetups pour aider les gens. Comme ParisRB.
Sylvain : Moi, je peux en parler d’expérience. Je co-organise ParisRB. Et depuis que Franzé nous a lancé avec son partenariat Remote Meetup, tous les meetups sont filmés, sont streamés en live. Et donc, on sait qu’on a des gens qui nous regardent, nos meetups de Paris depuis le Canada, depuis la Belgique, depuis je ne sais pas trop où on a eu. Et pas mal de gens. Et BigMarker, c’est un outil qui est vraiment pas mal, qui tourne dans Chrome. Vous avez la vidéo, le micro, un chat et c’est pas mal fait. Si vous n’oubliez pas de cliquer sur le bouton “Enregistrer” et “Exporter la vidéo sur Youtube” comme moi, vous pouvez le faire et garder votre meetup après. Ce sera dispo sur Internet et c’est vraiment très cool. J’en profite aussi pour dire les podcasts Le Ruby Nouveau, on utilise Zencastr, qui est une application dans Chrome qui nous permet d’avoir plein d’invités, de télécharger les pistes audio et de faire du post-processing avec. C’est vraiment très sympa. Ce sont deux beaux outils et je pense que c’est utile pour les communautés remote. Franzé, tu as quelles technos en Remote Meetup à part Ruby ?
Franzé : On essaie de faire des “branchs”. Il y aussi un Elixir ou un autre pour Elm. Et un autre sur JavaScript. On essaie d’avoir quelques managers sur chaque “branch”.
Sylvain : On peut passer la parole à Sonia pour nous parler de Women on Rails un peu plus en détails. Pas encore remote, mais peut-être bientôt.
Sonia : Women on Rails est né du désir de continuer à se retrouver après un Rails Girls.
Sylvain : C’est quoi Rails Girls ?
Sonia : C’est un samedi où des filles et des mentors se retrouvent pour apprendre à coder en Ruby on Rails et avoir une première approche du code. À l’issue de ce Rails Girls (moi je n’y étais pas, mais il y avait Lisa, Agathe, Sylvain et plein d’autres), est né ce désir de continuer à se retrouver pour continuer à progresser. Parce que les Rails Girls, c’est deux fois par an. C’est un peu court quand on veut vraiment apprendre à coder. Du coup, elles se sont retrouvées toutes les semaines pendant un moment et l’année dernière, ça s’est un peu plus construit. Sauf qu’on se rend compte, en fait, que venir un lundi toutes les semaines, ça peut être assez contraignant pour certaines participantes. Notamment, moi qui ne peut plus physiquement assister aux meetups, je pense que le remote, c’est quelque chose vers lequel on aimerait bien aller. C’est cool d’avoir toutes ces idées, tous ces outils pour pouvoir nous, de notre côté, mettre en place la communauté remote de Women on Rails. Et d’avoir plus de participantes. Pas forcément physiques. Tous les lundis de 19h à 21h. Sinon, nous, on utilise beaucoup Slack. C’est quelque chose qui continuera être utile pour la communauté remote. Comme du Hangout ou des choses comme ça.
Sylvain : Est-ce que Michel, tu veux nous parler d’éventuelles communautés ? Michel, qui vient d’Argentine, fait plutôt dans le monde entier mais en voyageant physiquement la plupart du temps.
Michel : J’habite ici en France. J’ai beaucoup d’amis en Argentine, en Uruguay. Je travaille en remote, ça fait très très longtemps. Depuis 1999. J’utilise IRC. C’est comme Slack, mais pour les vieux :) Ca fonctionne très bien, pour mon boulot, mais aussi pour les toutes petites communautés autour des logiciels, des outils.
Sylvain : Tu travailles en remote plutôt tout seul ou plutôt avec des clients pour des projets ? C’est ton produit ?
Michel : En ce moment, et depuis 2011, c’est mon produit. Je travaille avec deux personnes en remote. L’une est à Portland aux États-Unis, l’autre est aux Philippines. Notre comptable est à Gibraltar, on ne se voit jamais :) On utilise IRC et les emails.
Sylvain : Depuis 2011, c’est ton produit. Et de 1999 à 2011, tu faisais comment ?
Michel : En 1999, je travaillais en Argentine et j’ai rencontré ma femme. Elle faisait ses études à Montpellier. J’ai déménagé avec elle. J’ai gardé mon boulot et j’ai commencé à travailler en remote. Et là, c’était juste les emails à l’époque. Après en 2008, j’ai commencé à travailler pour une compagnie à Los Angeles et là, c’était IRC.
Sylvain : De 1998 à 2008, c’est ta compagnie en Argentine qui t’a donné la chance de travailler en remote. Tu étais le premier ou ils avaient l’habitude ?
Michel : J’étais le premier. À l’époque, j’ai du baisser mon salaire de moitié pour avoir le droit de partir. Ça s’est fini en 2001 où j’ai re-augmenté mon revenu.
Sylvain : En ce moment sur le Slack de ParisRB, on a eu pas mal de gens qui posaient ce genre de questions. C’est difficile de trouver du travail quand on est remote. C’est difficile de trouver du travail quand on est junior. Ou des clients quand on veut être freelance. Et en remote, et en junior. Tout est possible, tout est négociation mais parfois il y a une contrainte qui saute. Donc, effectivement, quand on cumule junior et remote, c’est le salaire qui baisse. Et à l’inverse, si on est senior, on peut se payer le luxe.
Michel : Au moins, on peut essayer. Parce qu’en entreprise, rien n’empêche d’essayer pendant deux mois. Dans mon cas, c’était ça ou rien. C’était soi ça ou je quittais mon boulot. Donc, ils voulaient essayer. Moi aussi. Et ça a marché.
Sylvain : Est-ce que depuis, ta boîte en Argentine, ils ont l’habitude de travailler avec plus de gens en remote ?
Michel : Je ne sais pas. À l’époque, j’étais le seul.
Sylvain : Et donc Franzé, tu es freelance remote. Tu as pas mal de clients à Paris, en France. Est-ce que c’est l’intégralité ou la plupart de tes clients ? Ou tu en as d’autres ailleurs ?
Franzé : Je travaille pour une entreprise. J’ai un contrat avec cette entreprise. Là, je travaille full-time. Au niveau légal, je suis un freelance. Au niveau de l’entreprise, je suis comme embauché, un peu comme un employé. Ça fait plus d’un an que je suis comme ça. C’est bien, j’aime bien. C’est un peu difficile de trouver ça en France. Mais, comme vous dites, ça dépend beaucoup de la personne et de l’entreprise aussi.
Sylvain : C’est une opportunité à trouver à chaque fois. Et avant, tu travaillais en remote aussi ou que depuis un an ?
Franzé : Avant, j’ai travaillé pendant six mois pour une entreprise ici au Brésil. Puis, je me suis dit non. Je voudrais travailler en remote parce que j’aime bien ça. Je trouve ça bien. Même s’il y a des inconvénients comme chaque travail. Je trouve ça pas mal de faire ce que j’aime bien.
Sylvain : On a parlé un peu des raisons. On a Guirec (je l’inviterai dans un autre podcast) qui est dans une zone très isolée du Québec qui vit les mêmes problèmes que vous. C’est-à-dire qu’il est éloigné d’un peu toutes les grandes villes. Donc, il est éloigné des meetups aussi. Et forcément des entreprises ou des clients. Du coup, c’est un sujet qui intéresse un peu tout le monde. De se dire qu’on a une contrainte géographique, on veut vivre à tel ou tel endroit. Ou on déteste les transports, ça arrive aussi. Et donc, on a toutes ces idées. Un, le télé-travail. Deux, les communautés. Parce que c’est bien d’avoir une ou plusieurs communautés en dehors de son travail. Et ça peut aussi marcher en remote. Alors, du coup, ce qui m’intéresserait de savoir, c’est : gérer une communauté en remote, ça prend combien de temps ? c’est compliqué ? Qu’est-ce qui embête les gens ? Qu’est-ce qui fait qu’ils viennent ? Qu’ils partent ? Et quels outils on peut mettre en place ? Apparement, tout le monde a des Slacks ou des IRCs en ce moment. Que ce soit au travail ou en communauté. Est-ce que vous avez des conseils et des outils pour principalement des communautés plutôt que pour du télé-travail ? Des soucis que vous avez constaté, des astuces que vous pourriez donner ? Qu’est-ce qui marche, qu’est-ce qui ne marche pas pour des communautés en remote ?
Michel : Je crois que c’est important de trouver les faiblesses d’une communauté en remote et ses points forts. Par exemple, toi (Sylvain), tu participes à la communauté Rails. C’est asynchrone. Quand on essaie de reproduire ce qu’on a en live, c’est là que l’on trouve des problèmes. Il faut profiter de pouvoir communiquer par email. De ne pas être dans le même temps au même endroit.
Sylvain : Pour le context, je co-organise ParisRB. On est 2500 membres et quelques. On se retrouve à 100-120 membres tous les mois. C’est vrai qu’effectivement, si vous n’être pas là, si vous êtes en vacances ou si vous avez une obligation familiale, vous allez rater le meetup et c’est fini. Ceux qui ont une contrainte : “Les transports, je peux pas. Mais à part ça, je pourrai regarder si c’était en vidéo ou en streaming. C’est là où le Remote Meetup de Franzé nous aide. Ces gens-là peuvent même participer. Par exemple, en nous posant des questions sur Slack ou sur le BigMarker. On essaie d’y penser et de le lire. De poser les questions aux speakers. C’est intéressant, c’est interactif. Et puis, par contre, si vous avez vraiment raté le meetup de telle date, vous pouvez quinze jours ou même un an après, aller voir sur Youtube les présentations.
Franzé : La première chose que je peux dire, c’est que faire des vidéos, c’est très bien pour regarder après. Une autre chose : on a toujours des gens qui ne peuvent pas venir. Le pourcentage des participants, ce n’est pas beaucoup. Ça, c’est un problème dans toutes les communautés. Je ne sais pas si ça arrive souvent à ParisRB.
Sylvain : Par pourcentage des participants, tu veux dire les gens qui s’inscrivent et qui ne viennent pas ? Toi, tu as quel genre de pourcentage en gros ?
Franzé : Normalement, 40%.
Sylvain : Sur presque tous les meetups que je connais. Que ce soient des meetups technos ou des meetups business, dans Paris, souvent les absents, c’est quelque chose comme 20% à 40%. Presque tout le monde est à 30%. ParisRB, on a beaucoup de chance. On s’est beaucoup battu. On a une communauté très sympathique, les gens rigolent plus chez nous que dans d’autres meetups. Donc, on est plutôt à 20% d’absents. Voilà, c’est la partie arrogante, elle est finie. On s’est beaucoup battu contre ça et puis, on a compris qu’on n’était pas les seuls et qu’on ne pourrait rien faire. On a tenté de faire un système par contre. On a des lieux avec des capacités maximum, pour la sécurité. La chance avec Remote Meetup, c’est que vous n’avez pas ça. Vous pouvez faire des meetups à mille personnes, nous pas trop. C’est dommage de se dire que la salle, elle n’a que 100 places. Il y a 100 inscrits, il y en a 50 sur liste d’attente. Et en fait, il y en 30 qui ne sont pas venus parce qu’ils ne sont pas pris alors qu’en fait, ils auraient pu avoir une place. Et donc, du coup, on a mis une page qui raconte que : si vous réservez une place et qu’en fait, vous ne venez pas, moi je vais le noter. Le mois d’après, je vais vous mettre en liste d’attente. Juste pour vous “punir” en gros. La bonne nouvelle, c’est qu’on n’a jamais eu besoin de menacer comme ça. Rien que de faire peur avec la page, ca suffit. Encore une fois, j’ai beaucoup de chance. Je ne sais pas si tout le monde, ça marcherait. On s’est sérieusement demandé s’il fallait faire payer le meetup. “Si vous venez pas, c’est 5 euros” ou “Tout le monde donne un euro symbolique. Et si vous venez, on vous le rend. Si vous venez pas, on le garde”. Après, ça, c’est des problèmes physiques. Pas un problème du Remote Meetup
Sonia : Chez Women on Rails, on a mis à peu près le même principe. Et les filles libèrent vraiment leur place. On part du même principe. Si vous ne pouvez pas venir, c’est pas grave. Au moins, prévenez et permettez aux gens qui sont en attente de pouvoir venir. En ligne, c’est un peu plus compliqué. Moi, j’ai une question pour Franzé. Tu dis que tu as 40% qui ne viennent pas le jour même où tu peux regarder le meetup en ligne. Mais, tu as plein de gens qui le regardent après. Peut-être que tu récupères les 40% qui n’ont pas pu être là au jour J, à l’heure H.
Franzé : Probablement, mais je n’ai pas de chiffres pour dire ça. On doit probablement regagner les 40% après. Je ne sais pas vraiment.
Sonia : C’est l’intérêt d’une communauté en remote. Chez Women on Rails, c’est un peu différent. Le but, c’est de dire, je peux l’avoir en ligne, mais je peux l’avoir plus tard aussi après. C’est ça qui est chouette dans le fait que ce soit une communauté en remote.
Sylvain : C’est pareil, vous non plus, vous n’avez pas de métrique pour voir les personnes qui sont venues sur le Github de Women on Rails. Et moi, sur ParisRB, je ne l’ai pas non plus sur les vidéos. Dans nos têtes à tous, en tout cas sur ParisRB, c’est un service qui a un coût parce qu’il faut prendre la vidéo, il faut faire attention. On va réessayer de faire du vrai montage. Ce qui a de la valeur. Parce qu’il y a des gens qui peuvent s’en servir après. Et c’est vrai que si on voulait mettre aux sponsors, parce que les meetups vivent aussi des sponsors, surtout en physique quand t’as besoin de payer un buffet. Mais, en remote, tu as les outils à payer et puis, potentiellement, moi, ça ne me choquerait pas qu’un organisateur soit payé. Ce n’est pas mon cas. Qu’il soit payé pour améliorer son meetup, faire les transcriptions textes éventuellement. Ça peut être super cool. C’est vrai que si on était dans une phase où, par exemple, un meetup remote a vraiment besoin de trouver des sponsors, parce que c’est ça ou la communauté, elle meurt, ça vaudrait le coup de mettre des métriques sur la vision des vidéos, l’écoute des trucs. Et dire aux gens “Bah oui, mon meetup, y’avait 100 inscrits et 70 présents, mais les vidéos, elles ont été vues 3000 fois quoi.”
Sonia : Alors que bon, en physique, tu n’as pas forcément ce souci de statistiques, vu que tu les as en face de toi. Donc, tu sais le taux de remplissage.
Sonia : Nous, chez Women on Rails, c’est un peu différent des communautés en ligne avec vidéos vu que c’est du mentoring. Ça veut dire comment tu crées la relation un mentor et une apprenante en ligne. Comment tu fais aussi. Le souci récurrent, c’est que, on a forcément moins de mentors que d’apprenantes. Et une des questions qu’on a (et peut-être que vous avez la réponse), c’est si jamais on fait en ligne, comment on peut faire en sorte que plusieurs filles, plusieurs apprenantes aient un seul mentor ? Au lieu d’avoir un one-to-one. C’est une question que je pose comme ça.
Sylvain : Tu veux dire que le mentor derrière son Slack ou son téléphone, il partage son temps sur plusieurs apprenantes ou tu veux qu’une seule débutante sur 8 semaines d’affilée, elle a toujours le même mentor, comme ça, ils connaissent mieux et tout le monde est au courant du progrès chacun ?
Sonia : Je ne sais pas. C’est vraiment une question vaste de savoir comment on peut faire. Un des soucis auquel on est confronté aussi, c’est que souvent, on n’a pas vraiment de lien entre les apprenantes. Comme on est vraiment sur le partage, comment on peut créer ça en ligne ? Même si on est dans des lieux physiques différents, créer des liens avec les apprenantes et aussi avec le mentor. Je pense que ce sont des choses qui sont liées. Avoir des groupes d’apprenantes avec un mentor qui suive ce groupe-là sur plusieurs semaines.
Sylvain : J’ai plutôt envie que Michel et Franzé parlent, pas des meetups, mais plutôt du travail. En entreprise, je suis sûr que vous êtes obligés d’expliquer aux collègues, même s’ils aussi forts que vous. L’historique, pourquoi est la boîte, quand il y a une nouvelle recrue qui arrive. Vous avez peut-être eu à recruter des gens plus jeunes, moins expérimentés. Du coup, comment ça se passe ? Qu’est-ce qui marche bien ? Qu’est-ce qui est bon signe ? Qu’est-ce qui est mauvais signe quand vous mentorez quelqu’un à distance pour le travail, mais peut-être pour la communauté aussi ?
Franzé : Pour moi, je pense que la meilleure façon d’aider et de partager, c’est de faire du pair programming, pair coding. Je fais ça souvent quand j’ai un problème et que je ne trouve pas de solution. Ou même si je veux juste expliquer ce qui se passe dans mon code, dans mon appli. Je pense que c’est du pair programming, la solution. Par exemple, j’utilise Screenhero. On peut faire du pair programming avec deux ou trois personnes. Je trouve ça pas mal. On peut vraiment partager l’écran. Il y aura trois ou quatre souris sur l’écran, donc tout le monde peut dire ce qu’il veut, mais aussi taper. Pour faire du mentoring et partager la connaissance, surtout si c’est quelqu’un de senior et un junior. Je pense que c’est la meilleure façon d’apprendre. Et partager aussi les règles de l’entreprise, les standards de l’entreprise.
Michel : Je suis d’accord avec toi. Même si je n’aime pas le pair programming comme technique à appliquer toujours. Pour ça, on a toujours un serveur où on peut se mettre pour partager avec Screen. Screen, c’est l’outil en terminal pour multiplexer les commandes. On ouvre un éditeur de texte et on commence à partager des idées, faire ce que tu viens de décrire avec Screenhero. On le fait avec un serveur, mais c’est la même idée. À mon avis, je suis d’accord avec toi, c’est la meilleure façon de faire.
Sylvain : Du coup, y’en a pas mal aussi, quand, par exemple, au travail, soit ils veulent, soit ils n’ont pas le temps de faire du pair programming, parfois, ils se contentent de faire le mentoring, le partage des pratiques de l’entreprise lors de la code review. C’est quelque chose que vous faites encore plus ?
Michel : En ce moment, je n’en fais pas trop.
Sylvain : Vos code reviews, vous les faites plutôt, apparement plutôt pour Franzé, en synchrone et peut-être pour toi plutôt en asynchrone ?
Michel : En fait, c’est ça. Ce que je faisais beaucoup, c’est de parler avant de l’idée. Pas de code, de l’idée. En général, de design. Je crois qu’après ça, le la code review est plus facile parce qu’on est déjà d’accord sur ce qu’on veut.
Sylvain : J’aime beaucoup ce conseil. Je suis en région parisienne. La plupart de mes clients et de mes équipes sont en région parisienne. Mais, je ne suis pas toujours avec eux. Y’en a une, je suis avec deux jours par semaine. Y’en a une autre, je suis avec une après-midi par semaine par exemple. C’est pas du remote parce qu’on est ensemble physiquement. Mais, c’est du remote parce que finalement, on fait pas mal de choses en asynchrone. On échange des mails de temps en temps. On a des Slack ou des coups de fil parfois. C’est un peu le même genre de chose et c’est vrai que j’aime beaucoup cette attitude. Finalement, quand on a bien expliqué avant “le client, il veut vraiment ça”. Moi, éventuellement, si je suis entre guillemets plus “fort” que la personne, je vais aller voir le junior ou le mid, moi je vois que la conception, je veux que tu la fasses comme ça. Ce n’est jamais un ordre direct, même avec quelqu’un qui est aussi fort ou plus fort que moi, ca va être “Moi, je pense que le client, il veut ça”. Déjà, est-ce qu’on a bien compris ? Rien qu’en parlant entre deux développeurs, on voit que peut-être on n’a pas bien compris et qu’il faut revenir vers le client. Ensuite, on dit entre nous on va l’architecturer comme ça : - “Est-ce que tu es d’accord ? Est-ce que tu vois des problèmes ?” - “Ah oui, j’ai pensé à ça.” Il faut anticiper et souvent dès cette étape-là, on va revenir vers le client avec un petit mail en lui disant “Au fait, on va faire comme t’as demandé, mais je te rappelle que à tel endroit il y aura un piège, il faudra pas oublier de configurer, il faut qu’on fasse ça avant telle date”. Et puis, ça, c’est en remote si le client n’est pas avec nous. Effectivement, du coup, je laisse les gens coder. Quand le code est committé, il ne surprend personne parce qu’on savait déjà à quoi il ressemblerait. Et peut-être à ce moment-là, on fait une review ou on s’en passe en fonction du temps ou du niveau de la personne. Ce conseil-là qui a l’air d’être pour les remotes est complètement génial et je le fais tous les jours dès que possible dans des équipes qui ne sont pas remote. Ça, c’est cool pour livrer un logiciel, mais c’est vrai que ça ne va pas trop t’aider Sonia pour Women on Rails.
Sonia : Si, si, ça donne des idées. Rien que le Screenhero donne des idées. Et je pense aussi que rajouter du code review, c’est-à-dire en asynchrone, le code est produit et le mentor regarde après, je pense que ça peut être pas mal d’aller sur ça. Comme ça, ça permet au mentor de pas toujours forcément d’être présent derrière. La seule contrainte, nous, c’est de se dire, on est un groupe qui se réunit le lundi soir et que si on fait que en remote, il ne faut pas que ça prenne toute la semaine au mentor. Parce qu’à ce moment-là, ça devient une activité rémunérée. Et ce n’est pas le but. C’est comment en deux heures de temps, on arrive à mettre en place ces petits exercices. Je pense que j’arrive à avoir deux ou trois idées qui sont plutôt pas mal là grâce à vous.
Michel : Une autre chose qu’on fait, c’est, par défaut, on ne doit rien changer dans le code, dans les équipes, dans les projets. Et si il y a une personne qui participe et qu’on n’est pas d’accord, on ne change rien. Et ça marche, ça fonctionne. C’est un peu bizarre. Parce que si on fait un compromis et qu’on change, on n’est pas tout à fait content. À la fin, ça donne un mauvais code.
Sylvain : Mine de rien, ça, c’est quelque chose qui se fait aussi hors de la technique. On fait une réunion avec plusieurs personnes chez le client ou la MOA comme on aime bien l’appeler en France. Et peut-être des techniques, mais pas toujours. C’est vrai que si, moi je suis invité comme pour apporter la crédibilité technique ou l’information technique à une réunion où je vois des gens du métier qui ne sont pas d’accord entre-eux, c’est sûr que par défaut, moi je vais dire “On fait rien tant que vous n’êtes pas d’accord”. Faut livrer, faut que ça marche. L’idée, ça va être de créer un consensus, de dire “Est-ce que le compromis, tout le monde va finir par être d’accord dessus ?”. On va livrer une partie tout de suite, une partie plus tard. Du coup, c’est ce que je comprends, c’est ce que vous faites sur le code. Tant que tout le monde n’est pas d’accord.
Michel : Exactement, il faut que tout le monde soit content avec ce que l’on fait. Sinon, on commence à perdre le rapport avec le code. Ça commence à ne plus être ton projet à toi.
Sylvain : Si je me souviens bien, Michel, dans tes produits notamment, tu as des choses autour de Redis, qui sont utilisés par des milliers de gens sur la planète. Donc, effectivement, si toi, tu t’amuses à faire plein de petits changements bizarres. Ce n’est pas deux ou trois co-workers ou collègues qui ne vont pas être contents, ça va être 1500 clients qui peuvent te hurler dessus. C’est peut-être ça qui t’oblige à faire cette méthode.
Michel : Oui, c’est ça. Mais, c’est aussi d’avoir la sensation que c’est ton code à toi. Que tu n’as pas mis des choses que tu n’aimes pas.
Sylvain : C’est pour un peu garder le ownership, la responsabilité et la motivation des gens.
Michel : Tu travailles avec quelqu’un et si on fait un compromis, personne n’est complètement content.
Sylvain : Ca veut dire que si, je travaille avec Sonia, j’ai envoyé du code, il n’est pas terrible. Sonia, elle change mon code et elle le renvoie. Moi, je ne suis pas content parce que ce n’est pas très correct et parce que ce n’est plus mon code. Et parce que je travaille mal. Et donc, l’idée, c’est que si on travaille en remote avec Sonia, c’est qu’elle vienne me dire “Écoute, j’ai vu ton code et moi je l’aurais fait comme ça.”. Et finalement, tous les deux, d’abord on arrive à se mettre d’accord et après, on envoie le code.
Sonia : Ou alors on reste pas d’accord. Et c’est ta version qui l’emporte puisque c’est toi qui a fait le code.
Sylvain : Non, parce que si tu n’es pas d’accord, mon code, il ne passe pas.
Michel : Exactement.
Sylvain : Et c’est normal. Imaginons, tu n’es pas d’accord parce que, dans mon code, il y a une faille de sécurité ou de performance. Ou alors, par exemple, toi tu sais - tu es la chef d’équipe - tu sais que le produit bientôt, il va un peu changer et tu sais que ma modification, elle te casse la baraque. Elle va tripler ton travail par exemple.
Michel : Si tu sais que tu vas pas être contente et que tu ne peux pas l’expliquer, ça suffit. À mon avis.
Sylvain : C’est un peu extrême mais c’est intéressant. Il faudrait qu’on pratique.
Sonia : Promis, Sylvain, je ne reprendrai pas ton code.
Sylvain : Non, non, au contraire. Moi, j’ai la chance de travailler avec des gens. C’est une tradition qui date depuis l’école en fait. Quand j’avais des groupes de projets, on se dit tout et on n’hésite pas. On s’est toujours dit, pour les sentiments, pour la cohésion d’équipe, de toute façon, on est dans la même boîte, on est dans le même projet. Par défaut, je dis même pas qu’on est copain, par défaut, je dis qu’on s’entend bien. Par défaut, on se respecte. Voilà, ça c’est donné. Ça, c’est la base. Mais, par contre, parce qu’on se respecte entre autres, faut qu’on se dise tout. Si on n’est pas content, on le dit. C’est vrai que moi, avec la plupart de mes équipes, je suis plutôt en mode “Si vous avez une critique à me faire, si c’est peut-être pas le bon jour, ou peut-être c’est pas la bonne manière, je préfère que vous la fassiez quand même. Et je vous pardonnerai plus tard même si ce n’est pas sur le moment.”. Donc oui, tu as le droit de changer mon code. Et au contraire, si tu penses qu’il faut le changer, je préfère que tu me le dises.
Sonia : Oui, oui, bien sûr. Mais c’est rare quand même.
Sylvain : Du coup, on a déjà fait 40 minutes d’épisode. Avant d’arriver aux picks, je vais peut-être aller sur un dernier sujet. Je me suis un peu perdu par le complément sur le consensus de Michel. En fait, dans Women on Rails, on parle effectivement de communauté physique, d’entraide et de débutantes. On parle de ce cyle d’apprentissage. On parle aussi de femmes qui ont terminés ce cycle-là. Elles ne cherchent plus de passer du niveau… En fait, on va dire, elles arrivent au niveau 0 à Rails Girls, elles arrivent au niveau 1 à Women on Rails et puis elles sortent de Women on Rails, elles en sont au niveau 5. Et après, avec la suite des sessions, des ateliers libres ou en remote mentoring, elles veulent passer du niveau 5 au niveau 20. Mais, peut-être que c’est simplement deux audiences différentes. Et quand tu parles de faire un mentoring en remote, par exemple, le mentor, il va voir le code de l’apprenante le lendemain. Moi, je pense, en tout cas, je le vois avec Rails Girls et avec des nouveaux embauchés dans les entreprises, que quand la personne est très très débutante, le cycle de retour doit être très rapide. Je ne vais pas les laisser se perdre 20 minutes et se casser la tête 20 minutes sur le même sujet. C’est très désagréable pour eux, ça gaspille du temps pour moi. Et donc, j’ai l’impression que plus les gens sont débutants et plus il faut que le mentor soit présent en synchrone. Et plus les gens sont autonomes, et c’est exactement le principe, plus les gens grandissent et apprennent. Peut-être qu’ils ne seront pas meilleurs techniquement, mais ils auront la maturité de se dire “Puisque je bloque 20 minutes sur le premier problème, je vais plutôt attaquer le deuxième problème. Là, j’arrêterai d’être énervé tout seul dans mon coin”. Avant que l’on enregistre l’épisode, tu nous disais que peut-être Women on Rails avait peut-être cette histoire de ciblage à faire et de savoir si vous allez, entre guillemets, vous séparer en deux, vous séparer en trois parce que vous avez de fait deux audiences, trois audiences de niveaux différents.
Sonia : Surtout, en fait, on s’aperçoit avec le cycle que ça intéresse beaucoup de femmes qui - ça, je l’avais vu aussi quand j’ai fait le Wagon - c’est-à-dire qu’on va vers le code parce que c’est intriguant et que souvent on travaille avec des équipes techniques. Et qu’il faut comprendre ces équipes techniques. Et j’ai l’impression que le cycle de formation répond beaucoup à ça. Les apprenantes qui viennent au cycle, consomment le cycle et ne reviennent pas forcément après. Parce que c’est compliqué ensuite de se mettre dans un processus de projet ou de continuer l’apprentissage parce qu’au moins, avec le cycle, elles ont compris comment cela fonctionnait.
Sylvain : En fait, tu dis que lorsqu’elles sont arrivées au niveau 20, elles n’ont plus besoin de passer au niveau 100.
Sonia : Une fois qu’elles ont passé un niveau, comme c’est pas forcément leur travail et qu’elles sont dans des équipes techniques et qu’elles ont juste besoin, parfois, juste besoin de mettre des mots sur “Qu’est-ce que c’est le code ?”, elles ne vont pas forcément revenir. On va avoir des filles qui reviennent aux ateliers libres. Et ça va plutôt être des gens comme Marine qui ont un projet et qui vont continuer à venir pour travailler. Et à ce moment-là, la présence du mentor est très bénéfique. C’est un peu le partage de communauté qu’il faut qu’on arrive à avoir. Et il faut aussi qu’on puisse le faire pour nous. Moi, Women on Rails, j’y suis allée pour un projet perso. Je suis passée très vite mentor parce qu’on avait pas mal d’apprenantes qui venaient pour ça et beaucoup moins pour moi. Donc, c’est aussi, comment en tant que mentor, on arrive à trouver un équilibre entre nos projets perso et les moments de mentorat.
Sylvain : C’est moins remote. Mais c’est vrai que c’est un sujet.
Sonia : De communauté.
Sylvain : L’avantage du remote, si tu le fais en asynchrone ou autre, c’est que tu peux donner ton temps et arrêter de donner ton temps, c’est plus facile. Mais, c’est vrai qu’effectivement, moi je n’ai pas trop de pitch là-dessus. Les mentors qui prennent le temps, gratuitement en plus, pour mentorer, ils savent pourquoi ils viennent. Et en général, ils essaient une fois ou deux, sans comprendre, parce que ça les intéresse. Finalement, une fois qu’ils l’ont fait une fois ou deux, c’est très riche pour eux et ils sont content d’être venus. Ils sont contents d’avoir mis des étoiles dans les yeux de quelqu’un. Ils sont très contents d’avoir aidé quelqu’un. Et puis, ils se rendent compte au fur et à mesure que, en fait, moi, j’ai appris beaucoup. J’ai révisé mes bases, c’est une bonne chose. J’apprends à être professeur et dans ma boîte, on va bientôt embaucher un junior donc c’est une très bonne chose. Les gens à qui je propose de devenir mentor chez Rails Girls, je leur dis ça et tout simplement, s’ils ont le temps ou s’ils n’ont pas le temps, c’est eux qui me disent oui ou non. Ça s’arrête là. Le reste, avec ta discipline à toi et tes disponibilités à toi pour te partager ton temps entre mentorer les autres et aller chercher du mentoring auprès d’autres gens. Ou d’avancer toute seule ton projet. Mais, c’est vrai que là-dessus, je n’ai pas trop de conseil.
Sonia : On va voir comment va se passer 2017. On a plein de choses dans les bacs. Je pense que ça va être une année très intéressante pour Women on Rails, pour gérer un peu tout ça.
Découvertes des invités
- • Franzé Jr
- Livre sur les optimisations de Rails – Rails Performance
- • Sonia Prévost
- Plate-forme d'apprentissage en ligne – Udemy
- • Michel Martens
- Seymour Papert (inventeur de LOGO) - pour l'apprentissage, la pratique, l'innovation... – Mindstorms
- • Sylvain Abélard
- Énigmes "Zen" sur le code, pour se poser des questions plutôt qu'y répondre – The Codeless Code