Ne sois pas trop productif !

Jonathan : Bonjour et bienvenue dans le podcast d'Exercism. Je m'appelle Jonathan et j'ai le privilège de t'accueillir aujourd'hui. Je suis accompagné de Franziska, qui est l'une de nos mainteneuses sur les parcours Go et JavaScript. Nous avons beaucoup de chance d'avoir Franziska chez Exercism, et elle est impliquée depuis plusieurs années. Donc si tu traînes dans le coin, tu as peut-être déjà croisé Franziska. Que ce soit dans les cohortes d'apprentissage ou sur les parcours Go et JavaScript. Alors Franziska, sois chaleureusement la bienvenue aujourd'hui. Merci beaucoup d'être venue. Je vais entrer directement dans le vif du sujet et te demander comment tu es arrivée là où tu es aujourd'hui ?

Franziska : Oui. Alors. Je suis Franziska. Sur internet, je suis June, ou June Dev. Je vis actuellement près de Francfort, en Allemagne, juste en dehors des limites de la ville, dans une petite banlieue. Et j'ai récemment commencé un nouveau boulot chez Atlassian. Atlassian, c'est l'entreprise derrière tout un tas d'outils qu'on adore ou qu'on déteste, comme Trello, Jira et Confluence. Et ce que je fais là-bas, c'est développer un nouvel outil pour aider les chefs de produit dans leur travail. Parce que Jira est centré sur les développeurs, mais ça ne colle pas à ce que les chefs de produit ont besoin de faire : prioriser des choses, et ainsi de suite. Donc on construit quelque chose spécialement pour eux. J'aime beaucoup Go comme langage. Je l'adore vraiment. Et le backend est construit en Go. Alors quand j'ai vu l'annonce, je me suis dit : hé, c'est cool qu'ils fassent ça. J'ai postulé et j'ai eu le poste. Ça ne fait que 30 jours, je ne sais pas, mais en tout cas, c'était une bonne expérience. Et puis, enfant, j'ai toujours été intéressée par la tech, les sciences naturelles, la science-fiction, j'étais une grande fan de Star Trek, tout ça. Je me débrouillais bien en maths et en physique à l'école. À l'époque, beaucoup de gens faisaient des études d'informatique, et on nous disait toujours de ne pas étudier ce que les autres étudiaient, parce qu'il y aurait trop de ces gens-là plus tard. Et je me suis dit : bon, peut-être que je ne devrais pas faire d'informatique, parce qu'il y en aura trop. Bref, je me suis dit : bon, faisons quelque chose de similaire. Je me suis donc retrouvée à étudier la physique, que j'aimais beaucoup à l'école. Et l'informatique était plutôt une matière secondaire pour moi. J'ai suivi quelques cours, mais pas autant que les autres. On arrive à un moment où il faut se demander : bon, qu'est-ce que je vais faire du reste de ma vie, pas vrai ? Comment est-ce que je gagne ma vie en faisant quelque chose que j'aime vraiment faire ? Et j'ai réalisé que la partie programmation était en fait ce que je préférais dans mes études, et que j'étais douée pour ça. Et je voulais en faire plus. Et c'est aussi quelque chose qui permet de payer les factures. Donc voilà, je me suis dit : bon, comment trouver un job dans ce domaine sans avoir un diplôme classique d'informatique à ce stade ? L'autre chose, c'est qu'à ce moment-là je ne voulais pas devenir développeuse C, développeuse Java, ce genre de truc vieux jeu. Du code backend bancaire quelque part. Donc je me suis dit : bon, comment apprendre les trucs modernes, le web, internet ? Je veux construire quelque chose pour ça. Et puis un ami m'a dit qu'il existait des trucs qu'on appelle les bootcamps de développement web, où tu peux aller quelque part pendant trois mois et on t'apprend les nouveaux trucs cool. Oui. J'ai donc décidé que je voulais faire ça. Et qu'à partir de là, j'aurais sans doute un meilleur point de départ pour trouver un job. Et à l'époque, il n'y en avait aucun ici, en Allemagne. Oui. Soit tu pouvais aller à l'université pendant des années et des années, tu vois ? Soit il y avait des endroits où tu pouvais un peu travailler et étudier en même temps, mais c'étaient aussi d'énormes programmes, des années et des années de formation. Et côté bootcamps, ils n'avaient que... Des trucs du genre accélérateurs de startup. Où tu apprenais un peu de code, mais aussi du management, de l'économie et ainsi de suite. Ça ne me convenait pas vraiment. Donc j'ai cherché un peu autour de moi, et j'ai fini par trouver : il y en avait un bon à Londres, avec les matières que je voulais apprendre.

Jonathan : C'est ce qui tourne

Franziska : Le web, c'est là que ça se passe. Oui, exactement. Exactement. Là où les nouveaux trucs cool se passent. Oui, j'ai trouvé ce bootcamp, et j'y suis allée. C'était vraiment une super, super expérience. Et on faisait du Node.js pour le backend. Et puis je suis retournée à Francfort et j'ai trouvé un job de développeuse Node. L'entreprise était plutôt cool, la tech vraiment cool, et je me suis adaptée à tout très vite, c'était très amusant. Mais je n'ai pas eu de chance avec mon équipe : il y avait pas mal de collègues avec un gros ego, très machos. Et quand tu avais une réunion, c'était celui qui parlait le plus fort qui gagnait la discussion. Et ça, ce n'est pas une équipe agréable.

