Mentor prolifique et automate de systèmes

Jonathan : Salut tout le monde et bienvenue dans le podcast de la communauté Exercism. J'ai le privilège d'être accompagné d'Isaac, qui est l'un de nos mainteneurs et contributeurs et qui a récemment fait beaucoup de mentorat auprès de nombreux apprenants sur nos GoHorts, nos cohortes d'apprentissage, que nous avons organisées pendant 30 jours, deux fois maintenant je crois, en particulier en Go et en Elixir. Et Isaac a aidé sur la piste Go, ce qui était génial. Donc Isaac, un immense bienvenue à toi. Est-ce que tu peux juste me raconter un peu où tu es installé, d'où tu viens et comment tu es arrivé dans la tech ? Isaac : Oui, je suis installé en Californie. Je vis à San Jose, en Californie. La vérité, c'est que je suis arrivé dans la tech parce que mon grand frère était dans la tech et que je faisais tout ce qu'il faisait. J'avais plein de frères et sœurs. On aimait traîner ensemble, ou certains d'entre nous aimaient plus traîner avec certains qu'avec d'autres. J'avais un grand frère avec qui j'adorais traîner. Lui n'aimait pas forcément traîner avec moi autant, mais je passais mon temps à le suivre et à vouloir faire tout ce qu'il faisait. Il a récupéré un livre « C for Dummies » qui traînait à la maison quand il avait environ 15 ans, et moi j'avais 9 ans si je me souviens bien. Donc il écrivait du C, et je me suis dit, s'il fait ça, je vais le faire aussi. Mes programmes étaient assez simples et basiques à cet âge. C'était plutôt du genre, tu sais, quel est ton nom, bonjour Bob. Ce n'était pas très complexe. Il faut bien commencer quelque part. Il faut commencer là. Je me disais, oh, tu peux afficher un caractère et ça fait un son. C'est trop cool. J'ai écrit un programme qui littéralement affiche juste un slash A. Mais je commençais à 9 ans. J'écrivais des programmes en C. On avait une vieille machine sous Windows 3.1 qui démarrait sous DOS, et mon frère avait mis en place un script batch pour qu'au démarrage de l'ordinateur s'affiche un menu où tu pouvais choisir de lancer Windows, de lancer des jeux, il y avait genre un menu de jeux. Tu pouvais taper 5 pour Warcraft ou peu importe. Donc j'écrivais des scripts batch au fur et à mesure qu'on installait d'autres jeux et tout le reste. Et à partir de là, tout s'est enchaîné. Mon frère est allé à l'université étudier l'ingénierie informatique, et là encore je me suis dit que s'il faisait ça, j'allais le faire aussi. Donc j'ai commencé à écrire du C à 9 ans. J'écrivais... du Visual Basic 6 au lycée. J'avais un Palm Pilot sur lequel j'écrivais divers programmes au lycée. Mon prof de maths était vraiment cool. J'étais dans un de ces vieux... Jonathan : C'était un peu le genre de truc, tu te souviens, ils ont essayé de sortir le truc d'avant l'iPad, et genre, quelques personnes en ont eu un et il y avait ce petit machin où on griffonnait au stylet. Et tout le monde trouvait ça hyper cool parce que ça sortait à l'époque, et c'était genre zoup, et après tu pouvais tapoter dessus. C'était un peu, ça n'a pas... je m'en souviens toujours parce qu'après l'iPad est arrivé et tout le monde s'est dit, ah, un peu tôt. Le Pilot était juste un peu, un peu en avance sur son temps, tu vois ce que je veux dire ? Isaac : C'était génial pendant une décennie environ, mais ouais, il y avait le Graffiti de Palm pour saisir le texte. Il y avait un petit pavé de saisie, et tu devais écrire des caractères, mais ils étaient en quelque sorte basés sur l'alphabet. Par exemple, le A, c'était juste un triangle, et le F, c'était un angle droit. Ouais, mon prof de maths au lycée m'a dit, hé, si tu as écrit le programme, tu peux très bien l'utiliser pendant le contrôle. Donc j'écrivais des programmes sur Palm Pilot au lycée, ce qui était vraiment cool. Je suis allé à l'université en ingénierie informatique. Les gens parlaient de langages de script. Je ne savais pas trop ce que c'était, alors j'ai pris Perl un peu au hasard. Et puis j'ai fini mes études supérieures, je suis parti et j'ai été embauché par Google. En 2013, ils m'ont fait déménager de la côte Est vers la Californie. Et c'est là que j'ai découvert Python il y a une dizaine d'années. Et Python est mon langage principal depuis dix ans. Je travaillais chez Google, donc mon style est très influencé par le style Google. Et c'est pour ça que j'ai surtout écrit comme ça. Et puis il y a environ... quatre ans, je dirais 2018 ou par là, Google a commencé à pousser le langage Go en interne et c'est là que j'ai appris Go. Jonathan : Cool. Et Isaac, quand tu parles du style Google, est-ce qu'il y avait une idée bien établie que c'était la bonne façon de faire, ou est-ce que c'était plutôt... comment, développe un peu là-dessus parce que c'est intéressant. Isaac : Le style de code n'est pas forcément la bonne façon de faire, c'est plutôt une façon uniforme que tout le monde doit adopter. On dit qu'un bon compromis, ou un bon accord, c'est un accord dont personne n'est satisfait. Personne n'est vraiment satisfait du guide de style, mais tant que tout le monde le suit, le code est uniforme. Ça veut dire que n'importe qui peut prendre n'importe quel morceau de code dans la base de code Google et le modifier, et tant que tout le monde suit les mêmes consignes de style, le code reste uniforme, on n'a pas à se dire, ah, cette base de code utilise des indentations de quatre espaces et celle-ci de deux, ou bien celle-là a telle ou telle convention de nommage. Tout, dans toute la base de code, est fait de la même manière. Personne n'est satisfait de tout. Chacun a ses domaines où il aimerait que ce soit fait autrement, mais comme il existe un guide de style documenté, disponible publiquement, on peut juste chercher le guide de style Python de Google et il te dit voilà comment on écrit du code chez Google. Tant que tout le monde s'y tient, le code est très uniforme, ce qui est vraiment agréable : on peut ouvrir n'importe quelle base de code et il n'y a pas de surprises du genre, ah, ils écriraient ça autrement. Jonathan : C'est pour ça que Go s'intègre peut-être assez bien dans ce contexte ? Parce qu'il est formaté et que c'est vraiment, voilà comment ça se passe. On voit clairement l'influence de Google là-dedans. Isaac : Ouais, je ne sais pas dans quelle mesure Rob Pike a été influencé par l'approche de Google, ou dans quelle mesure c'est lui qui a influencé l'approche de Google. Je ne sais pas trop lequel a mené à l'autre, mais Go pousse clairement ça à un autre niveau, où... il y a encore plus, genre avec Python, il y a différents styles et les gens bricolent leurs linters pour accepter des choses différentes. Par exemple, en interne, Google utilise des indentations de deux espaces en Python parce qu'il y a beaucoup de code profondément imbriqué et qu'ils ne veulent pas d'un énorme mur d'espaces. À l'extérieur, la plupart des gens utilisent quatre espaces, et c'est en quelque sorte écrit dans la documentation de Python. Mais ouais, pour Go, ils ont juste poussé ça à un autre niveau et ils se sont dit, le langage lui-même intègre le formatage. Il n'y a qu'une seule façon de formater. Il n'y a pas de débats en ligne sur la bonne façon. Il n'y a qu'une seule façon. Jonathan : Ça évite un paquet d'allers-retours. Disons les choses comme ça, peut-être. Ouais. Donc c'est bien. Isaac : Ouais. Jonathan : Alors, d'accord, donc quand tu as commencé chez Google, tu n'avais jamais fait de Python, ou tu avais un peu bricolé, ou c'était un passage facile ? Genre comment, parce que tu as donné l'impression que tu avais obtenu le poste chez Google et qu'ensuite c'était, ok cool, apprends Python, c'est parti. Isaac : C'est exact. Je crois que je n'avais jamais écrit de Python avant de rejoindre Google. J'écrivais du Perl depuis un an ou deux. Je suppose que ça faisait quelques années, à ce moment-là, que j'avais commencé le Perl. Mon premier job d'été. C'est une toute autre histoire. J'avais commencé le Perl six ans avant de rejoindre Google, donc j'écrivais pas mal de Perl à ce moment-là. J'écrivais aussi un peu de Bash, donc les langages de script m'étaient familiers. Mais je n'avais jamais écrit de Python. Mais une fois qu'on a bricolé avec assez de langages... La courbe d'apprentissage est un peu moins raide pour en apprendre un autre, parce qu'on a déjà vu la plupart des constructions et ce n'est qu'une syntaxe légèrement différente, une boîte à outils légèrement différente. Mais c'est beaucoup la même chose, juste un peu différent, écrit autrement. Les constructions ont tendance à être assez similaires. Donc une fois qu'on a appris quatre langages, en apprendre un cinquième, c'est genre, ah, c'est juste écrit un peu différemment. Jonathan : Ouais, ouais. C'est intéressant. Donc tu as un peu rigolé à propos de ton premier job, genre en sortant du lycée. Donc, est-ce que tu as toujours été du genre, je vais faire de l'ingénierie, je vais faire de l'informatique ? Est-ce que ça a toujours été une pensée consciente, ou est-ce que c'était plutôt, c'est juste là que je me sens à ma place naturellement, j'aime ça et c'est tout ? Genre, comment ça s'est... Isaac : Je suppose. J'essayais vraiment de suivre les traces de mon frère. Il est allé en ingénierie informatique. Il a commencé à programmer. Il a commencé à programmer quand j'étais gamin. J'ai suivi. Je programmais depuis que j'étais jeune. Il est allé en ingénierie informatique et c'était, tu sais, je voulais faire la même chose que lui et en plus je m'éclatais à programmer et tout ça. Donc, depuis mon entrée au lycée, alors que mon frère était déjà à l'université, je savais que c'était là que je voulais finir. Jonathan : Donc il a quelques années de plus que toi, et on dirait qu'il a eu une influence énorme sur toi en tant que personne. Combien d'autres frères et sœurs as-tu ? Ou est-ce qu'il était un peu ton idole à tes yeux ? Isaac : J'ai huit frères et sœurs, mais c'était clairement celui avec qui je m'entendais vraiment bien. Il fait partie de ceux, je suppose, avec qui je m'entends mieux qu'avec d'autres. Quand on en a huit, il y a forcément de tout. Je m'entendais très bien avec lui. On a tendance à beaucoup penser de la même façon. On a tendance à avoir des intérêts similaires. On s'éclatait à parler d'ordinateurs tout le temps. Encore aujourd'hui. Sa femme n'aime pas quand ça devient le sujet de conversation à table. Elle dit, pas de boulot à table. On parle de programmation avec passion tout le temps, on en discute sans arrêt. C'est vraiment difficile à dire, quelle part relevait du simple désir de le copier et quelle part venait du fait qu'on avait juste des intérêts similaires. On a clairement des intérêts similaires aujourd'hui. Je ne sais pas quelle part relève de l'inné et quelle part de l'acquis. Je ne peux pas vraiment dire quelle part vient du fait que je le copiais et quelle part vient du fait qu'on avait juste des intérêts similaires. Mais comme je suivais ses traces depuis tout petit, je suivais et lui traçait le chemin dans une certaine mesure, et je le suivais. Jonathan : Ouais, c'est vraiment cool. Et lui, il est où maintenant ? Juste par curiosité, il est sur la côte Est ? Isaac : Il est toujours sur la côte Est, il travaille dans la tech. On a travaillé brièvement dans la même entreprise. Jonathan : Ouais, ok, cool. Donc voilà pour ça. C'est cool. J'étais juste curieux de demander. Bon, une des choses qui... donc tu as été vraiment impliqué dans la cohorte que nous venons de terminer. Donc la dernière cohorte d'apprentissage, surtout avec Go, on a organisé un truc de 30 jours avec Go, et ensuite ton implication dans Exercism auparavant portait plutôt spécifiquement sur la maintenance, mais aussi pas mal de mentorat d'après ce que je comprends. Donc comment as-tu vécu cette répartition ? Genre, je veux dire, comment as-tu découvert Exercism et quels sont les différents aspects dans lesquels tu aimes contribuer ? Isaac : Donc j'ai découvert Exercism à l'origine parce que j'essayais de me remettre à Haskell. J'ai suivi un cours Haskell 101 chez Google qui était assez sympa. Et puis je me suis dit, oh, je devrais passer plus de temps là-dessus. Et puis j'ai laissé tomber. Et ensuite j'ai essayé de m'y remettre. Jonathan : et on se voit la prochaine fois. Isaac : Avec n'importe quel langage, je trouve que la façon la plus simple de l'apprendre, c'est de l'écrire pour de vrai. La façon la plus simple de l'écrire, c'est d'avoir une raison de l'écrire. Je n'ai pas trouvé de bonne raison d'écrire du Haskell, ce qui rendait l'apprentissage vraiment difficile. Mais j'ai découvert Exercism et je me suis dit, oh, ça pourrait m'aider à écrire plus de Haskell. C'est comme ça que j'ai découvert Exercism à l'origine. Une fois là-bas, je me suis dit, oh, il y a une piste Python et une piste Shelf et genre des exercices psychoride là-dedans, alors je suis parti dans le terrier du lapin. Jonathan : Et tu es tombé dans le terrier du lapin. Isaac : Ouais. J'ai commencé à résoudre des exercices en Python. J'ai commencé à résoudre des exercices en Bash. J'ai fait quelques exercices de Go. Quand le GoHort est arrivé et que je regardais certaines de mes anciennes solutions, j'ai vu que beaucoup avaient été soumises trois ans plus tôt. Donc je me suis, je m'étais inscrit pour la première fois à la piste Go en 2019 et j'avais résolu une bonne partie de ces exercices à l'époque. Et puis je fais du Python depuis dix ans maintenant. Donc je me sentais relativement à l'aise pour rejoindre les mentors Python, et c'est là que je passe la plupart de mon temps sur les exercices ces jours-ci. Et puis j'ai commencé à soumettre des PR, des pull requests sur la piste Python parce qu'il y avait des choses qui n'étaient pas à leur place. Et puis j'ai commencé à m'impliquer dans la piste Bash. Et je ne sais pas trop comment c'est arrivé, mais je suis passé de soumettre des correctifs à la piste Bash à devenir mainteneur de Bash. Jonathan : Comme ça, d'un coup. Je veux dire, c'est un peu, attention à ce pour quoi tu t'inscris, hein ? Isaac : Ouais, et puis Glenn a écrit la piste Ock et je me suis dit, oh, je connais Ock, j'aime Ock, je vais monter dans ce train. Donc j'ai aidé à construire les exercices de la piste Ock. Je ne suis pas tout à fait sûr, mais je crois que quand j'ai vu les exercices Go il y a trois ans, j'ai terminé toute la piste et ensuite un des mentors m'a dit, oh, tu as fini tous les exercices, tu devrais peut-être devenir mentor. Je ne suis pas assez à l'aise, je n'écris pas Go assez souvent, assez régulièrement pour me sentir à l'aise pour mentorer dessus. Donc je n'étais pas vraiment mentor Go. Mais quand j'ai rejoint le GoHort et qu'il y avait un paquet de gens qui voulaient du mentorat, je me suis dit, oh, je suppose que je pourrais m'inscrire pour mentorer pendant le mois et donner un coup de main. Mais en fait j'ai récemment rejoint le GoHort en tant qu'apprenant. Et puis je vais glisser depuis la section apprenants, je suppose. Jonathan : Je viens de glisser depuis la section apprenants, je suppose. Attention à ce pour quoi tu t'inscris. Je te le dis, on dirait un schéma qui se répète : tu t'inscris pour une chose et tu finis dans une autre, mais c'est vraiment cool. Bon, alors, quand tu as mentoré des apprenants sur la piste Go en particulier, quelles sont les choses les plus courantes que tu vois ? Je veux dire, la piste Go, il y a probablement pas mal de développeurs chevronnés, je dirais, qui l'ont faite, des gens qui avaient déjà un certain parcours en développement, mais quelles sont les choses que tu as remarquées, du genre, ok, ça, c'est courant, c'est là-dessus que les gens semblent bloquer ? Est-ce qu'il y avait des schémas ou des choses que tu trouvais, du genre, ok, c'est courant, ça revient assez... régulièrement, potentiellement. Isaac : Je ne sais pas. La plupart du mentorat que j'ai fait portait sur des gens ayant des solutions terminées. Les gens, la plupart du temps, ont déjà résolu l'exercice avant de demander du mentorat. Donc en général, les gens ne sont pas bloqués dans la plupart des échanges que j'ai. Euh, donc c'est surtout, tu sais, ils ont réussi à terminer un exercice et ensuite une grande partie des remarques, c'est, euh, tu sais, est-ce qu'il y a une façon plus efficace de faire ça ? Est-ce qu'il y a un meilleur algorithme ? Euh, une des choses courantes qui revient bien trop souvent, c'est la construction de strings, euh, dans. Dans des langages comme Go et Python où les strings sont immuables, faire beaucoup de concaténation de strings n'est pas très efficace. Donc c'est beaucoup de, hé, tu pourrais construire ça avec un tableau puis joindre les strings, ou tu peux utiliser un string builder en Go. Donc il y a beaucoup de, tu sais, on les pousse vers de meilleurs, je suppose, schémas, bonnes pratiques et schémas. Merci d'avoir regardé. Jonathan : Ok, c'est cool. C'est fascinant. Alors maintenant, à quoi ressemble ton quotidien au travail, et où est-ce que le développement s'y inscrit ? Disons que tu es dans la tech depuis un moment, à quoi ressemble la journée ? Quels sont les défis ? Quels sont les aspects que tu apprécies dans ton travail en ce moment ? Isaac : Donc j'occupe un poste de site reliability engineering, ce qui ressemble vaguement à du DevOps. Il y a un peu d'administration système là-dedans. Je porte un pager dans une rotation d'astreinte depuis une dizaine d'années. Donc mon quotidien dépend beaucoup du fait que ce soit ma semaine d'astreinte ou non. Quand je suis d'astreinte, c'est surtout surveiller le pager, il y a une file de tickets, une file de support, s'assurer que tous les processus en échec ou les problèmes sont diagnostiqués et corrigés. Donc c'est à peu près une semaine sur six, ou selon la taille actuelle de l'équipe. Et le reste du temps, je suis d'astreinte. Jonathan : Mm-hmm. Isaac : Je passe beaucoup de temps à bricoler de l'automatisation, donc c'est beaucoup repérer des processus pénibles et les rendre moins pénibles. Il se peut que... Il y a peut-être une raison à cela, mais en général je trouve que tant que quelque chose ne se met pas en route, tu sais, quand ce problème arrive, on doit exécuter, tu sais, on répare à la main en lançant telle et telle commande, et on se dit, bon, pourquoi on lance ces commandes à la main ? Est-ce qu'on peut écrire un script Python qui ferait tout ça à notre place ? Ou est-ce qu'on peut améliorer l'outillage pour qu'il ne tombe pas en panne et détecte lui-même ce problème ? Et beaucoup de simplement essayer d'améliorer le quotidien de la façon dont on fait tourner les systèmes, pour que les humains soient moins impliqués, ou n'aient pas besoin d'être aussi, tu sais, aussi profondément impliqués pour que tout tourne bien. Jonathan : Donc est-ce que ton quotidien, est-ce que tu aimes chercher ces petits domaines où on peut optimiser les choses ? Quelle part de ton travail consiste à réagir à des trucs et, à partir de cette réaction, à te dire, ah cool, c'est une occasion, versus chercher proactivement ces petits domaines ? Quel est l'équilibre en général ? Isaac : J'aime l'automatisation, c'est probablement ce que j'aime le plus dans mon travail, pouvoir automatiser des choses. Ce n'est pas toujours de la réaction. Je veux dire, réagir, ça peut vouloir dire que quelque chose casse, mais ça peut aussi être, oh, tu sais, les gens lancent cette commande, j'ai remarqué qu'il y a cette commande qu'on a tendance à copier-coller, est-ce que je peux l'améliorer ? Ou bien je vois quelqu'un modifier un runbook quelque part ou améliorer une commande quelque part et je me dis, oh, cette commande est plutôt bordélique, est-ce que je peux la réécrire de zéro ? Et bien sûr, l'attention, c'est trop, il faut l'équilibrer avec l'attrait, il faut moins de grands mots, un meilleur langage, ce genre de choses. Il faut se mettre au-dessus de ça en essayant de le faire. Honnêtement, je veux dire, tout dans mon boulot s'emboîte vraiment quand j'y pense. Donc je suis quelqu'un de très motivé, genre non, mon boulot je suppose qu'il est là... comme partout... mais dans n'importe quel boulot que j'aime, tuer le temps pour moi, c'est là seulement pour essayer de Jonathan : de la fabrication, on pourrait dire Isaac : Réécrire du code, remarquer qu'il y a des outils qui sont, tu sais, pénibles à utiliser et décider de les réécrire ou d'écrire des surcouches autour. Je vois, ouais, genre je vois des modifications de code dans un gros programme compliqué et je me dis, oh, ce programme est un fouillis. Est-ce que je peux y aller et le réécrire ? Ou créer de nouveaux... je veux dire, ce n'est pas toujours de la réécriture, c'est parfois juste créer de nouveaux outils. C'est genre, oh, on a un processus qui implique 20 étapes, je vais tout fourrer dans un programme. Souvent, tu sais, il faut que je les découvre d'une manière ou d'une autre. Parfois je les découvre parce qu'on me confie une série de tâches, et là je me dis, je n'ai pas envie de les lancer à la main. Parfois je les découvre juste en remarquant, genre, je cherche un morceau de code quelque part, et je me dis, oh, cet autre code là-bas, que maintient une autre équipe, fait les choses mal, je vais le réécrire, ou utiliser des bibliothèques modernes, ou peu importe, ouais. Jonathan : Donc beaucoup de... juste pouvoir le voir. Donc quelle marge de manœuvre as-tu ? Est-ce que tu as pas mal de liberté pour te balader et débarquer quelque part, ajuster par-ci par-là ? Je veux dire, ça doit être assez amusant, assez plaisant. Isaac : Mon manager me laisse beaucoup de liberté, ce qui est vraiment agréable. Je ne sais pas quelle part de ça vient de... je ne suis pas chez Google actuellement, mais je ne sais pas quelle part vient de mon passé chez Google. Chez Google, les gens étaient très ouverts à débarquer et à dire, oh, j'ai remarqué que les autres, tu sais, il m'arrive d'utiliser cette bibliothèque et elle pourrait être améliorée de telle manière. Je vais la corriger. Euh, j'ai travaillé très, très brièvement dans une startup où la culture était très différente, bien moins ouverte. Euh, et dans la startup, les gens étaient très protecteurs de leur base de code, et le fait que d'autres personnes modifient leur code n'était pas très bien accepté. Donc je me disais, oh, il y a un problème avec cette base de code, tiens, je vais vraiment la modifier, cette base de code. Jonathan : Ouais, du recul. Mais c'est intéressant parce que... on suppose qu'une startup serait bien plus du genre, bon, fais juste le boulot et fais-le le moins cher possible, tu vois, mais en fait, peut-être que Google était bien plus capable de gérer ça comme concept. Et c'est, pardon, je viens d'allumer la lumière parce qu'on n'a, pas de lumière actuellement pour tous ceux qui écoutent, pas d'électricité au Cap de temps en temps. Là je m'aveugle, mais ce n'est pas grave. Mais c'est intéressant de revenir à ce point sur la culture de startup et comment les gens sont bien plus, ironiquement, accaparés par le fait de posséder des trucs, et du coup peut-être de freiner un peu les choses, tu vois ? Isaac : Ouais, je ne sais pas si être une startup est forcément lié au fait d'être une culture de travail ouverte... du genre ludique. Chez Google, beaucoup de ce que les gens faisaient relevait du jeu, parce qu'ils aimaient ce qu'ils faisaient. Ils le faisaient parce qu'ils aimaient ça. Ils étaient très bienveillants là-dessus, ou très ouverts. D'autres cultures d'entreprise sont moins dans le fait de faire les choses parce qu'on aime ça et plus dans le fait que c'est un boulot, ou que c'est mon code et que je sais comment ça marche. Je ne veux pas que d'autres y touchent. Je ne sais pas trop ce qui entre en jeu pour faire évoluer ces cultures d'entreprise. Mais Google cultivait vraiment l'idée que tout le monde a accès à tout le code. Chacun est habilité à y apporter des modifications. Vas-y, fais ce que tu penses être juste. Et puis dans mon travail actuel, avec mon manager actuel, il m'a aussi donné beaucoup de liberté. Il se dit, bien sûr, tu as trouvé quelque chose à corriger. Vas-y, corrige-le. Tu as trouvé un domaine où on peut améliorer les choses. Je vais juste m'écarter de ton chemin. Dis-moi ce que je peux faire pour aider. Donc je peux vraiment m'autogérer sur une grande partie de ce que je fais et, tu sais, si je trouve un domaine où je me dis, oh, je pourrais améliorer ça, il me dit, ouais, c'est cool, vas-y. Jonathan : Ok, sympa. Et toi, l'entreprise est basée sur la côte Est, si je ne me trompe pas, donc tu travailles en fait à distance ? Je crois me souvenir que tu disais que tu allais déménager, et puis le COVID est arrivé et c'était un peu, tout ce projet est tombé à l'eau. Comment vis-tu le télétravail, la distance, le décalage horaire, tout ce genre de choses ? Est-ce que ça t'affecte ou... ? Isaac : L'absence de bureau et des interactions en personne me manque vraiment, oui. Euh, donc voilà pour ça, euh, le décalage horaire, mon, mon équipe a été très, euh, accommodante avec le décalage horaire. Donc j'ai trois heures de retard sur le reste de mon équipe. Euh, il y a un court standup quotidien que je rate. On a deux points quotidiens pour deux produits différents. Euh, donc le premier, c'est vrai qu'il me manque, et mon équipe a vraiment été très arrangeante là-dessus, et on utilise beaucoup Slack en interne. Donc ils sont très bons pour avoir genre un fil Slack quotidien avec les problèmes qui sont apparus, comme ça je peux me rattraper, et s'ils ont besoin de quelque chose, ils me contactent, euh, j'essaie vraiment d'être réactif, euh, et je traite tout ça aussi vite que possible le matin. Donc, euh, c'est un peu, c'est, le décalage horaire n'est pas génial, mais ce n'est pas non plus, ils ont été, on a réussi à bien faire avec. Euh, et inversement, il y a l'autre côté : ils savent qu'ils ont quelqu'un dans l'équipe qui est éveillé un peu plus tard. Donc j'ai eu des collègues qui, tu sais, il est 18 h sur la côte Est et ils se disent, oh, c'est cassé. Hé, Isaac est sur la côte Ouest, Isaac pourrait m'aider là-dessus parce qu'il n'est encore que 15 h là-bas. Euh, donc ça marche dans les deux sens. Euh, ouais, le, Jonathan : Ouais. Isaac : J'étais, ouais, donc j'ai quitté Google en 2019, pardon, 2020. J'ai passé les entretiens en 2019. Je devais rejoindre en mai 2020. Je prévoyais de déménager en août, avril 2020, mais le COVID est arrivé et tout ça, et le bureau a fermé, et c'était beaucoup de, oh, le bureau n'est pas encore ouvert. Il déménagera dès que le bureau ouvrira. Et puis deux ans après le début de la pandémie, ils ont commencé à rouvrir le bureau. Et je me suis dit, tu sais, je ne suis plus sûr de vouloir déménager. New York avait l'air vraiment excitant, mais il y avait tous ces commerces ouverts et, tu sais, des salles, des trucs qui se passaient. Mais maintenant qu'il y a une pandémie, tout ça sonne beaucoup moins excitant. Donc je suis passé à un poste à distance après avoir travaillé à distance pendant deux ans. Jonathan : Et tu es plutôt du genre ville, ou campagne, ou entre les deux ? Genre quoi ? Parce que New York, c'est la ville. C'est 100 % de la ville. Je veux dire, il n'y a pas à discuter. Tu vois ce que je veux dire ? Donc ça aurait été un sacré changement, je suppose. Oui. C'est excitant, quand même. Isaac : J'ai grandi dans une grande métropole, donc la vie citadine ne m'est pas étrangère. Je vis actuellement en banlieue. J'aime la randonnée et le vélo, et j'essaie de sortir en plein air aussi souvent que possible. Donc j'aime vivre en banlieue près de superbes sentiers de randonnée et de vélo, et tout ça. Déménager à New York serait un sacré changement. Mais je me dis que changer de temps en temps n'est pas une mauvaise chose. Et si ma vie à New York me déplaît, je déménage, c'est tout. Jonathan : Ce n'est pas si compliqué que ça. Mais c'est cool. Donc maintenant tu passes probablement, corrige-moi si je me trompe, beaucoup de temps devant l'écran, genre dans un bureau, un bureau à domicile ou peu importe. Est-ce que tu sors tous les jours pour... comment équilibres-tu tout ce monde de l'écran versus... est-ce que tu as un moment quotidien où tu te dis, il faut que je sorte et que je fasse autre chose. Isaac : J'aimerais bien. Certains jours, certains mois ou certaines années, je fais mieux que d'autres. En 2020, j'étais plutôt bon pour faire du vélo presque tous les jours. Je sors la plupart des week-ends. J'essaie de faire une randonnée par semaine. Je n'ai pas été très assidu, mais je vais faire une randonnée. Ça dépend de la saison. Je suis en Californie. Certaines semaines sont extrêmement chaudes. On vient d'avoir une vague de chaleur où il a fait... plus de 40 degrés Celsius pendant environ une semaine d'affilée. Donc ça rend les sorties difficiles. On est en Californie, où il y a des incendies, donc tu sais, parfois on passe une semaine ou deux où la qualité de l'air dehors n'est pas vraiment sûre à respirer. Donc ça rend le plein air difficile certaines semaines en Californie. Et puis rester à l'intérieur pendant une pandémie, c'est aussi un défi. Donc il y a clairement des semaines où je reste beaucoup plus à l'intérieur que d'autres. Mais j'aime sortir. Il y a eu, tu sais, j'ai eu des périodes de six mois où je faisais des randonnées, au moins une semaine sur deux. Jonathan : et puis. Isaac : J'ai eu des périodes où je campais genre une fois par mois pendant, tu sais, six mois d'affilée. Donc il y a des périodes où je fais mieux que d'autres, et il y a des périodes où je reste juste à la maison pendant genre deux semaines d'affilée. Jonathan : Ouais, c'est cool. Et donc Isaac, c'est quoi la suite, en quelque sorte... Peut-être, je ne sais pas, peut-être que tu n'as pas réfléchi aussi loin, mais à quoi ressemblent les cinq prochaines années pour toi, est-ce que tu as une idée, ou est-ce que tu es plutôt du genre, je veux monter ma propre entreprise, ou je veux faire ci, ou est-ce que tu es plutôt du genre, ah, je profite juste de la vie et de là où j'en suis. Isaac : Avant de déménager sur la côte Ouest, je pensais avoir une meilleure idée de ce à quoi ressemblerait mon avenir. Mais le fait que tout ça ait été chamboulé m'a appris qu'il est vraiment difficile de prédire ce qui va se passer dans l'année à venir, et encore moins dans cinq ans. Je suis plutôt heureux. Je viens de changer de travail, relativement récemment. J'ai changé de travail il y a environ deux, deux ans et demi. J'aime beaucoup mon travail actuel, donc je ne vois pas ça changer de sitôt. Je serais content de rester au même poste pendant les deux, trois prochaines années, dans cinq ans. J'adore vivre en Californie. J'adore pouvoir partir en randonnée, à vélo, camper et tout ça. Donc je ne me vois pas quitter la Californie de sitôt. Et je ne me vois pas quitter ce travail de sitôt parce que j'aime vraiment beaucoup y travailler. Donc je suis plutôt satisfait, et je ne vois pas de grand, je n'ai pas de grands changements prévus, mais c'est vraiment difficile à dire. Jonathan : C'est cool. Bon, j'ai encore deux ou trois questions, et j'aimerais beaucoup avoir ton point de vue dessus. La première n'est probablement pas celle pour laquelle je t'ai préparé, mais celle... Donc si tu allais... Si dix personnes débarquaient dans ton bureau maintenant, dix parfaits inconnus, et qu'ils ne connaissaient rien à la programmation, et qu'il y avait genre une harpiste, un jardinier et peu importe, quels seraient les trois meilleurs conseils que tu leur donnerais pour apprendre à coder ? Genre, si tu devais résumer en, fais ça à tout prix, quels seraient certains de ces conseils ? Isaac : Donc ma recommandation numéro un serait d'essayer de trouver un problème que tu pourrais résoudre avec du code. Donc tu as un... un projet concret qui te motive, sans objectif précis en tête pour te faire avancer. C'est extrêmement difficile de se lancer dans l'apprentissage du code, comme pour n'importe quelle autre compétence, apprendre à coder demande pas mal de ténacité ou de cran. Il faut juste persévérer. Ça peut être très difficile au début. Ça peut être très frustrant. Sans quelque chose pour te faire avancer, il est très facile d'abandonner. Donc si c'est possible, avoir quelque chose que tu veux vraiment faire avec, ça aide beaucoup. C'est un peu tout dans la même constellation de conseils. Il faut juste, tu dois persévérer. Ça aide beaucoup d'être patient avec soi-même et de reconnaître qu'on apprend une nouvelle compétence et qu'on va beaucoup échouer. J'ai vu des gens essayer d'apprendre à coder et se frustrer. Ils se disent, oh, je suis généralement bon dans ce que je fais et là ça ne marche pas du premier coup. Et je leur dis, ouais, l'échec fait partie du processus d'apprentissage. Et si tu n'es pas à l'aise avec le fait d'échouer, tu peux avoir vraiment du mal à acquérir de nouvelles compétences. Il faut être patient avec soi-même et avec le processus, et beaucoup persévérer. Jonathan : C'est utile. Je veux dire, je dirais que c'est un peu, je viens seulement de comprendre comment fonctionnent les méthodes. Et ça vient juste en parcourant, parce que beaucoup du savoir que, enfin, quand les gens parlent de trucs, il y a tellement de connaissances implicites quand on enseigne, surtout. Donc, genre, soudain tout le monde balance ce mot, méthodes. Je me dis, mais qu'est-ce que c'est que ça, une méthode ? Genre, qu'est-ce qui se passe ? Et c'est seulement grâce à la cohorte Go que j'ai commencé à comprendre, oh, les méthodes fonctionnent comme ça. Mais c'était presque comme le déclic, sauf qu'il a fallu que je m'immerge dans cet environnement et cette terminologie si longtemps que ça finit par s'infiltrer. Je dirais que c'est l'un de mes plus grands apprentissages : ne pas essayer de tout apprendre, mais avancer petit à petit sur un concept simple. Parce que tout est tellement lié qu'au bout d'un moment, tu arrives à assembler le modèle mental, ce qui est vraiment important. Donc c'est un super petit outil. Donc je le ferai savoir aux gens, cette recommandation d'Isaac : sois patient, sois bienveillant envers toi-même et avance petit à petit. C'est vraiment cool. Bon. Alors la dernière question que j'ai, et avant que je te laisse retourner à ta journée, on a parlé en équipe de ce concept de la colline sur laquelle tu es prêt à mourir dans la tech. Ça sonne assez mélodramatique et assez, il y a beaucoup de drame là-dedans. Et l'idée, c'est essentiellement : quelle est la seule chose que tu estimes absolument essentielle, que tu considères comme un état d'esprit ou une perspective inébranlable à avoir dans la tech ? Un bon exemple serait, je ne sais pas, à un niveau très trivial, je place toujours mes fonctions, puis je code mon CSS si je fais du front-end. Donc la fonctionnalité, puis la logique, puis peu importe. Ça pourrait être, tu sais, on en avait une, Rebecca qui gère la piste Unison. Elle disait que plutôt avoir un génie qui a des opinions bien arrêtées et avec qui c'est difficile de travailler, elle préférerait 50 personnes qui adorent vraiment travailler en équipe et résoudre des problèmes ensemble, qu'un seul génie qui accapare toute la bande passante en matière de gestion. Donc c'était l'une des siennes, et je l'ai formulée gentiment, mais quelle serait ta colline sur laquelle tu es prêt à mourir dans le domaine de la tech, ton genre de non négociable. Isaac : C'est probablement très fortement influencé par la façon dont Google fait les choses. Chez Google, ils ont ce concept de readability, où le code est censé être facile à lire. Et beaucoup de ce que je fais quand j'écris du code, je veux que mon code soit simple à lire et à comprendre. Et j'ai vu beaucoup de code, surtout, il y a beaucoup d'accent mis sur l'efficacité, les benchmarks, et rendre son code plus rapide. Et souvent je reconnais que ma façon de faire n'est pas forcément la plus efficace, mais si je trouve que le code est plus facile à lire, je préfère du code inefficace et facile à lire à du code ultra efficace. Donc, genre, tu sais, il y a cette citation courante, je ne sais pas à qui elle est exactement attribuée, comme quoi la racine de tous les maux, que l'optimisation prématurée est la racine de tous les maux. Et chaque fois que les gens disent, oh, comment ça pourrait être plus efficace ? Je réponds, est-ce que ça a besoin d'être plus efficace ? Tu es tombé sur, tu sais, est-ce que tu tournes en production et tu rencontres des problèmes d'efficacité ? Est-ce que c'est trop lent à utiliser en production ? Si tu n'as pas réellement rencontré de problème avec le code en production, où il aurait besoin d'être plus efficace, pourquoi le rendre plus efficace ? Il est déjà plus facile à lire tel quel. Il est plus facile à maintenir. D'autres personnes peuvent comprendre ce qui se passe. Pourquoi sacrifier du code bien écrit, facile à utiliser et à maintenir, pour économiser quelques cycles CPU ? Est-ce que l'électricité est assez bon marché et les CPU assez bon marché pour qu'on n'ait pas besoin d'optimiser le code ? Juste pour l'optimiser. Jonathan : Ouais, c'est toujours drôle parce que c'est un de ces trucs où je me dis... notre programme a compilé et tourné en 30 millisecondes. Et eux, ils disent, oh, mais on l'a fait descendre à genre 20 millisecondes. Et je me dis, je ne pourrais pas te dire. Je ne pourrais pas te dire lequel était plus rapide, lequel était plus lent. Ça a l'air rapide. Donc je pense que c'est un bon point. Je suis sûr que j'aimerais lire ton code, mais c'est génial. Isaac, merci beaucoup pour ton temps, pour t'être levé tôt et pour avoir supporté le délestage dans l'hémisphère Sud. Et pour moi assis dans le noir complet, je suis sûr que c'est probablement assez cocasse pour toi. Mais merci beaucoup pour ton temps. Et j'ai hâte de te revoir dans les prochaines cohortes d'apprentissage et dans les streams de mentorat et tout ça. Et merci pour toute la contribution que tu apportes à Exercism et partout. Donc j'apprécie. Et ouais, merci beaucoup encore une fois. Et je te revois dans une seconde. Non, avec plaisir. Prends soin de toi, Isaac. Salut. Isaac : Merci beaucoup encore une fois. Non, avec plaisir. Prends soin de toi, Isaac.