Afleveringen
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Louis:
"On a un sujet qui pop en rétrospective sur l'équilibre entre temps de dev et review qui fonctionne pas trÚs bien chez nous. L'équipe est relativement jeune, composée de 5-6 devs et 1 super PO arrivé il y a peu. ConcrÚtement les tickets restent ouverts trop longtemps et trop de tickets ouverts en parallÚle⊠Avez-vous des pistes à proposer pour nous aider à trouver le bon équilibre ?"
Ăpisode enregistrĂ© en Octobre 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Joseph:
"Je dois faire un dossier Ă chaque fois pour obtenir la promotion dâun membre de mon Ă©quipe. Ce dossier est soumis Ă un comitĂ© qui va dĂ©terminer quels sont les personnes qui vont ĂȘtre promues ou non.
Un membre de mon Ă©quipe opĂšre dĂ©jĂ au niveau supĂ©rieur mais sâest vu refuser une promotion car les Ă©lĂ©ments du dossier ne sont pas assez âdĂ©monstratifsâ de sa valeur. En particulier câest un solide contributeur individuel mais le comitĂ© sâattend Ă ce quâun dĂ©veloppeur aie un impact âmultiplicateurâ (oui le 10x engineerâŠ) sur les autres membres de lâĂ©quipe, et mĂȘme dâautres Ă©quipes.
Dâune part câest assez compliquĂ© de trouver un projet sur lequel illustrer ces compĂ©tences du fait du scope de notre Ă©quipe mais aussi la personne a du mal Ă tracker son travail (rĂ©sout des taches sans passer par jira, skip la phase de doc, etc) ce qui rend la tĂąche de âdĂ©montrerâ sa valeur complexe.
Par ailleurs jâai vu des gens briller dans la maniĂšre de dĂ©montrer leur impact malgrĂ© des contributions particuliĂšrement limitĂ©es. Jâen viens Ă penser que âdĂ©montrerâ sa valeur est une compĂ©tence - et radicalement differente que celle de gĂ©nĂ©rer de la valeur - mais pourtant essentielle pour la progression de carriĂšre.
Que me recommandez-vous pour 1- identifier les sujets sur lesquels se mettre en avant, et 2- comment prĂ©senter ses achievements sans avoir lâair de âbrag de lâairâ (comme jâai pu aussi le voir par ailleurs)."
Ăpisode enregistrĂ© en Octobre 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Zijn er afleveringen die ontbreken?
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Pierre:
"Hello,
Je suis tech lead / manager d'une petite Ă©quipe (1 dev senior, 3 devs juniors + moi-mĂȘme) qui travaille sur un projet qui fait appel Ă de nombreuses "nouvelles technologies".
Les besoins du projet nous obligent souvent Ă nous pencher sur des sujets dont les solutions ne sont pas Ă©videntes ni directes, et nĂ©cessitent souvent un travail de R&D pour rechercher la meilleure solution, et parfois mĂȘme tout simplement pour vĂ©rifier la faisabilitĂ© ou non d'une fonctionnalitĂ©. Il arrive donc rĂ©guliĂšrement qu'un travail de plusieurs jours soit stoppĂ© car la piste explorĂ©e s'avĂšre ĂȘtre une mauvaise piste et il faut alors rĂ©orienter les recherches.
L'Ă©quipe a grossi trĂšs rĂ©cemment, et est devenue trĂšs jeune, tous les juniors ont Ă©tĂ© recrutĂ©s en sortie d'Ă©cole. J'ai justement Ă©normĂ©ment de mal Ă piloter ces juniors : j'ai remarquĂ© qu'ils me vouent une confiance presqu'aveugle et ont tendance Ă assez peu remettre en question les choix techniques ou Ă appliquer les suggestions proposĂ©es lors des revues de code sans rĂ©flĂ©chir Ă leur pertinence. Ils ont Ă©galement du mal Ă accepter que je nâai moi-mĂȘme pas la solution en tĂȘte et que leur boulot est justement dâexplorer pour la trouver.
De plus, au moindre échec (tentative d'utilisation d'une technologie qui ne répond finalement pas au besoin, difficultés à trouver une solution technique, etc.), la démotivation se fait rapidement sentir et l'effort pour remotiver l'équipe est considérable.
Cela pose pas mal de problĂšmes car Ă cause de cela, ils ont du mal Ă aller expĂ©rimenter et chercher des solutions d'eux-mĂȘme. Les daily meetings aident un peu dans le sens oĂč ils peuvent rapidement exposer leurs points de blocage, mais jâai remarquĂ© que cela avait introduit un effet secondaire : plutĂŽt que de passer un peu plus de temps Ă rechercher une solution, ils peuvent attendre le daily meeting suivant pour appeler Ă lâaide, et cela finit par induire Ă©normĂ©ment de temps d'accompagnement pour mon senior et moi, qui sommes impactĂ©s sur nos propres tĂąches, et cela peut entraĂźner des retards de shipping.
Pourtant, j'essaye de leur enseigner au maximum l'autonomie, et je m'assure que les objectifs sont clairs pour tout le monde et que les tĂąches sont les moins ambigĂŒes possibles.
Ma question est donc la suivante : comment puis-je aider au maximum la prise d'autonomie de mes dĂ©veloppeurs juniors, qu'ils montent en compĂ©tence et surtout qu'ils gardent la motivation mĂȘme aprĂšs des « Ă©checs », qui sont inhĂ©rents Ă notre projet ?"
Ăpisode enregistrĂ© en Octobre 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Robert, a.k.a. Dark Nounours:
"Comment faire comprendre aux gens que les architectes ne sont pas lĂ pour nous dire comment coder ?
Jâai lâimpression que câest flou le mĂ©tier dâarchitecte. Perso jâaime bien la comparaison avec lâarchitecte dâurbanisation. Il est lĂ pour que ta maison sâinsĂšre correctement dans le paysage pas pour te dire comment dĂ©corer ton intĂ©rieur. Mais je me trompe peut ĂȘtre?
Sinon bravo pour votre podcast il est fun (et intéressant)"
Ăpisode enregistrĂ© en Septembre 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Robert, a.k.a. Dark Nounours:
"Ă chaque introduction de nouveautĂ© (concept, nouvelle feature dâune techno) comment Ă©viter dâĂȘtre constamment face Ă une rĂ©ticence au changement ? Je trouve ça incroyable de se contenter de ses acquis surtout dans notre mĂ©tier. Je trouve ça surtout usant pour moi qui aime partager."
Ăpisode enregistrĂ© en Septembre 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Kelly:
"Nous rencontrons des problĂšmes dans ma boite.
Le customer service est objectivé en nombre de tickets à résoudre (entre autres).
Le problĂšme est le suivant : nous ne contrĂŽlons pas le nombre de tickets entrants et quand il n'y a pas de bugs, il n'y a pas vraiment beaucoup de tickets.
Si le nombre de ticket à faire n'est pas fait, l'agent du customer service ne bénéficie pas de son salaire variable (10% du salaire fixe).
Cela crée de grosses frustrations et aprÚs plusieurs discussions avec la direction, le CSE, les syndicats, le CS ne réussit pas à modifier ces objectifs.
Cela crée : des personnes qui se connectent réguliÚrement à 5h du matin pour pouvoir faire les tickets tombés dans le backlog le soir.
Le reste de l'Ă©quipe qui se connecte pendant les business hours n'a pas de quoi faire son objectif.
RĂ©sultat : burn outs, arrĂȘts maladie, compĂ©tition malsaine, et tout ce qui s'en suit.
Deux questions, comment faire pour ouvrir la communication et obtenir gain de cause ? et, quelles missions donner à des membres du CS de façon à changer les KPIs de maniÚre intelligente ? Merci :)"
Ăpisode enregistrĂ© en Juillet 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Sachi:
"Je bosse pour une ESN depuis un an et j'ai passé une grosse partie de mon temps en Inter-contrat. Je me suis naturellement dis que ce serait intéressant de Monter / Contribuer à des projets Open Source. Mais quand j'en ai parler avec mes collÚgues, ils étaient moyen chaud à l'idée et les plus anciens de la boite disant que le directeur n'est pas super fan vis à vis du fait de "travailler pour les autres" sachant que l'on utilise des technos open source dans nos projets. Mais du coup je sais pas vraiment quoi faire. Je suis sur 7 mois d'inter contrant et à part occasionnellement améliorer le socle, je fais pas grand chose."
Ăpisode enregistrĂ© en Juillet 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Tanguy:
"Mon Ă©quipe travaille Ă 80% en remote et un de mes collĂšgues, le tech lead mais qui est trĂšs jeune (et qui ne lead pas beaucoup, peut ĂȘtre liĂ©), a pris la fĂącheuse habitude lors de nombreuses visio meet, d'avoir la cam et le son coupĂ©.
Quand il ne s'agit pas d'un sujet Ă lui, il n'intervient pas du tout (mĂȘme pas un mot) et quand on lui demande son avis, il rĂ©pond toujours mais il faut souvent rĂ©pĂ©ter la question ou redonner le context => On a clairement l'impression qu'il fait autre chose en mĂȘme temps.
RĂ©cemment il est mĂȘme arrivĂ© qu'il dĂ©croche en plein mob programming (en physique) et qu'il se mette Ă traiter un autre sujet dans son coin. Quand le team manager le remarque, il se justifie qu'il a Ă©tĂ© sollicitĂ© par mail pour un bug Ă rĂ©soudre... et c'est comme si c'Ă©tait normal.
MĂȘme en faisant du pair-programming avec lui, je me suis parfois retrouvĂ© Ă coder seul et sentir qu'il a dĂ©crochĂ© de son cĂŽtĂ© et qu'il traite d'autres sujets.
Je trouve ça de plus en plus désagréable en plus de trouver ça personnellement impoli. Je ne me sens pas du tout de lui reprocher directement, ni d'escalader auprÚs du team manager. Il y a une bonne ambiance dans l'équipe et je ne voudrai pas casser ça.
Est-ce que je me prends la tĂȘte pour rien ? Est-ce que c'est normal de se dire qu'il a d'autres sujets Ă traiter et puis j'avance dans mon coin ?"
Ăpisode enregistrĂ© en Mai 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Robert:
"Je suis manager d'une Ă©quipe oĂč je manage plusieurs devs. L'un d'entre eux me pose des problĂšmes de productivitĂ©. Il fait du code trĂšs propre, mais il est trop perfectionniste et Ă beaucoup de mal Ă dĂ©livrer. Il sâintĂ©resse Ă©normĂ©ment aux problĂ©matiques d'architectures logiciels, au clean code et Ă toutes les bonnes pratiques, ce qui en soit est trĂšs bien. Mais j'ai l'impression qu'allier ceci Ă son perfectionnisme l'empĂȘche de mener Ă bien les tĂąches qui lui sont attribuĂ©es. Il passe Ă©normĂ©ment de temps Ă prĂ©parer ses dĂ©veloppements avant de les dĂ©buter, Ă chercher la meilleure façon de le faire, et durant le dev il revient rĂ©guliĂšrement sur ce qui a Ă©tĂ© fait pour tenter de l'amĂ©liorer. RĂ©guliĂšrement il fini par produire des mini usines Ă gaz pour des choses trĂšs simples aprĂšs un temps de dev qui dĂ©passe trĂšs largement les estimations les plus pessimistes. Cela pose Ă©galement des problĂšmes quand d'autres membres de l'Ă©quipe collaborent avec lui sur un projet.Il m'est mĂȘme arrivĂ© de faire une choses que je dĂ©teste: reprendre from scratch certaines tĂąches pour sauver les meubles et qu'elles soient terminĂ©es pas trop hors dĂ©lais. Ce qui fait que je sais que les dĂ©lais en question Ă©taient largement tenables ^^
Ma question est donc: comment réussir à transformer un développeur trop académique en développeur plus orienté vers les besoins d'une entreprise ? Pour l'instant mes tentatives y ont échoué."
Ăpisode enregistrĂ© en Mai 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Stéphane:
"Je suis manager et je n'arrive pas Ă parler du tabou de la performance avec mes Ă©quipes de devs. Comment aborder le sujet ? Est-ce que c'est utile de mesurer la perf d'un dev/Ă©quipe ? Comment mesurer ?"
Ăpisode enregistrĂ© en Mai 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Dan:
"Comment amener plus de diversité culturelle dans les équipes lors des recrutements ?"
Ăpisode enregistrĂ© en Mars 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question d'Elodie:
"Dans une petite entreprise, l'habitude a été prise de manger en regardant la télé/JT et en discutant. Des nouveaux arrivants trouvent que ça fait mauvaise ambiance, et qu'il n'y a pas de cohésion d'équipes. Et en effet, les gens mangent devant la télé en se parlant à peine, ce qui n'était pas le cas avant. Devrait-on se débarrasser de la télé pour "forcer" les gens à se parler ? Comment améliorer cette ambiance/cette cohésion d'équipe ?"
Ăpisode enregistrĂ© en Mars 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Ernst:
"Mon CEO pratique allĂšgrement le mansplaining, que faire ?
Contexte: Je suis actuellement EM et ai au dessus de moi en terme hiĂ©rarchique le CEO. Quelque chose que j'ai notĂ© depuis bientĂŽt 6 mois est sa manie Ă "mansplain" avec mes collĂšgues fĂ©minins, et une en particulier. Cette personne est au mĂȘme niveau hiĂ©rarchique que moi et se fait systĂ©matiquement interrompre au milieu de son argumentaire par le CEO. Il lui explique Ă©galement rĂ©guliĂšrement son job (dans un setup avec plusieurs personnes dans le meeting je prĂ©cise - nice) et insidieusement Ă quelle point elle ne le fait pas bien. Si je caricature un peu (mais pas tant que ça) notre CEO a une tendance Ă ĂȘtre "un bro" dans sa maniĂšre d'ĂȘtre. Relativement machiste, valorise les interactions musclĂ©es ou il faut montrer que l'on est fort. Donc particulierement cette personne qui est une femme plutot reservĂ©e je note des probleme: elle a des excellents points mais son argumentaire est inaudible. Je ne pense pas que la solution soit de me mettre moi dans une position de "rescuer" et de la shield par rapport au CEO. Je pense Ă©galement potentiellement Ă en parler Ă la Head of People. Mais qu'en pensez-vous, vous?"
Ăpisode enregistrĂ© en Mars 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Steeve:
"Petite question de responsabilité, de hiérarchie et de tact.
Je tombe sur un fichier oĂč je trouve des modifications rĂ©centes complĂštement foutraques, plusieurs v-if/v-else/v-show appliquĂ©s de maniĂšre croisĂ©e sur les mĂȘmes Ă©lĂ©ments de template, crĂ©ant un bazar illisible et potentiellement boguĂ©, bref, une vĂ©ritable satanerie qui fait pleurer du sang.Rapidement je me rends compte grĂące Ă gitLens que les modifs ont Ă©tĂ© faites il y a une semaine par mon CTO đ¶.Qu'est-ce que je fais ?
Je fais l'andouille et signale Ă l'Ă©quipe que le code n'est pas correct sur cette feature comme si je n'avais pas vu qui en Ă©tait l'auteur au risque de l'afficher ?Je fais l'avenger et prends la responsabilitĂ© de corriger le code en douce pour Ă©pargner son Ă©go au risque de perdre du temps sur ma propre tĂąche ou de causer moi-mĂȘme un bug en voulant corriger ?Je fais l'adulte et vais le voir pour lui dire que la feature n'est pas bien codĂ©e et qu'il faut la modifier au risque de le vexer et de remettre en question ses compĂ©tences ?Je fais l'autruche et passe mon chemin au risque de laisser des bugs partir en prod ?"
Ăpisode enregistrĂ© en Mars 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Jean-Michel:
"Débarquer dans une nouvelle entreprise est souvent une épreuve. On est submergé d'informations de partout, tant sur le contexte de la boite, que sur les personnes, leurs pratiques, les outils utilisés, les mots de passe, les pratiques, ....Et la frustration parfois de rester beaucoup trop longtemps improductifs.
Que faire et ne pas faire dans ce scénario, tant de la part de la personne qui arrive que de la part de la boite qui l'accueille ?"
Ăpisode enregistrĂ© en Mars 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Judith:
"Bonjour. Voici la situation: une Ă©quipe de dev de 5 personnes + 1 tech lead. Lâun de dev a mis en place un « daily technique » (rĂ©union Google meet) aprĂšs chaque daily lors duquel on se retrouve entre devs pour parler de problĂšmes plus techniques histoire de ne pas encombrer le daily dâĂ©quipe. Le tech lead Ă©tait Ă©videmment invitĂ© mais il nâest jamais venu. JâapprĂ©ciais beaucoup ces moments dâentre aide. Mais un bon jour le tech lead a supprimĂ© de lâagenda le daily tech en disant que ce daily nâavait pas de raison dâĂȘtre puisquâil y a le daily principal. Pas de dialogue, juste une suppression. Personne nâa protestĂ©. Pourtant, je pense que tout le monde apprĂ©ciait ce moment qui faisait aussi team building. Je pense que nous pourrions continuer mais ça a crĂ©Ă© un froid et nous nâosons plus⊠Je dois avouer que le tech lead me met mal Ă lâaise et que je nâoserais pas aborder le sujet avec lui de peur de lâagacer. (NB: pas de rĂ©tro pour tous, seul le tech lead sây rend) Lâentre aide continue mais dĂ©sormais nous nous posons des questions en privĂ© (en one-to-one, sinon ça voudrait dire crĂ©er un channel sans le tech lead, on ne se le permettrait pas). Que pensez vous de cette situation? Comment faire pour remettre en place ces moments de partage sans crĂ©er de drama?"
Ăpisode enregistrĂ© en Mars 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question d'un auditeur anonyme:
"Hello,
Je suis dev et je viens d'arriver il y a quelques semaines dans une startup qui existe depuis 2 ans. Durant les Daily, mon CTO a tendance Ă s'Ă©parpiller et Ă sauter d'un sujet Ă l'autre, si bien que parfois on en oublie de lui communiquer certaines infos importantes (bug sur lequel on a pas pu avancer, feature qu'on a pas bien comprise).
Hier l'autre dev n'a mĂȘme pas eu le temps de faire sa propre daily. Je n'ose pas lui demander d'aller droit au but ou de lui proposer de voir certains points aprĂšs le call (histoire de ne pas retarder l'autre dev). Il est vrai aussi que cet Ă©parpillage m'aide Ă dĂ©couvrir d'autres aspects de notre tech, donc ça a quand mĂȘme de l'intĂ©rĂȘt.
Comment puis-je lui demander de ne pas s'Ă©parpiller, et d'aller droit au but, tout en conservant la super bonne entente qui rĂšgne entre nous tous ?
Merci pour votre super travail, c'est top !"
Ăpisode enregistrĂ© en Mars 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question d'Audrey:
"Bonjour,
En tant que développeuse, je me suis toujours efforcée de suivre les meilleures pratiques, en m'assurant d'écrire du code propre et bien organisé. Cependant mes collÚgues ne partagent pas cette rigueur. Ils ont tendance à écrire du code de maniÚre désordonnée, sans se soucier des standards de qualité, ce qui me fait souvent paraitre lente lorsque je dois éditer leur code car il est peu maintenable.
Cette situation est source de frustration pour moi. Non seulement elle rallonge mon temps de travail, car je dois souvent retravailler leur code lorsque je dois le modifier pour ajouter une feature, mais elle me met également dans une position inconfortable. Je crains que mes propositions ne soient perçues comme une critique personnelle, ce qui pourrait nuire à l'ambiance de travail et à mes relations avec mes collÚgues. De plus ce n'est absolument pas récompensant car mon code fonctionne bien, et le leur bug réguliÚrement, et de plus ils en sont récompensés car ils résolvent plus d'incidents de prod que moi...
Je suis convaincue que le maintien d'un code propre est essentiel, non seulement pour l'efficacitĂ© du dĂ©veloppement, mais aussi pour la pĂ©rennitĂ© du projet sur le long terme. Cependant, je me sens impuissante face Ă cette culture de l'Ă -peu-prĂšs qui semble ne pas ĂȘtre simplement limitĂ©e Ă mon Ă©quipe mais dans l'ensemble du monde du dĂ©veloppement.
Auriez-vous des conseils pour m'aider à naviguer dans cette situation difficile ? Je suis pas seulement à la recherche de stratégies pour promouvoir le clean code mais aussi pour, moi aussi trouver l'état d'esprit me permettant de développer des solutions quick-and-dirty et progresser dans une codebase désorganisée.
Merci pour votre aide !"
Ăpisode enregistrĂ© en Janvier 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Jules:
"Hello !
Je vous contacte car aprĂšs 15 ans d'experience dans la tech, j'ai toujours du mal Ă trouver confiance en moi. MĂȘme en Ă©tant rationnellement confiant dans mes experiences et en quantifiant mes compĂ©tences j'ai tout de mĂȘme du mal Ă trouver la confiance de briguer de meilleurs postes ou promouvoir mon travail. Cela peut aussi poser souci dans mon quotidien car lorsque je suis confrontĂ© aux autres opinions des dĂ©veloppeurs j'ai tendances Ă rapidement lĂącher l'affaire car
1- je n'aime pas perdre du temps à débattre, je suis focus sur produire de la valeur
2- je trouve que les ingĂ©nieurs ont une tendance Ă ĂȘtre trĂšs sĂ»rs d'eux, parfois pĂ©dant. Je suis certain que souvent ce n'est pas forcĂ©ment pour des bonnes raisons mais cela me fait douter de moi car personnellement j'essaie d'avoir une Ă©coute active et comprendre les points des autres mais je constate rarement ce comportement face Ă moi.
Comment puis-je retrouver confiance et m'affirmer dans le milieu professionnel ?
Merci !"
Ăpisode enregistrĂ© en Janvier 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
-
Cette semaine, dans le SAV de la Tech, on répond à la question de Mickael:
"Jâai 43 ans et je suis toujours dĂ©veloppeur. Jâaime toujours coder, par contre je me sens parfois un peu Ă la traine par rapport Ă mes collĂšgues plus jeunes, au moins en termes dâĂ©nergie et de motivation Ă tester les derniĂšres technos. Et, en sachant que mon salaire Ă©volue avec lâexpĂ©rience, jâai peur quâun jour plus personne ne veuille mâembaucher sur ce roleâŠ
Est-ce que jâai intĂ©rĂȘt Ă changer de rĂŽle ? Ă me former sur quelque chose en particulier pour rester âdans la courseâ ?
Merci dâavance pour vos conseils !"
Ăpisode enregistrĂ© en Janvier 2024.
Crédits musique: "Guess Again", provided by https://slip.stream
- Laat meer zien