Jonathan : C'est un thème assez courant : les gens se lancent dans la programmation, et puis l'aspect périphérique, l'aspect équipe, est toujours ce à quoi les gens ne s'attendent pas comme problème ou comme défi. Donc ça semble être assez courant. Désolé.

Franziska : Oui. Oui. Tout à fait. Et au début, tu surestimes la partie technique. Tu te dis : oh, ce job a exactement la tech que je veux faire, donc tout ira bien. Mais en fait, la partie équipe est presque plus importante que la tech précise que tu utilises. Oui. Et donc, au bout de deux ans, un ami qui était CTO dans une autre entreprise ici, à Francfort... Il m'a dit : nous aussi, on aimerait transformer notre stack technique et construire quelque chose de nouveau, mais on ne veut pas faire du Node.js. On voulait passer à Go. Il a décidé ça pour on ne sait quelle raison, et il m'a dit que je pouvais les rejoindre. Mais il faudrait que j'apprenne Go, bien sûr. Et j'ai dit que si ça ne le dérangeait pas que je prenne un peu de temps au début pour l'apprendre, j'étais partante. J'ai jeté un œil au langage et ça avait l'air sympa. Bref, j'ai changé d'entreprise. Et dans ce nouvel endroit, l'équipe était vraiment cool. Là, c'était vraiment le cas : si tu discutais avec le PDG et que ton argument était meilleur, ça se remarquait. Et les gens réagissaient à ça. C'était vraiment agréable de travailler avec eux, et les gens étaient vraiment intéressants, etc. Je suis donc restée cinq ans. J'ai construit pas mal de services orientés croissance, et aussi beaucoup de contenu rédigé, des concepts pour aider à intégrer d'autres développeurs à Go, et j'ai aussi fait un peu de front-end, etc. Oui, mais après cinq ans, on cherche aussi un nouveau défi. Et puis, ce qui m'a poussée à chercher un nouveau job, c'est la situation du Covid. J'ai remarqué que je travaillais de toute façon depuis chez moi, tu vois ? Et que j'allais peut-être au bureau une fois par semaine. Je me suis dit qu'il y avait plein de jobs en full remote. Que je pourrais peut-être trouver quelque chose de vraiment cool dans une plus grande entreprise. Puisque je travaille de toute façon depuis chez moi, autant travailler pour cette entreprise plus grande et plus cool, non ? Donc voilà, c'est à ce moment-là, alors que je travaillais, que j'ai trouvé ce job chez Atlassian.

Jonathan : Donc je crois que ma question, c'était : est-ce que toute la pandémie t'a en quelque sorte ouvert l'esprit à l'idée que, oh, il y a peut-être plus que Francfort et la scène startup de Francfort ? Parce que j'allais demander : c'était comment, la scène startup à Francfort, comme espace ?

Franziska : Oui, alors juste pour le point Covid : ce que le Covid m'a ouvert, c'est cette idée de travailler entièrement à distance. Avant, j'étais plutôt du genre à aller au bureau. J'aime voir les gens en personne, c'est comme ça que je structure ma journée, etc. Mais j'ai réalisé qu'après avoir travaillé surtout à distance pendant deux ans, en fait, ça va. Je gère. J'ai ma fille, je dois sortir tout le temps de toute façon, etc. J'ai donc assez de structure dans ma journée maintenant. C'est quelque chose que la pandémie m'a en quelque sorte montré, et ça m'a donné envie d'envisager d'aller voir ailleurs. Pour ce qui est de Francfort, il s'y passe beaucoup de choses en matière de tech et de startups, mais... Comme tu peux t'en douter, il y a beaucoup de choses centrées sur la banque, donc pas mal de fintechs, etc. Et ce n'est pas particulièrement... J'ai travaillé dans la fintech par le passé, mais ce n'est pas un sujet qui me passionne vraiment. Donc c'était toujours un peu bof. Et puis il n'y a pas non plus beaucoup de développeurs Go dans le coin. Oui, rien ne me retenait vraiment à Francfort en particulier, ni dans la scène de Francfort. Voilà, donc...

Jonathan : Non, bien sûr. Et est-ce qu'il y a des langages précis sur lesquels Francfort se concentre, d'après toi ? Évidemment, la fintech... tous les langages qui sous-tendent ça sont sans doute un peu plus au centre ? Donc est-ce que tu te sens un peu comme une espèce rare en tant que développeuse Go à Francfort ? Ou est-ce que ça augmente ? Comment tu vois les choses ?

Franziska : Oui, c'est difficile à dire, si ça augmente ou pas en ce moment, parce qu'il n'y avait pas beaucoup de meetups et ce genre de choses à cause du Covid, tu vois ? Donc c'est dur de dire s'il y a de plus en plus de gens qui viennent aux meetups au fil du temps en ce moment. Oui, je pense qu'il se passe beaucoup plus de choses, par exemple du côté de Java. Donc c'est un peu, c'est un peu difficile à dire exactement, mais par exemple, avec JavaScript, ce n'est généralement pas si compliqué de réunir une communauté, parce que tout le monde a un peu de front-end quelque part, tu vois ? Donc il se passait souvent plus de choses dans ce monde du front-end que dans le backend.

Jonathan : Et est-ce que, quand tu as commencé à coder et que tu es allée au bootcamp, tu as forcément eu une partie front-end que tu as un peu explorée, et maintenant tu es plutôt axée back-end ? Pourquoi est-ce que tu préfères le back-end au front-end ? Ou est-ce juste une supposition de ma part ?

Franziska : Non, c'est sûr, c'est quelque chose que j'ai compris pendant le bootcamp : je suis plus attirée par la partie back-end, et il y a plusieurs raisons à ça. D'abord, je ne suis pas une personne de design, et quand tu fais du front-end, tu dois souvent prendre toi-même des décisions. Parfois : à quoi ça devrait ressembler ? Qu'est-ce que je peux faire ici ? Comment améliorer ça, écrire du CSS, etc. Et c'est super dur pour moi de prendre ce genre de décisions. Bien sûr, tu reçois aussi des maquettes quand tu fais ça dans le vrai monde. Mais bon, je n'ai pas vraiment l'œil pour ce genre de choses. Et j'ai vu que les développeurs front-end qui ont ce sens et qui savent le faire sont plus efficaces dans leur travail. Donc c'était une chose pour laquelle je me suis dit que ce n'était pas vraiment pour moi. Et l'autre chose, c'est qu'aujourd'hui, l'espace front-end est vraiment super complexe. Les frameworks qui traînent par là, la plupart de ceux qu'on utilise couramment, sont vraiment difficiles. D'une certaine façon, le back-end actuel est aussi un peu plus facile. C'est plus dur dans le sens où c'est plus difficile à visualiser, tu vois ? Tu ne vois pas le résultat final en regardant ton écran, comme en front-end, où le résultat final est là devant toi. Mais du point de vue de la complexité de la tech impliquée, je trouve ça plutôt plus facile actuellement que ce qui se passe dans l'espace front-end. Donc pour moi, à un moment donné de ma carrière, je veux clairement me remettre aussi au front-end. Mais j'attends qu'un meilleur framework arrive. Et quand tout ce bazar actuel se sera calmé et qu'il y aura quelque chose de mieux, alors j'y retournerai et je redeviendrai développeuse front-end.

Jonathan : Je vais peut-être attendre que tu décides quand ce framework arrivera, et je te rejoindrai, parce que... quand je regarde les frameworks construits sur JavaScript, et... je suis un débutant. Dans tous les sens du terme. J'essaie d'apprendre Go en ce moment et ça me plaît. Mais rien que les concepts et le modèle mental qu'il faut avoir, c'est déjà un monde entier à part. Et je voulais te demander comment tu as fait le saut entre l'apprentissage de JavaScript, quand tu as commencé à programmer, et Go, parce que tu donnes l'impression que c'était un processus assez simple : bon, de JavaScript à Go. Mais c'était comment ? Qu'est-ce que tu as fait pour faire cette transition ?

Franziska : Oui. Bonne question. Un truc important ici, c'est que JavaScript n'était pas mon seul langage, tu vois ? À l'université, je ne suis pas allée en profondeur dans beaucoup de langages, mais j'ai appris le C. J'ai appris Java, j'ai appris le C++, j'ai appris des trucs comme Mala et quelques-uns de ces langages un peu exotiques. Donc pour moi, JavaScript était déjà ma cinquième langue environ, et Go a été la sixième. Pour moi, par exemple, Go, c'était tout un truc : tu entends parler des pointeurs et tout ça, et si je n'étais arrivée qu'avec du JavaScript, ça aurait été quelque chose de complètement nouveau, j'aurais dû apprendre ce que c'est, etc. Mais avec tous ces autres langages en arrière-plan, je connaissais déjà ça du C et du C++, etc. Je me suis donc appuyée sur beaucoup de choses que j'avais déjà apprises à l'université, et ça a rendu l'apprentissage vraiment facile. Et l'autre chose qui aide avec Go, c'est que c'est un langage assez minimal. Il n'a pas tant de mots-clés que ça, il n'a pas tant de constructions que tu peux assembler. Tu peux en faire le tour assez rapidement. Je dis souvent : va faire le tour officiel, va sur le site ou autre. Et en deux ou trois semaines, tu as fini. Et tu en ressors avec une compréhension solide. Avec JavaScript, ce serait impossible. Il te faudrait bien plus longtemps rien que pour avoir une compréhension solide des bases, et ensuite il y a tellement plus à apprendre. Voilà. Le fait que mon langage cible soit comme ça a aussi beaucoup aidé à rendre la transition facile.

Jonathan : D'accord. Donc maintenant tu travailles pour Atlassian, et tu as mentionné un peu le recoupement entre les produits, la tech et tout ce genre de choses. Et tu as dit que la fintech ne t'apportait pas grand-chose, que ce n'était pas particulièrement passionnant pour toi. Est-ce que tu dirais que l'espace produit et l'interface entre la tech et le produit sont un domaine qui te plaît vraiment ? Et sinon, qu'est-ce qui, dans la tech en particulier, serait ta passion si tu pouvais la résumer ? Je sais que c'est une très grande question, mais tu peux nous en dire un peu plus ?

Franziska : Oui, il y a différents types de domaines ou de sujets qui m'intéressent. Ce n'est pas seulement là où je travaille maintenant. Par exemple, j'aime beaucoup ce qui se fait dans les produits grand public. Il y a des entreprises comme HelloFresh qui font plein de choses cool. Des choses cool liées à la tech aussi, ou bien tout ce qui se passe dans l'éducation, comme Exercism et compagnie. Et puis l'autre domaine, c'est celui de l'outillage pour développeurs, ou de l'outillage pour les équipes en général. Il y a donc plusieurs domaines, et celui-là en faisait partie, un de ceux où je pouvais me dire : hé, ça a beaucoup de sens d'aider les gens là-dessus. Et puis, pour ce qui est de la gestion de produit en particulier, je peux raconter cette anecdote avec Jeremy, et aussi avec mon... mon PDG de ma précédente entreprise. Je lui ai parlé de ce nouveau job et de ce sur quoi j'allais travailler, et il m'a dit la même chose que Jeremy, le fondateur d'Exercism. Il m'a dit exactement la même chose : est-ce que tu as choisi ce job parce que tu étais frustrée par mes compétences en gestion de produit ? Et donc tout ça... ça te montre que la gestion de produit, et le fait de l'améliorer, a toujours été quelque chose qui me tenait à cœur. Parce que voilà : en tant que développeur, tu peux écrire le meilleur code du monde. Mais si tu écris la mauvaise chose, si tu construis la mauvaise chose, alors tout ça ne sert à rien, non ? Donc si ton chef de produit n'a pas bien fait son travail pour identifier les bonnes choses à construire, alors peut-être que personne n'utilisera jamais ce que tu as construit, parce qu'ils n'ont pas bien analysé le marché, qu'ils n'ont pas bien priorisé, etc. Et j'ai vécu ça dans mes jobs précédents. J'ai construit plein de choses qui n'ont jamais vu le jour, parce qu'il n'y avait pas de bon processus de priorisation, tu vois ? C'est pourquoi je pense qu'améliorer ce domaine de la gestion de produit en général rend aussi la vie des développeurs du monde entier bien meilleure, parce qu'ils peuvent alors construire les bonnes choses et vraiment créer de la valeur, au lieu de construire quelque chose qui finira à la poubelle ou que les utilisateurs ne verront jamais.

Jonathan : Oui, non, c'est vraiment intéressant, parce que ce que tu sembles relever, c'est... mentalement, je pense qu'on a souvent eu cette mentalité : si tu es bon en tech, tu le fais tout en arrière-plan. Tu ne vois jamais le jour en tant que personne parce que tu fais de la tech, et c'est vraiment le stéréotype, on peut dire. Mais on a l'impression que ces dernières années, il y a de plus en plus de recoupements entre la tech et le côté business. Et pour moi, j'ai toujours réfléchi à l'agilité comme concept. Et ce concept agile, je pense, est en réalité une mentalité business, une façon de voir les choses imposée à une équipe technique. Dans mon esprit, si je suis vraiment honnête, c'est ce que ça donne : c'est utile, mais je ne crois pas avoir déjà vu un environnement agile porter ses fruits à temps, si tu vois ce que je veux dire. Et c'est peut-être parce que je l'ai vu mal géré par le passé, mais on a vraiment l'impression qu'il y a plus de recoupements, que les développeurs commencent à vouloir s'impliquer davantage dans le côté business, ce que je trouve vraiment intéressant et plutôt positif, parce que du coup les décisions sont meilleures dans l'ensemble.

Franziska : Oui, c'est... certains développeurs veulent s'impliquer davantage, mais d'autres ne le veulent pas, et pourtant ils doivent quand même s'impliquer davantage. Le truc, c'est que ça ne marche tout simplement pas comme ça : la gestion de produit s'assoit, découpe tout, puis balance ça par-dessus le mur et ton développeur le construit, et tout va bien. Ça n'a jamais vraiment bien marché, même par le passé, quand c'était le modèle standard. Et aujourd'hui, oui, on y accorde plus d'attention, mais ça a toujours été la bonne chose d'avoir davantage de dialogue entre les développeurs et les designers, les développeurs et les chefs de produit. Et puis aussi, dès que tu as des équipes plus en aval, par exemple une équipe de support et peut-être quelqu'un qui fait la maintenance pour toi, ou peu importe. Plus ils travaillent ensemble de près et élaborent vraiment ensemble la meilleure solution possible, mieux c'est, plus vous pouvez créer de valeur ensemble. Et ça a toujours été vrai. Par exemple, actuellement, sur la fonctionnalité sur laquelle on travaille, la gestion de produit a plein d'idées sur ce qui pourrait faire partie de la première itération de cette nouvelle fonctionnalité, mais eux, ils ne peuvent pas en juger par eux-mêmes. Est-ce qu'ajouter tel truc, c'est une journée de travail de plus, ou est-ce que ça ferait exploser tout le périmètre et rajouterait trois mois de travail ? Oui. Donc pour eux, c'est impossible à évaluer. La seule façon de trouver un bon découpage pour cette première itération, c'est de se parler et de dire : ça, ce serait facile à ajouter. Ça, c'est difficile à ajouter, etc. Et on arrive à un bon périmètre. Et ce qui est bien dans mon job chez Atlassian, c'est qu'on a un chef de produit qui voit les choses de la même façon. Il dit toujours que le périmètre, c'est quelque chose qui se fait à deux. Moi, j'ai des idées ici, mais toi aussi tu dois me donner ton avis sur ce qui a le plus de sens. Et ensuite on trouve une solution ensemble. Je vois aussi que quand je suis passée par le processus de recrutement, tout ce sujet de la communication avec les autres, avec les autres équipes, etc., est très mis en avant actuellement. Beaucoup de gens demandent : comment as-tu travaillé avec les autres équipes ? Et rien qu'en te parlant, ils évaluent aussi à quel point tu sais t'exprimer, parce que c'est super important que tu t'intéresses à ce que font les autres équipes et que tu t'y impliques. Et c'est seulement comme ça que tu peux vraiment tirer le meilleur parti du temps que tu as.

Jonathan : Ça ressemble à une approche beaucoup plus intégrée, dans ce sens. Et ça m'amène à une autre réflexion, c'est que très souvent

Franziska : Oh, peut-être qu'avant de continuer : tu as mentionné le mot qui me déclenche, « agile », hein ? Donc il faut que je rebondisse là-dessus. Je ne sais pas si c'était fait exprès pour me provoquer ou pas. Oui. Pour ce qui est de l'agilité, je trouve toujours que les idées de base d'où vient tout ce truc, « les gens sont plus importants que les processus » et toutes ces choses fondamentales qu'ils ont imaginées il y a longtemps, gardent beaucoup de sens. Il y a beaucoup de magie autour. Mais ensuite sont arrivés tous les consultants, ils ont inventé tous ces frameworks massifs, et ainsi de suite, et ils les ont vendus, et il y a des scrum masters, et cetera. Et d'après mon expérience aussi, comme tu dis, une grande partie de tout ça n'aide pas tant que ça. Si, par exemple, les équipes produit et les développeurs ne communiquent pas très bien, ajouter toutes ces structures par-dessus ne règle pas vraiment le problème. Donc voilà, je ne suis pas non plus une grande fan de ces pratiques scrum standard, des pratiques agiles ; je n'ai pas non plus vu ça fonctionner superbement quelque part.

Jonathan : C'est intéressant, parce qu'on a l'impression que... Si tu cherches un job sur LinkedIn, genre product owner ou chef de produit, alors c'est du scrum, de l'agile partout. Partout, tu te dis : c'est incroyable. Mais c'est assez drôle de voir que les équipes de développement les plus... comment dire... les plus débrouillardes que j'ai vues fonctionnaient en Kanban, où il n'y a pas la pression de devoir produire dans un délai donné, mais où la qualité est là, et où tu redonnes la responsabilité à l'individu pour qu'il en réponde, ce qui a été très intéressant à vivre, parce que les jeunes équipes se bloquent sur l'agile, ça ne marche pas, ça les frustre, et elles finissent par arriver au Kanban, où on avance petit à petit, de façon régulière, et où les choses fonctionnent. Mais je trouve aussi intéressant de comparer le fait d'avoir un produit en tant qu'entreprise et le fait de construire des produits pour les autres. Je ne sais pas quel était ton job précédent, si c'était un produit interne. Je sais qu'à Atlassian, vous construisez essentiellement vos propres produits.

Franziska : Oui, j'ai toujours construit mes propres produits. Je n'ai jamais travaillé en agence.

Jonathan : Oui. Les agences, c'est un cauchemar, parce que c'est là que tout le monde épluche chaque heure de développement, et ils te disent : mais je ne comprends pas. Pourquoi ce bouton me coûte 400 $ ? Et c'est parce que tu voulais le déplacer de là à là, ce qui a demandé de refaire tout le backend. Donc je voulais te poser une question qu'on a posée à beaucoup de gens dans nos différents podcasts et lives. C'est tout ce concept de la colline sur laquelle tu mourrais, ou de la chose que tu défendrais toute ta vie quand il s'agit d'une opinion ou dans la tech. Ce n'est pas qu'on veuille dire que c'est l'opinion que tu dois avoir, mais plutôt : quelle valeur ou quelle opinion as-tu que tu dirais absolument capitale pour toi et que tu aimerais voir partout dans le monde de la tech ? C'est une question assez large, mais y a-t-il une chose que tu défendrais très fermement dans la tech ?

Franziska : Je pensais que tu rendrais ça un peu plus léger. Je voulais partir sur une opinion impopulaire, plus légère. Ça te va aussi ?

Jonathan : Oui, tout à fait.

Franziska : D'accord. Je n'ai pas tant de collines sur lesquelles mourir que ça. Une des choses qui me tient à cœur, c'est que beaucoup de gens te suggèrent d'optimiser ta configuration personnelle de développement. Et je pense que c'est largement surestimé. Les gens te diront : oh, il faut que tu apprennes Vim, parce qu'alors tu ne toucheras plus jamais à ta souris, c'est génial, etc. Et les gens y croient : quand ils débarquent dans le métier, ils y croient. Et puis ils passent un an à apprendre tous les raccourcis magiques, etc. Et au final, je ne sais pas, ils gagnent peut-être une journée par an. Donc cette année de souffrance n'a pas payé. Et il y a plein de choses comme ça : les gens te disent qu'il faut configurer tous tes alias pour ton terminal dans tes dotfiles, ou qu'il faut connaître toutes les combinaisons de raccourcis, etc. Et tu passes énormément de temps à apprendre ces trucs, mais au final tu ne gagnes pas grand-chose. Et je pense que ce qui se passe, c'est que les gens surestiment le temps qu'ils passent à taper au travail, tu vois ? Comme on l'a dit plus tôt, une grande partie du boulot consiste aussi à communiquer. Une grande partie du boulot consiste en fait à réfléchir. Oui. Et il n'y a qu'une petite partie de ta journée où tu tapes réellement quelque chose, du code ou des commandes, etc. Donc beaucoup de gens optimisent cette toute petite partie de la journée, et à mon avis, oui, si c'est ton hobby, alors vas-y. Ou si ça t'apporte une valeur similaire. Si tu es SRE, donc ingénieur en fiabilité de site (site reliability engineer), et que tu bidouilles des serveurs, etc., alors ça peut avoir du sens de connaître Vim, non ? Parce que tu ne peux pas ouvrir d'interface graphique. Mais si tu n'en as pas besoin, alors ne t'en fais pas. Utilise ce avec quoi tu es à l'aise, c'est tout. Par exemple, pour les raccourcis, je dis toujours : bon, la plupart des interfaces graphiques t'affichent le raccourci à côté de la chose sur laquelle tu cliques. Donc si tu cliques dessus cinq fois par jour, ou toutes les cinq minutes, alors ça peut avoir du sens de mémoriser, tu vois ? Le raccourci pour enregistrer, ça vaut le coup si tu cliques dessus tout le temps. Mais sinon, sois content dans ton interface graphique et fais ton truc, et passe plutôt ce temps à améliorer tes vraies compétences de programmation. Fais des exercices, ce genre de choses. Apprends un nouveau langage. Peu importe. Mais voilà, c'est quelque chose que j'essaie toujours de dire aux nouveaux développeurs : ne te laisse pas intimider par ces gens qui te disent qu'il faut utiliser un de ces éditeurs ancestraux et optimiser ta productivité là-dessus, et...

Jonathan : C'est drôle, parce que souvent, les passions des gens s'immiscent dans le tableau, et c'est compréhensible. Parce que c'est : oh, je suis super enthousiaste parce que j'ai optimisé ma vie. Mais en y réfléchissant, ce n'est pas toujours le mieux. C'est ce que j'ai vécu en apprenant : il y a tellement de choses, de recommandations que les gens reçoivent. Et si tu vas sur YouTube et que tu cherches comment apprendre à coder, quelqu'un commence par comment configurer ton GitHub. Un autre commence par comment comprendre le terminal, etc. Moi, je dois tirer le code pour travailler en local et dans l'éditeur en ligne, peu importe. Bref, je pense que c'est un très bon conseil : garde les choses assez simples. Donc, si tu vas passer plus de temps à réfléchir, comment... qu'est-ce que tu fais pour réfléchir aux problèmes ? Si tu as une situation au travail, ou en général, qu'est-ce que tu fais dans ta journée ? Est-ce que tu te ménages du temps ? C'est quoi ton processus ?

Franziska : Une chose par laquelle j'aime commencer, c'est en gros de me saisir du problème un peu en avance, avant d'avoir réellement à le résoudre, puis de juste le garder quelque part dans un coin de ma tête pendant une semaine ou deux. Et puis, sous la douche, j'y pense un peu. Et avant de dormir, j'y pense un peu, je le retourne dans ma tête un moment. Et généralement, ça m'aide à trouver quelques points de départ. Et à partir de là, surtout quand c'est pour le travail, je commence généralement par noter quelques points, parce qu'écrire les choses m'aide vraiment à clarifier mon esprit, à repérer les points où j'ai encore besoin de parler au chef de produit, par exemple, parce que je ne sais pas exactement ce dont les clients ont besoin là. Je note donc ce que je sais déjà et comment le résoudre. Et je note aussi, en général, un assez grand tableau de questions ouvertes, soit pour quelqu'un d'autre dans l'équipe, soit pour moi-même, les choses à élucider. Et ça m'aide vraiment à y voir plus clair. Et ensuite, à partir du concept de très haut niveau, j'essaie de le découper en tâches de programmation plus concrètes. À quoi ressemble l'API ? Quelles données dois-je stocker pour ça ? Et ensuite, comment ça part de l'histoire pour aller aux données et revenir, et quelle logique doit intervenir en chemin. Ça dépend. Il peut arriver que j'aie déjà trouvé beaucoup des problèmes à résoudre pendant ma phase de réflexion, mais parfois, quand je commence à coder, je découvre de nouveaux problèmes que je n'avais pas anticipés, et je dois alors prendre du recul, réfléchir à nouveau, puis revenir au code. Ça arrive aussi. Mais en général, la méthode, c'est d'abord d'essayer de réfléchir un peu au problème, et de résoudre certains problèmes à l'avance ; ça m'aide beaucoup. Et ensuite, soit le code est simple à écrire, soit je trouve d'autres problèmes et je reviens en arrière, mais ce n'est pas grave non plus.

Jonathan : D'accord. Non, c'est cool. C'est souvent ce que j'ai en tête, cette idée que si tu es programmeur à plein temps, tu es littéralement assis devant ton ordinateur, du matin au soir, à gratter petit à petit. Mais je réalise que la capacité à réfléchir aux problèmes, et je pense que c'est aussi ce qu'Exercism essaie de mettre en avant, c'est de bien réfléchir au problème. De s'assurer qu'on a tout le contexte. Et la partie codage n'est alors vraiment que l'expression de ce processus, mise en œuvre. Et Jeremy dirait la même chose. Je pense qu'il réfléchit à beaucoup de choses, puis code assez peu.

Franziska : Oui. Et aussi, c'est un conseil courant de commencer par écrire en commentaires ce que tu veux que ce truc fasse. Bon, je dois faire ceci d'abord, puis ça, c'était le résultat, et ensuite ça, et alors je remplis les bouts de code pour chaque étape. Ça aide vraiment beaucoup aussi.

Jonathan : C'est drôle, parce que ce que tu dis, je vais vraiment essayer maintenant, parce que je réalise... quand tu dois programmer, et surtout pour apprendre Go ou autre. Un des exercices que j'essayais de faire consistait à prendre une entrée au clavier, la stocker, puis renvoyer un truc du genre : tu as fait tel nombre de tentatives, peu importe. Mais tout le processus de réflexion pour décomposer ce problème en tâches vraiment granulaires, c'était quelque chose que je ne connaissais pas du tout. Et c'était vraiment intéressant d'apprendre comment réfléchir à un problème de ce genre, étape par étape. Donc non, ce sont de bons petits conseils, je les prends.

Franziska : C'est aussi quelque chose que beaucoup de gens... sur Exercism, beaucoup de gens ne peinent pas tant que ça à comprendre le langage et la syntaxe. Mais ensuite, ce « comment est-ce que je résous ce problème assez général », c'est là que les gens bloquent. Et on a essayé un peu de fournir de la documentation là-dessus aussi, en disant : voilà, c'est une bonne ressource pour apprendre à penser comme un programmeur, etc. Mais oui, on peut peut-être aussi faire mieux de ce côté-là.

Jonathan : Non, c'est... Non, c'est vrai. Et je pense que ça mène à une question intéressante que j'ai aussi posée à quelques personnes, et qui a toujours été intéressante quand j'en ai parlé avec d'autres. C'est tout ce concept : à quel moment la programmation a fait « tilt » pour toi ? Je ne sais pas si tu as déjà eu ce sentiment. C'était des concepts et de la théorie, tu as potassé des manuels, et puis tu t'es réveillée un matin et d'un coup tu t'es dit : oh, mais c'est évident. C'est souvent ce que je vis en apprenant quelque chose. C'était quand pour toi, ou est-ce que ça t'est arrivé ? Ou est-ce que c'était juste progressif, un « bon, j'ai compris petit à petit » ? C'était quoi ?

Franziska : Ah oui, j'y ai un peu réfléchi, et oui, je pense qu'il y a eu un moment de déclic. Mais laisse-moi commencer par le début. Au départ, ça n'a pas fait tilt, si ça te va. Quand j'étais adolescente, j'avais un de ces ordinateurs jouets avec quelques jeux dessus. Et il avait aussi une fonction qui permettait de programmer en BASIC. Et mon grand-père est passé, et il... il avait commencé par programmer ces cartes perforées, en gros. Donc il a toujours été branché tech, et il s'est dit : oh, cool, tu peux programmer là-dessus. Et il voulait me montrer que la programmation, c'est cool. Et il a commencé comme tout le monde commence. Il a tapé print, Hello World, et ça a recraché Hello World. Et moi j'étais là : je sais taper Hello World. Qu'est-ce que tu essaies de me montrer ? Et il a dit : non, il fait ce que tu lui dis de faire, etc. Et puis il tapait un truc comme « un plus deux », et ça recrachait trois. Et moi : ma calculatrice sait faire ça. Qu'est-ce que tu veux me montrer ? Je ne comprenais pas. Et plus tard, j'ai eu un truc d'informatique à l'école. Et là, on avait Turbo Pascal, et il y avait un plugin ou quelque chose comme ça qui permettait d'avoir une petite tortue et de dessiner quelque chose à l'écran. Et là, ils nous donnaient des exercices sympas où tu entrais des sortes de formules, et ça dessinait de super fractales complexes, des trucs qui ressemblent à des feuilles, etc. Et tu obtenais ça juste en tapant une petite formule qui disait à la tortue quoi dessiner. Et c'est là que ça a fait tilt pour moi, parce que j'ai réalisé qu'à partir d'instructions super simples, on pouvait créer une chose complexe que je n'aurais jamais pu faire moi-même. Je n'aurais jamais pu dessiner tout ça à la main, tu vois ? Donc pour moi, c'était ça : ah oui, cette machine peut faire plus que ce que je pourrais faire moi-même. Mais avant, avec les explications de mon grand-père et ce qu'il m'avait montré là-dessus, ça n'avait pas marché. Mais voir cette chose graphique et voir à quel point peu d'instructions suffisent pour que l'ordinateur fasse cette chose complexe, c'est là que ça a fait tilt pour moi.

Jonathan : D'accord, c'est cool, parce que j'ai eu ça avec les méthodes l'autre jour. Je me disais : mais qu'est-ce que c'est que ce truc, une méthode ? Et le déclic n'était pas encore venu. Et c'était pareil pour moi avec la chimie. J'ai dû l'apprendre pendant deux ans, et puis du jour au lendemain, le tableau périodique est devenu parfaitement logique. J'avais 16 ans à l'époque. Et je me souviens avoir pensé : oh la la, mais c'est la chose la plus simple du monde. Je n'arrive pas à croire que je n'ai pas compris ça pendant deux ans. Et puis l'examen a été une formalité, parce que je me disais que toutes les réponses étaient dans le tableau périodique. Il suffisait de faire ton petit... tout s'était synchronisé dans mon cerveau. Et c'était aussi intéressant de parler avec des gens de ce moment de déclic. Et Rebecca, que tu connais peut-être, du parcours Unison sur Exercism, je lui ai demandé, parce qu'elle a fait des études de littérature anglaise. Et je lui ai demandé : comment es-tu passée de la littérature anglaise à la programmation ? Et quelle méthode utilisais-tu mentalement pour conceptualiser ce changement ? Et elle disait qu'elle imaginait le programme qu'elle écrivait comme une histoire, un récit avec un protagoniste, et que les fonctions étaient des personnages, etc. Et je me suis dit : oh, wow, c'est vraiment intéressant. Je n'y aurais jamais pensé de cette façon. Non, c'est vraiment...

Franziska : Oui. Mais ça rejoint ce qu'on disait à propos des commentaires, non ? Tu écris avant le code. C'est exactement ça : tu racontes d'abord l'histoire, et ensuite tu écris le code qui va avec.

Jonathan : C'est vraiment cool que tu aies mentionné ça, parce que je crois que réaliser qu'en fait, j'écris une histoire dans mes commentaires... je vais garder ça en tête, c'est sûr. Non.

Franziska : Et encore une chose sur ce sujet : il y a eu des études sur les gens qui sont doués en programmation, etc., et on a découvert que les compétences verbales, par exemple le nombre de mots que tu connais, etc., jouent un grand rôle là-dedans. Par exemple, nommer les choses est toujours présenté comme difficile en programmation. Donc si tu es doué pour trouver les bons mots qui décrivent ce dont tu t'occupes, ton code s'améliore beaucoup. Donc ce n'est pas seulement une question de maths et de logique analytique. C'est aussi beaucoup une question d'avoir un bon rapport aux mots, ce à quoi on ne s'attend pas forcément au départ.

Jonathan : Non, c'est du langage, j'imagine, au bout du compte, ce qui est une réflexion intéressante que j'ai eue. Pour toi, tu es allemande de naissance, mais c'est ta langue en quelque sorte. Est-ce que tu développes maintenant chez Atlassian en anglais ? Et est-ce que tu l'étais déjà avant ? Parce que, je dirais que malheureusement, tout est en anglais. Et tu parles très bien anglais, mais tu as appris l'anglais à l'école, et puis la programmation, c'était tout en allemand, ou comment tu as appris tout ça ?

Franziska : Oui, surtout, j'ai eu la chance que la plupart des choses en programmation soient en anglais, et tous les commentaires étaient en anglais, etc. Ce n'est pas toujours le meilleur anglais, mais ça va. Pour moi, l'apprentissage de l'anglais... je n'ai jamais été bonne en anglais à l'école. Mais j'ai eu la chance, à l'université, de passer un an, une année d'échange, au Royaume-Uni. C'était vraiment l'immersion dans la langue. Et ensuite mon anglais s'est beaucoup amélioré. Après ça, c'était facile, mais avant, c'était vraiment mauvais. Et cette année, à vraiment apprendre la langue, m'a aussi aidée plus tard à pouvoir communiquer avec des collègues qui ne venaient pas d'Allemagne, etc. Et puis dans le... C'est clairement un facteur. Si l'anglais n'est pas ta langue maternelle, alors là encore, c'est plus difficile de te battre pour le bon nom des choses, non ? Et nommer les choses, tu le fais à chaque ligne de code que tu écris, pas vrai ? Tu affectes toujours quelque chose à quelque chose, et tu dois nommer cette chose le mieux possible pour que le code soit clair.

Jonathan : Non, ça ne me semble pas si facile que ça pour les non-anglophones. Et je pense que ça va aussi commencer à évoluer. J'ai vu un article l'autre jour : l'Inde est l'espace tech qui connaît la croissance la plus rapide au monde en ce moment. Et l'anglais... qu'ils gardent l'anglais ou leurs dialectes locaux, dont je sais qu'il y en a beaucoup en Inde. C'est juste intéressant d'y réfléchir, de réfléchir à tout ça. On approche de l'heure. J'ai vraiment adoré cette conversation. J'ai une dernière question pour toi, Franziska. Et là, c'est à toi de faire une recommandation à la communauté Exercism. Quelle serait ta recommandation ? Ça peut être n'importe quoi : un plat à essayer, une balade à faire, ce que tu veux recommander à la communauté. Quelle serait ta recommandation pour la communauté Exercism cette semaine ?

Franziska : Oui, je reviens au thème de la productivité dont j'ai parlé dans l'opinion impopulaire. Ma recommandation serait : prends une pause, regarde d'une traite cette série Netflix que tu as toujours voulu regarder, peu importe. En général, les gens sont très concentrés sur le fait d'être productifs toute la journée. Et ce n'est pas bon pour ton cerveau. Ce n'est pas bon pour ton cerveau de s'optimiser à ce point ; ton cerveau, pour être performant au travail, pour être créatif, etc., a besoin de pauses, et c'est pendant ces pauses qu'il fait son travail de fond. Et puis, rester assis sur le canapé à regarder tranquillement une série, ou peu importe, c'est bien. C'est une bonne chose à faire : laisser ton cerveau un peu de temps pour faire son truc en arrière-plan. Et je pense que prendre des pauses, s'accorder du temps, c'est sous-estimé. Donc ce serait ma recommandation : ne culpabilise pas de prendre des pauses et de te détendre.

Jonathan : Cool. Non, j'aime beaucoup. Eh bien, tout le monde, la recommandation, le conseil de la semaine, c'est ça, de la part de Franziska. Alors Franziska, merci beaucoup pour ton temps, pour tout ce que tu apportes à Exercism, pour toute la réflexion et l'engagement que tu as envers la communauté. Je sais que tu t'es énormément impliquée dans Exercism, pour l'améliorer et l'aider, et on t'en est vraiment reconnaissants. Je voulais juste te dire merci, et merci pour ton temps ce matin. Un jour férié où tu aurais pu être dehors à faire la fête ou à t'amuser. Et tu nous as offert ton temps, donc on apprécie énormément. Je suis resté en ligne après avoir arrêté l'enregistrement, mais je voulais juste te remercier beaucoup, et voilà, passe une très bonne fin de journée. Cool.

Franziska : Merci de m'avoir invitée.