Transcription

• Sylvain

  Bonjour à toutes et à tous et bienvenue dans ce nouvel épisode du podcast PunkinDev. Aujourd'hui, je reçois quelqu'un que j'ai envie de recevoir depuis hyper longtemps sur le podcast et je suis ravi de t'avoir avec moi. Bonjour, Shirley, comment tu vas ?

• Shirley

  Ça va bien, et toi ? Merci beaucoup.

• Sylvain

  Ça va super bien. Avant de se lancer sur le sujet, est-ce que tu voudrais bien présenter qui tu es et ce que tu fais au quotidien pour les rares personnes qui oseraient ne pas te connaître ?

• Shirley

  Alors moi je suis recruteuse informatique depuis pas mal de temps maintenant. Je recrute principalement des développeurs et des développeuses. Et depuis maintenant trois ans, je suis agent de carrière. Donc ça c'est un mot très stylé en fait, pour tout simplement dire que je suis le poil emploi du luxe. J'accompagne les gens dans leur carrière, que ce soit autour du droit du travail, autour du sourcing d'opportunités. Ça peut être aussi sur la négociation, donc vraiment toute la chaîne avant la prise de poste, pendant le poste aussi en mode délégué du personnel externe. Je peux aider sur des discussions avec son manager, sur des négociations sur les augmentations, etc. Et la sortie de poste, c'est-à-dire le moment où il faut signer la fameuse rupture conventionnelle ou parfois même il faut aller sur des trucs assez moches comme les licenciements abusifs. Voilà, globalement le spectre de mon intervention. Et ce sont les individus mes clients alors que quand je suis recruteuse ce sont les entreprises les clients.

• Sylvain

  Merci pour ce petit tour d'horizon si je t'ai proposé de passer dans le podcast aujourd'hui c'est pour causer d'un sujet, il y a eu plusieurs épisodes sur le podcast ces derniers mois où je parle de ça s'appelle journal d'un dev.net dans un monde Java . Et je parle de mon récent changement de stack, où je suis passé, après 15 ans de .NET, je suis passé sur un projet Java. Et cette transition de stack m'a amené plein de questions. Et en discutant avec les gens, j'ai l'impression que ça amenait encore plus de questions chez d'autres gens. Comme si le fait de changer de stack comme ça était un truc absolument rarissime et exceptionnel. Alors que j'ai l'impression que pas tant que ça. Et j'avais envie d'avoir un petit peu un retour de quelqu'un qui croise potentiellement beaucoup plus de profils variés que moi en la personne de Shirley. Et tu es là pour ça, pour nous faire profiter de tes lumières et de ton XP, de ton level en termes de recrutement. Donc la première question, j'ai envie de te dire, est-ce que toi, c'est des cas que tu vois souvent ? Des gens qui cherchent à changer de stack en changeant de poste ou en interne ? Ou des gens qui ont accepté des postes ? d'une stack qui n'était pas forcément la leur. C'est un truc que tu vois, que tu as déjà vu, que tu vois de temps en temps ?

• Shirley

  Alors, j'ai déjà vu et je vois de temps en temps, mais pas non plus énormément. Et je remarque que ce sont souvent des individus qui ont une vraie culture craft. Je vais m'expliquer. Ce terme, il est un peu galvaudé, utilisé à toutes les sauces, mais qui ne voit pas la technologie comme une fin en soi, mais comme un moyen au service des utilisateurs. C'est-à-dire que... ils vont l'utiliser en fonction d'un besoin exprimé en amont, en se disant, là, si j'arrive dans cette structure et que l'existant veut cette technologie-là, je vais m'adapter à cette technologie-là. Si le besoin change et que le produit évolue et qu'il faut passer à un langage qui permet beaucoup plus de scalabilité, eh bien, j'irai sur le langage qui veut la scalabilité. Donc, c'est quelque part le client-driven. souhait de changement technologique, je ne sais pas comment dire ça mais il y a vraiment cette ouverture au langage des d'un sang où ils ont réussi quelque part, et là c'est presque une réflexion psychologique, philosophique à se détacher de la stack, c'est-à-dire que je remarque un petit peu trop dans le monde de la tech qu'il y a un peu ce côté non dissociatif entre ce que je suis et ce que je code en fait, et même ça se voit dans la manière dont les personnes se présentent la manière dont les personnes écrivent leurs titres de postes, développeurs Java développeurs PHP, développeurs C++ et j'ai l'impression que ces termes-là, cette technologie les a enfermés dans une bulle de présentation et même de conscience de soi, c'est-à-dire qu'au final ils n'arrivent pas à s'en extraire. J'ai l'impression que le monde craft, encore une fois, ce terme, il y a du bon, du moins bon, mais a permis cette dissociation entre l'intérêt l'envie de coder et ce pourquoi je le fais en fait. Et donc du coup, il y a beaucoup de personnes qui arrivent à quelque part à se détacher du langage parce qu'ils savent, encore une fois, que la technologie n'est pas une forme en soi. Ils savent s'adapter au marché en fait. Ils savent s'adapter aux clients, aux besoins. Et donc, ils arrivent, je trouve, plus facilement à comprendre quelque part l'intérêt du langage et comment je dois l'utiliser, les pourquoi quelque part du langage, plutôt qu'il faut cette technologie sur l'étagère. C'est toujours ce que j'ai appris à faire, donc il faut le mettre en place pour ce projet client. C'est plus une façon de penser la tech, que j'observe dans les différences entre les personnes qui sont fermées dans une techno et ceux qui se disent « Why not ? Allez hop, on change de technologie. »

• Sylvain

  C'est intéressant ce que tu dis, je me retrouve là-dedans. Parce que c'est précisément la démarche que j'ai eue, moi, de mettre en avant plus de... plus de craft sur mon profil au moment où j'ai changé de stack, puisqu'on cherchait des gens qui avaient une appétence craft et une envie de partager ça. Et je n'avais pas la stack adéquate, mais ça n'a pas été grave. Et au final, je me suis rendu compte que, de un, ce n'était pas si compliqué que ça de changer de stack. Il y a des choses compliquées, mais j'en ai parlé dans les épisodes précédents. Il n'y a pas que le langage, il y a toute la stack étendue, tout l'écosystème qui peut prendre un certain temps à apprendre et à domestiquer, si je puis dire. Mais au final, c'est plus ces compétences-là qui ont été pertinentes. Donc oui, j'ai discuté de ça en meet-up avec des gens qui avaient tendance à confirmer ça sans forcément que parler de craft. Il m'a un peu parlé de pratique et de choc de connaissances de base. Je discutais avec, je me permets de le citer puisqu'il a dit des choses plutôt sympas, avec Antoine Caron qui est un speaker lyonnais, qui est un dev qui vient plus du monde du web. Et j'ai l'impression que son propos était tourné autour de, pour le monde du web, on s'en fout que tu sois expert de vue ou de React ou d'Angular ou de je ne sais quel framework à la mode. si t'as compris les fondamentaux du web c'est pas grave tu vas pouvoir apprendre donc sans être forcément orienté vers le craft mais alors quelque part c'est du craft aussi peut-être d'avoir bien ses fondamentaux et les pratiques générales associées à un écosystème, là c'est du web c'est vrai que moi j'ai plus une appétence back-end, faut pas me laisser faire du front c'est pas beau euh Mais voilà. Toi, les profils que tu as vus, c'est des gens que tu as pu accompagner ou c'est juste que tu as été témoin de leurs changements technos ou de leur progression là-dessus ?

• Shirley

  Alors, les deux, dans le sens où j'ai des personnes qui, à un moment donné, dans leur parcours, m'ont dit, voilà, moi, j'ai expérimenté plusieurs langages, j'ai bien aimé l'annonce qui dit... l'annonce en recrutement que je proposais, mais évidemment qui dit, on s'en fie du langage, le principal c'est des personnes qui sont capables de s'adapter à l'environnement, etc. Et puis des personnes que j'ai accompagnées aussi dans le discours, c'est-à-dire qu'elles avaient envie d'explorer d'autres technologies. Alors, sur ce point-là, j'aide vraiment les individus à se poser trois questions. Déjà, quel est ton format ? CDI ou freelance ? C'est tout bête, mais des fois il peut y avoir quand même des petites nuances. Dans le sens où le freelancing, et même ça se traduit aussi dans le monde de la société de prestation, on attend beaucoup d'hyperspécialisation. On attend que la personne soit opérationnelle immédiatement, que le TJ soit justifié. C'est-à-dire que si tu as fait par exemple 15 ans de Java et que derrière tu demandes un TJ à 1000, c'est OK. Si tu dis OK, je vais basculer sur du .NET alors que je suis tout nouveau sur le truc. on va peut-être moins comprendre pourquoi un aussi fort TG. On se dit, tiens, il y a quand même une marge de progression, d'apprentissage, donc peut-être qu'on va baisser le TG. Donc les personnes s'enferment aussi en fonction du statut. C'est le marché un petit peu qui veut ça. Et c'est aussi les individus qui s'enferment pour pouvoir garder leur niveau de TG. Je ne sais pas si c'est clair ce que je raconte, mais il y a un petit peu ça. Et puis, il y a aussi le domaine. C'est tout bête, mais en fonction de là où tu veux aller, il n'y a pas forcément les mêmes attentes. Par exemple, si tu vas vraiment sur un monde très data, Il y a Python, par exemple. Si tu vas beaucoup plus sur du dev embarqué, c'est du C++. Si tu vas sur du mobile, il y a Kotlin. Même sur les sujets d'infra, il y a Go, par exemple. C'est intéressant aussi de se dire, à un moment donné, « Ok, toi, tu veux faire une bascule, mais non seulement où est-ce que tu veux aller, quel est ton format et pourquoi tu veux le faire ? » Et c'est vrai que, des fois, je remarque que les personnes, elles pourraient parfaitement le vendre si elles restent déjà dans un même écosystème. Tu vois ce que je veux dire ? Dans le sens où, par exemple, ça peut être l'écosystème data. Elles veulent apprendre un nouveau langage qui est Python alors qu'elles ont été sur Scala. C'est arrivé ça typiquement assez souvent, des personnes qui constatent que des missions Scala, il n'y en a quand même pas énormément en ce moment, même pratiquement plus. Python a pris vraiment le devant sur le marché de la data parce que c'est un langage très polyvalent et qui aujourd'hui fonctionne très très bien sur la data science et sur les problématiques autour de l'IA. Et donc Scala est arrivé à un stade où, bon, au final, il a été un petit peu parasité par ça. Donc dès l'instant où ton écosystème, c'est la data, si tu explores plein de langages et plein d'outils dans cet univers, j'ai envie de dire que c'est OK. Si ton écosystème, comme tu le disais, c'est le front-end, si tu explores plein de langages autour du front-end, c'est OK. Si ton écosystème, c'est l'infra et que tu dis, pourquoi pas aller chatouiller des problématiques autour d'AWS, autour du Go, peut-être autour du Java aussi, parce qu'il y a des sujets autour de la performance, j'ai envie de dire... ça c'est ok, mais il faut rester relativement cohérent par rapport à l'écosystème et moi j'ai vraiment aidé à accompagner des individus à quelque part s'extraire du langage à parler de cohérence en matière d'écosystème et donc du coup ça faisait plus transition, ça faisait presque suite logique il n'y a pas le côté je me suis reconverti et donc du coup tout de suite tu mets dans l'esprit de ton interlocuteur que soit t'es junior, que soit t'es débutant que soit du coup il faut apprendre tout de A à Z, alors que des fois non on est sur les mêmes paradigmes de langage ou sur les mêmes problématiques métiers, ou les mêmes problématiques de domaine. Et à partir de là, dès l'instant où tu arrives à le vendre comme ça, tu t'installes moins dans l'esprit de ton interlocuteur que tes débutants. Et j'ai donc aidé des personnes à vraiment travailler sur cette façon de se présenter, et cette façon de bien travailler le changement comme étant pas un changement de dingue, mais comme étant vraiment un changement presque positif, parce que c'est un changement qui s'adapte au marché. contraintes et aux attentes du marché aussi. Je ne sais pas si je suis claire.

• Sylvain

  Si, c'est très clair et ça résonne bien avec, quelque part, la démarche que j'ai essayé d'avoir. J'aurais dû chercher à te consulter quand j'ai préparé mes entretiens. Là-dessus, je m'étais mis deux axes. Déjà, j'ai réussi à avoir un entretien parce que, on va dire au coup de champ, c'est bonnes personnes qui font passer les CV et tout ça. Mais au moment de convaincre en entretien, je me suis dit qu'est-ce que je dois mettre en avant. Moi, je partais en étant freelance. Je savais que mon TJ allait baisser par rapport à ce que je pouvais exiger de mission historiquement que j'avais en dotnet. Je n'allais pas pouvoir demander la même chose et je me suis dit que ce n'était pas grave. Moi, j'ai un gain personnel à essayer cette nouvelle typologie de mission. Donc, je vais le faire. et je me suis dit d'une part il faut que je montre ce que j'ai comme plus value que le client n'a pas forcément en interne alors là pour le coup c'est un client qui cherchait quelqu'un qui soit plutôt qu'à aller en craft et qui a envie de partager moi qu'est-ce que j'ai en moi dans mon parcours qui me permet de dire ça bah ça me collait bien parce que je fais du podcast, je fais des confs j'aime bien raconter un peu tout ce que je sais, j'aime bien partager au maximum ça ça allait bien Mais en même temps, je n'allais pas passer complètement sous silence le fait que je ne connais pas la stack. C'était une stack Java, Spring, Oracle, Kafka, et c'est tout plein de trucs que je ne connaissais tellement pas. J'ai essayé d'être rassurant sur ce truc-là. Déjà, je suis arrivé en disant, Java, honnêtement, c'était mon premier langage quand j'étais à l'école. Derrière, je suis arrivé sur des projets .NET dès ma sortie de l'école. On m'a pas dit, mon dieu, tu connais pas .NET ? Non, on m'a dit, tu verras, C Sharp et Java, c'est un peu pareil. Il a beau s'être écoulé entre 15 et 20 ans, entre les deux, c'est toujours à peu près vrai. Repasser de C Sharp à Java, c'est pas bien compliqué. Je l'ai raconté, ça, en vrai, j'ai plus galéré sur les outils. Il est passé de Visual Studio à IntelliJ, il est raccourci clavier, tout ça, un peu l'enfer au quotidien. Donc j'ai essayé de rassurer là-dessus, et puis... Aussi de dire, effectivement, je ne passe pas sous silence que je ne connais pas. Il y a des trucs que je ne connais pas. Mais j'ai plus de 15 ans de métier. Je n'ai peut-être pas le cerveau aussi souple que les jeunes qui sortent d'école qui ont 25 ans. Mais même à 40 ans, je sais encore apprendre des trucs. Il y a des choses que je vais apprendre avec plus de facilité parce que j'ai les bases. Kafka, je ne connaissais pas. C'est un système de messaging. Avec de la synchronie, tout ça, j'ai eu des équivalents dans le monde .NET. Ok, j'ai compris comment ça marche. Les impléments ne sont pas les mêmes, mais ça marche.

• Shirley

  Je suis curieuse, tu as mis combien de temps pour finalement être clairement opérationnel entre .NET et Java ? Juste un message fort en disant que c'est possible en très peu de temps.

• Sylvain

  Alors, en sachant que je suis un très mauvais élève, du moment où la mission est acceptée, l'administratif et les calendriers se faisant, j'ai dû mettre un bon mois avant de rejoindre le projet. Si j'avais été un élève très sérieux, j'aurais utilisé l'Intelligi que j'avais installé localement et puis j'aurais fait plein de catap, plein d'exercices pour me familiariser. Je ne l'ai pas fait parce que pas le temps, parce que je suis un très mauvais élève. Donc si je prends le décompte à partir du moment où je suis arrivé sur le projet, combien de temps j'ai mis à être opérationnel ? Alors, en Java pur, si je prends que Java, que le langage, j'ai envie de dire tout de suite en fait, j'ai pas eu de transition. Java s'écrit vraiment comme c'est Sharp, là-dessus il n'y a pas de difficulté. Il y a 2-3 pouillèmes de syntaxe que j'avais déjà aperçus. Donc ça, ça a marché. Pour être autonome et fluente, j'allais dire, avec mon IDE, avec IntelliJ, là, c'est à ce qu'on ne plus s'en se mène. Il m'a quand même fallu 2, 3, 4 semaines pour désapprendre mes raccourcis clavier, rapprendre les nouveaux. Là-dessus, il y a du tooling à faire. J'ai installé un petit plugin qui permet de déconfier un truc à la souris. Ça affiche le raccourci clavier qu'on aurait pu utiliser. Donc ça, en 15 jours, pareil, c'est compensé. Et pour la plupart des briques de dev que j'utilise au quotidien, c'est de l'ordre de quelques jours à quelques semaines pour prendre en main. La vérité, ça fait plus d'un an que je suis sur cette mission. Il y a toujours des trucs que je ne sais pas, que je ne maîtrise pas à fond. J'ai priorisé. Il y a des trucs, ce n'est pas grave. Il y a des trucs, il faudrait que je bosse un peu plus dessus. J'ai un rôle plus de craft dans l'équipe. J'ai un tech lead qui, lui, est une encyclopédie technique. dès qu'il y a la moindre difficulté, purement technique, c'est vers cette personne que je vais me tourner. Et l'équipe va se tourner vers cette personne. Par contre, quand il y a des questions de est-ce que notre process, est-ce que notre TDD, il est propre ? Est-ce qu'on ne peut pas réfléchir à de l'archi, à des patterns à mettre en place ? C'est plus moi qu'on va venir voir. Et les rôles se dispatchent bien. Mais clairement, pour passer entre Java et .NET, l'un comme l'autre... Dans les deux sens, ça fonctionne. C'est une histoire de... Ça se compte en semaines, l'adaptation. On a eu, sur le projet aussi, on a eu deux autres profils. Un qui vient d'un monde plus PHP et qui a un peu de billes en Python. De ce que j'ai vu, son adaptation, c'est à peu près la même chose. Pourtant, les langages sont un poil plus éloignés. C'est quelqu'un qui a été opérationnel très très vite, en l'ordre de quelques semaines, voire même quelques jours, quand on a les bonnes pratiques en termes de PR et de mob programming, l'onboarding se passe très bien et ça va très vite. Et un autre qui a fait aussi le saut, qui vient d'un monde plutôt NUD, donc full JS, et qui s'y retrouve aussi très bien. Globalement, on est trois profils comme ça, être arrivés sur le projet, et à aucun moment, il n'y a quelqu'un qui a dit « Ouais, non, pas terrible quand même, ces gars-là, ils ne sont pas opérationnels. » Enfin, on avait tous des profils très crafteux, et on a appris très vite la stack.

• Shirley

  Donc tu vois, ça c'est intéressant dans le sens où des fois, tu peux mettre des mois, je ne parle pas en semaines, mais des mois à chercher la bonne personne sur une stack qui est parfois complètement en décalage avec le marché. ou une stack qui est parfois en décalage avec les gens qu'il y a sur une région. Par exemple, il y a beaucoup de dotnet à Lyon, vous avez remarqué ? Peut-être que sur Paris, j'en sais rien, il y en a aussi, mais peut-être un peu moins. Mais tout ça pour dire que, je n'ai pas de chiffre sur ça, donc je ne vais pas dire de bêtises, mais ce que je veux dire, c'est que des fois, il peut y avoir un décalage entre ce que tu recherches et ce qu'il y a comme compétences sur le marché, et les entreprises s'obstinent à dire pendant tant de mois, il faut absolument que la personne ait tant d'années sur tel langage. Et ça met des mois et des mois et des mois. Après, je ne veux pas transposer ton cas à tout le monde, mais j'en suis quasiment certaine que des personnes qui ont les bons fondamentaux techniques, et je pense qu'il y en a beaucoup, ils sont capables d'apprendre le langage en quelques semaines. Tu vois, ils sont capables. Et donc moi, c'est ce que je dis aux entreprises. Je dis, ne regardez pas le langage. Ne regardez pas forcément Node, PHP. Regardez dans quel contexte a été utilisé le langage. Si ça rejoint. des éléments de contexte avec le vôtre, par exemple une marketplace, du fort trafic, des problématiques, je ne sais pas, de plug-in, d'apéisation, c'est trop rien. Si vous voyez que dans l'expérience, il y a des ressemblances quelque part de problématiques techniques, peut-être que ça a du sens de prendre une personne qui a fait un langage différent sur du PHP versus Node, par exemple, et regarder plutôt l'expertise, comment elle a été exploitée, et s'il y a des paradigmes de langage qui se ressemblent aussi un petit peu. le développement objet, le langage typé, etc. Et des fois, les personnes sont capables de dire « Ok, je veux bien voir ce profil qui n'est pas exactement dans notre stack, mais c'est vrai qu'à travers son expérience, j'ai pu constater qu'on était sur des logiques assez similaires de marketplace, etc. Donc je veux bien regarder. » Et des fois, ça marche très bien, parce qu'au final, les contraintes derrière technique sont souvent les mêmes. On n'est pas en train de réinventer la roue totalement non plus à chaque fois, et les personnes, comme tu dis, en quelques semaines, des fois... Ça roule, quoi. Et c'est déjà arrivé dans un contexte, typiquement, d'une personne qui avait fait du pur Java et qui est passée sur du Node, chez un de mes clients. Et il était sceptique au début, puis il m'a dit, bon, pourquoi pas ? Et puis, au final, ça a été après intégré dans l'entreprise. Donc, c'est vraiment comment, toi aussi, en tant que recruteur, c'est ça aussi, c'est comprendre le marché, les nuances. Le fait que les compétences, ce n'est pas juste un langage, pas juste des mots-clés, pas juste des cases à cocher, mais aussi derrière, est-ce que la personne a été impactante dans son histoire professionnelle ? Et aussi, est-ce que vos histoires peuvent se retrouver dans les contraintes au quotidien ? Et ça, ce n'est pas évident l'un comme l'autre. On s'enferme beaucoup dans les technos parce que ça rassure. c'est comme le petit doudou t'as ton petit doudou dans ton coeur c'est cette technologie là et les clients comme les candidats parfois se rassurent avec ce petit doudou technologique.

• Sylvain

  C'est le mot, 'doudou' j'allais le mettre il y en a qui prennent vraiment leur stack technique comme leur doudou effectivement ça peut avoir ce côté rassurant c'est pas forcément péjoratif être perçu comme tel mais ouais ça a ce côté rassurant Après, effectivement, tu disais, il ne faut pas essayer de partir trop loin non plus. Je n'ai pas postulé sur une mission à Askel. Là, la transition aurait été beaucoup plus raide. Je suis resté, moi, sur un paradigme objet avec globalement une grosse appétence pour du back-end. Dans ce que tu disais avant, je me demandais aussi, je vois très peu souvent des recrutements sur un secteur métier. et c'est très peu mis en valeur. Moi, j'essaie de le faire, mais je ne sais pas. Tu as bossé, je ne sais pas, c'est un poste pour la SNCF, si tu as bossé dans les transports, tu vas prendre une longueur d'avance. Ou sur de l'énergie, si tu as bossé pour EDF ou GDF ou je ne sais qui, tu vas prendre une longueur d'avance par rapport à d'autres. Et ça, je le vois très peu. J'ai l'impression que ça commence à pointer dans ce que tu disais juste avant, à regarder les profils. Mais je trouve ça encore assez rare. Est-ce que c'est mon biais ou est-ce que...

• Shirley

  C'est vrai, c'est assez rare, mais j'entends des fois des entreprises être attentives à ça, notamment des personnes en reconversion. Ils vont dire, ah bah, ok, il faut que je le forme sur le langage, mais sur le métier, il y a une histoire professionnelle où la personne, elle a déjà eu tant d'années d'expérience dans l'assurance, par exemple. C'était son métier. Et si en face, l'entreprise est dans l'assurance et recrue dans l'IT, la reconversion, elle n'est pas tant sur le métier, alors que des fois, Les problématiques techniques sont très… je ne sais pas comment exprimer, je vais essayer d'être claire, mais des fois, les problèmes techniques, c'est comprendre le métier avant tout qui est compliqué. Je ne sais pas si tu vois ce que je veux dire en disant ça. Si, si, tout à fait. Et des fois, la technique suit naturellement, dès l'instant où tu as déjà très bien compris les nuances du métier. Et c'est typiquement dans ces entreprises-là, où là, le métier a du sens, où là, vraiment, l'entreprise va dire « Ah d'accord, la personne, elle a quand même tant d'années sur le métier. » Ça va nous faire gagner énormément de temps parce que nos règles métiers, il y a des problématiques de réglementation, des problématiques de TVA, des problématiques même des fois à l'international, des problématiques, je n'en sais rien, de persona, clients qui sont très diversifiés. Il faut vraiment se mettre dans le métier pour capter la technique en fait. Et ces gens-là qui ont déjà eu une histoire avant d'aller dans la tech dans cette même entreprise, là par contre, elles gagnent des points. Ça, j'ai déjà remarqué pour le coup. Après, je ne veux pas non plus généraliser, mais c'est souvent dans des contextes où le métier est fortement impactant pour être bon dans le code. Peut-être que ce n'est pas tout pareil, mais je trouve que dans le domaine de l'assurance, par exemple, j'ai souvent entendu ça. Banque et assurance, la compréhension du métier est très forte.

• Sylvain

  C'est des métiers qui sont très exigeants. Après, tous les métiers, quelque part, sont exigeants. Si le métier est simple, on n'a pas de plus-value, j'ai envie de dire. Il faut que les gens se prennent des... Des outils sur étagère s'il n'y a pas beaucoup de métiers. Et c'est aussi une des fonctions premières du travail de dev, de comprendre le métier. Parce que si on ne comprend pas ce qu'on est en train de coder, en général, c'est un peu la base du mouvement craft. C'est un peu comprendre pourquoi tu es en train de coder, à qui tu es en train de rendre service. Tu te fais plaisir à sortir du code ou tu es en train de rendre service à des gens qui vont utiliser ton appli. Effectivement, comprendre le métier, ça peut faire... Ça peut avoir une grosse avance là-dessus. Moi, je l'ai déjà eu il y a longtemps. Je ne me rendais pas compte de la valeur que ça pouvait avoir. Après avoir passé 2-3 ans à bosser pour Carrefour, il y a des gens qui me disaient, nous, c'est confort à main. Tu as des notions de retail, ça peut nous servir. Il s'avère qu'en fait, c'était pour la partie SAV de confort à main. Et le SAV, c'est encore un métier dans le métier. Et je ne comprenais pas mieux ce qui se passait, mais j'ai appris aussi. des fois c'est très on croit que c'est un rapport et ça peut être vite très éloigné tu disais, tu parlais justement de si je reviens à ce que tu disais avant, ce côté un peu doudou, on se rassure avec la stack moi dans mes réflexions là dessus j'ai essayé de voir d'où ça venait et pareil ça a commencé à transparaître dans ce que tu disais j'ai l'impression qu'il y a les deux bords qui ont ce problème là Que ce soit les boîtes qui bossent vont vouloir se rassurer en prenant des gens qui connaissent la techno. Et en même temps, les devs qui vont se rassurer en prenant des postes qui correspondent à leur stack techno. Tout ce côté un peu rassurant, je me posais la question de à qui la faute ? Puisqu'au départ, pour ne rien te cacher... je me disais, c'est toujours à cause de la recruteuse, elles font les fiches de poste et puis machin, et puis en fait c'est quand même les devs qui vont dire, on a besoin de telle personne sur l'équipe, il faut les devs ou des fois les managers, les responsables de projet, mais en général ça tourne autour de la tech donc en fait c'est plus de la faute des recruteuses je vous ai tout de ce péché là, en fait c'est nous La question que je me pose, c'est, à force de recruter des gens qui nous ressemblent, est-ce qu'on ne risque pas de recruter que des gens qui nous ressemblent et de manquer de recul ? Je précise un peu le fond de ma pensée. J'ai eu ce souci très tôt dans ma carrière. J'ai une formation universitaire, ce qui veut dire déjà que je n'ai pas fait d'école d'ingé. Et assez tôt, je me faisais tacler parce que tu n'as pas fait d'école d'ingé, donc forcément, on va te payer moins. On fait le même travail au quotidien. Oui, mais tu n'as pas fait d'école d'ingé, on va te payer moins. Et en plus, moi, mon master, j'ai fait une licence qui n'avait aucun rapport. J'ai fait une licence de sciences cognitives. Donc, en fait, techniquement, en informatique, j'ai un bac plus deux. Ça doit être un master. Je n'ai fait que deux ans de dev avant de rejoindre le marché du travail. Et je me faisais tacler assez facilement là-dessus. Oui, mais nous, on cherche des ingénieurs. Je ne sais pas c'est quoi un ingénieur. Et on a un peu ce degré de consanguinité, je trouve. Tu ne sais pas si tu le constates aussi, mais on a un peu cette tendance à la consanguinité sur les projets, dans la construction des équipes de dev.

• Shirley

  Alors, moi, je vois plusieurs points dans ce que tu viens de dire. C'est l'histoire de te rassurer, et puis le côté consanguinité. Je le vois notamment sur le côté culturel du langage. C'est un truc qui n'a jamais été abordé en conf, ou peut-être que ça a déjà été fait, mais je n'ai jamais eu l'occasion de lire, ou même d'écouter une conf sur le sujet. Mais je trouve qu'il y a un côté très culturel. C'est-à-dire que ce qui est assez contradictoire, c'est que la culture de l'entreprise, ça va être de dire « je veux des gens diversifiés dans mes équipes, mais en même temps, je veux des gens qui matchent avec ma culture. » Et des fois, la culture, c'est la tour d'un langage. C'est-à-dire que toute l'équipe a une vision parfois de la tech qui a été formatée autour d'un langage. qui a été construit à travers une histoire professionnelle, il y a un réseau qui a été construit autour de ce langage, il y a des amitiés, des affinités, donc il y a même un côté presque affectif autour du langage. Et au final, de changer le langage, c'est de remettre beaucoup de choses en question. D'ailleurs, beaucoup de gens quittent le navire quand il y a un changement de langage, alors que quand on y pense, c'est qu'un langage. Parce qu'il y a vraiment ce côté « on est ensemble ou rien » , on est une communauté. Des fois, c'est pour ça que je te taquine beaucoup sur le côté presque religieux. du langage c'est que forme une communauté dans cette même dans cette même dans ce même langage et ça rassure de dire on avait des gens qui nous ressemblent on a une culture en commun voilà dotnet même des fois tu les vois dans des confs qui sont très estampillés sur un outil les confs google par exemple les confs microsoft ça va être par exemple les environnements autour de php aussi qui ont une culture je sais pas si tu vois ce que je veux dire Et donc, si toi, en tant qu'individu, tu t'extrais... d'un langage, tu t'extrais un peu aussi du milieu de ce langage, tu vois. Tu t'extrais, donc du coup, le fait d'être rassuré, c'est le fait d'être effectivement dans cette même famille, donc c'est pour ça qu'on parle de consanguinité, parce que c'est comme si on était dans la même famille de langage, avec les mêmes préoccupations, les mêmes problématiques au quotidien, et s'en extraire, c'est s'exclure quelque part du groupe. Donc, vraiment, cette réflexion, je me la suis faite quand j'ai vu, par exemple, des équipes partir totalement parce qu'il y avait juste un changement de stack ou même des gens qui finissent par revenir sur une stack où ils étaient par le passé parce qu'ils ont remarqué qu'ils n'aimaient pas une communauté donnée, ils n'aimaient pas l'état d'esprit, ils n'avaient pas assez de craft, par exemple, ou ce genre de choses. Et donc, je me suis dit, tiens, c'est marrant, en fait, la personne, elle a besoin de revenir à des fondamentaux, à une sorte de famille premier amour, quoi, pour... justement se rassurer et se sentir bien dans son métier de développeur ou de développeuse. Alors j'ai un exemple typiquement sur Ruby, où quelqu'un a basculé sur Ruby, elle a complètement été étonnée de la différence culturelle. C'est un langage qui était plus élitiste à ses yeux. Elle a trouvé qu'on n'était pas sur la même façon de voir le code, etc. Elle a préféré revenir sur du PHP, par exemple. Un exemple. Mais c'est là où je me dis qu'effectivement, la diversité, qui manquent. La faute à qui, comme tu dis, c'est effectivement des fois des recruteurs qui ne savent pas ce qu'ils veulent. Et donc, le langage va être un petit peu ce côté « Ok, on ne sait pas ce qu'on veut, mais on met un mot qu'on connaît à peu près et qui fait joli. » Et donc, à partir de là, ça va attirer du monde. Il y a aussi les devs eux-mêmes qui ne créent pas cette diversité parce qu'ils ont besoin d'être dans leur petite famille rassurante avec leur petit doudou. Mais il y a aussi les... managers et les opérationnels qui ne savent pas évaluer autre chose qu'un autre langage. C'est-à-dire qu'ils ont toujours recruté dans les équipes que du .NET, ils ont monté toute leur base d'évaluation et technique sur du .NET. Demain, il y a un monsieur ou madame Java qui arrive, ils disent « Ouh là là, on est perdu, on ne sait pas faire » . Beaucoup de managers, que ce soit autour du langage informatique, mais sur bien d'autres sujets, ont du mal à composer avec la différence. Ils ne savent pas faire, ils ne savent pas évaluer, ils ne savent pas intégrer aussi en poste une personne qui aurait une différence de langue. Et ça se voit dans le langage informatique, mais aussi dans les différences de langue étrangères. Par exemple, il y a des personnes qui, clairement, culturellement, ils te le disent, on n'est pas de la même culture, tu vois. Et tu le sens que l'entre-soi se renforce beaucoup dans des contextes de crise. C'est-à-dire qu'il suffit qu'il y ait une crise économique dans le monde de la tech comme on le vit en ce moment. Quand on ne sait pas faire avec la différence, on fait avec ce qu'on a. C'est pas on va investir, on va innover, on va aller chercher de la nouveauté, parce que c'est ça quand ça va bien, quand les caisses sont remplies dans les entreprises, ça innove, ça investit, ça se dit, on donne la chance quelque part, que ce soit des gens en reconversion, des gens qui ont d'autres langages. Mais quand on est dans un contexte de crise, c'est on reste vraiment crampé sur nos positions, on est là à se dire finalement on va pas changer de techno, ça coûte trop cher, on sait pas faire. On reste sur nos acquis, sur ce qu'on sait faire. Et du coup, ça veut dire qu'on va rester sur ce même langage. On va recruter les mêmes personnes du même langage. Et on ne va surtout pas innover. On attendra que ça aille mieux pour ça. Donc, la raison, elle est aussi un peu autour de beaucoup d'entreprises qui sont très frileuses aujourd'hui dans le recrutement. Moi, je le vois, avant, j'envoyais cinq personnes. Je le dis sincèrement. Il y avait une des personnes qui était recrutée. Aujourd'hui, j'en vois 14. Et on me dit, ah ça, ceci, ça, cela, et donc ça, ça ne va pas le faire. Et je me dis, mais punaise, on est devenu dans un monde de tarés sur la frilosité, sur les critères de recrutement. Et donc, plus tu montres quelque part que tu n'es pas dans le moule attendu, plus tu fais peur. Et la peur, aujourd'hui, ça t'empêche de prendre des décisions nouvelles, d'investir, d'innover, de prendre des risques. Et le changement de techno est vu comme une prise de risque. Alors que j'ai envie de te dire, je ne sais pas, peut-être en 2022, à mon avis, en recrutant 14 personnes, c'était tellement la concurrence sur le marché qu'il y avait tellement de difficultés à recruter les individus parce qu'ils étaient sollicités par la terre entière, qu'ils se sont dit pourquoi pas effectivement prendre cette personne, on va lui donner sa chance, on a le cash, on peut le former, on peut lui donner un peu de jus de cerveau pour qu'on puisse l'accompagner, etc. Alors que maintenant, on est beaucoup moins sur cette logique-là. Donc ça joue aussi beaucoup cet entre-soi dans les équipes lié à un contexte où on investit moins dans l'apprentissage, en innovation, dans la prise de risque, tout simplement. J'ai dit plein de choses en même temps, mais je ne sais pas si tu arriveras à ressortir le truc.

• Sylvain

  Si, mais en plus, ça résonne avec ce que tu disais presque au... Au tout début, je crois. Pour se vendre un peu quand on cherche à sortir de notre zone de confort, de notre famille, du coup, il ne faut pas le montrer comme un espèce de nouveau départ, mais plus comme une évolution. Et là, je pense qu'en termes de posture, en termes de perception, tu changes de catégorie. Tu passes dans les gens qui sont suffisamment experts pour pouvoir naviguer à travers les... à travers les stacks et apporter autre chose, quelque chose à être impactant à un niveau de plus. Et tu as parlé un moment de l'impact, juste c'était assez bref, mais dans le passé, est-ce que cette personne a eu quel impact ? Elle a eu sur son écosystème, sur son projet ? Et ça, j'aime bien revenir avec le sujet. Il ne l'a pas fait beaucoup malheureusement, c'était Hugo Lassiège, un des fondateurs de Malte. qui avait fait une conf sur dev senior au bout de 5 ans et après quoi ? Si on est déjà senior avec 5 ans d'XP et lui il mesure un peu la seniorité du dev avec le niveau d'impact qu'on peut avoir quand on est junior on va avoir un impact sur le code qu'on écrit, quand on est senior il faut être capable d'avoir un impact sur l'équipe avec laquelle on bosse c'est un peu le rôle de tech lead et puis après plus on va vouloir monter en grade entre guillemets Et plus, il va falloir élargir le champ d'impact qu'on peut avoir. Ça va être passer de l'impact au niveau de l'équipe, au niveau du plateau, au niveau du pôle dans lequel on travaille, au niveau de la boîte pour laquelle on bosse. Et puis, à terme, être capable d'avoir un impact au sein d'un écosystème, à une échelle nationale ou internationale. Il y a des gens qui ont des impacts, des gens qui ont révolutionné des technos, des pratiques. Alors, tout le monde ne peut pas forcément viser ce truc-là. Je sais que... Je ne suis pas Ken Beck et je n'aurai jamais un impact sur la communauté à ce niveau-là, mais voir aussi les niveaux d'exigence. Je ne sais même pas pourquoi je suis parti là-dessus, mais c'est un moment où j'ai voulu rebondir sur cette notion d'impact. Et c'est un peu fondamental de se poser la question de l'impact qu'on veut avoir sur une équipe. C'est légitime de se dire « non, non, moi je veux juste faire mon code » et c'est ok. Il n'y a pas de mal à ne pas vouloir viser la lune à chaque fois qu'on fait un truc. mais du coup ça se met en face les exigences salariales qu'on peut avoir parce que on peut pas payer autant des gens qui vont transformer toute la boîte des gens qui vont juste transforme pourtant ça de la valeur aussi hein!

• Shirley

  Mais ce que tu dis c'est intéressant parce que si je me permets de rebondir, c'est le fameux thread des red flags que j'avais fait côté candidat se rappelle oui de personnes ont été surprises que je mette en avant le fait que les personnes soient trop la tech pour la tech, tu vois. Bah oui, en fait, on est des experts techniques, donc c'est important de parler que de la tech. Et c'est vrai qu'effectivement, l'impact, je trouve que c'est, à un moment donné, se rendre compte que la tech, c'est pas juste pour la tech, mais c'est aussi pour au service d'eux. Et quels sont finalement tes livrables et quels sont tes impacts côté business, côté aussi en interne, en fait. C'est-à-dire, à un moment donné, la tech, c'est pas juste du code, ça peut être aussi des bonnes pratiques de dev. Donc, autant, effectivement, Hugo, lui, voyait sur ... les impacts en fonction des années d'expérience. Et moi, je voyais plutôt l'impact sur les différents domaines. Il y a le domaine de la communication, par exemple, qui peut avoir un véritable impact, en tant que speaker, par exemple, en partageant, en étant vraiment, en brillant dans ta communauté, par exemple. L'impact autour de la pure tech, pour le coup, c'est-à-dire si tu as dû gérer un projet from scratch ou même une gestion de legacy. ou la programmation, je ne sais pas, concurrente, où il y avait des problématiques de sécurité. Et tu peux avoir aussi l'impact côté humain, si par exemple tu as fait tout ce qui va être recrutement, formation, aide auprès des personnes, même si tu es junior, tu peux avoir clairement un impact autour de ça. Et tout ce qui va être impact méthodo, c'est-à-dire est-ce que tu as à un moment donné assaini l'application, mis en place des bonnes pratiques, est-ce que tu as permis à un moment donné à ce que la communication soit beaucoup plus... beaucoup plus fluides entre les équipes, etc. Tout ça pour dire qu'effectivement, à un moment donné, les entreprises sont de plus en plus attentives à des gens qui, à un moment donné, ont plus que la tech. Tu vois ce que je veux dire ? Qui ne voient pas que le code pour le code, mais qui se rendent compte qu'en fait, ils font partie d'une équipe, qu'ils font partie aussi d'une entreprise avec un business. Donc, le business, ce n'est pas juste un truc que pour les commerciaux et les chefs de projet. Et plus une personne, elle arrive quelque part à travailler et tout. toute cette partie de son CV. elles-mêmes, d'une part, elles se rendront compte que la technologie, ce n'est pas le plus important. Et deuxièmement, elles se rendront compte que, en fait, parler de la techno, ça peut avoir plusieurs spectres. Ce n'est pas juste la technologie Java ou .NET, mais ça peut être aussi, encore une fois, les problématiques de performance, les problématiques de scalabilité, les problématiques de sécurité, les problématiques, ça peut être plein, plein de choses sur des sujets techniques, en fait. Et donc, à partir de là, tu te rends compte que les gens qui ont déjà pigé ça aujourd'hui sont vachement plus pertinents parce que la techno... ça devient quelque part juste un accessoire du discours. Ça ne devient pas le discours majoritaire. Et ceux qui sont restés encore sur du technocentrique, c'est-à-dire uniquement que la techno, Java, telle version, et je veux que faire Java et que machin, en fait, ils n'ont pas grandi dans la scalabilité de la solution. Ils n'ont fait qu'une première couche, la couche technique. Ils n'ont pas été sur la couche un petit peu plus supplémentaire. C'est-à-dire, pourquoi ton code ? à qui il sert, pourquoi tu veux le faire, etc. Et c'était ça le fond de mon message, et je pense que ça n'a pas été assez compris, parce que là on est sur Twitter, et puis en plus, clairement, tu ne peux pas tout expliquer. Mais aujourd'hui, effectivement, l'entre-soi se voit encore, je trouve, un peu trop souvent sur des gens technocentriques, où ils ne voient que l'excellence technique, ils envoient des codes de 4 heures à réaliser chez soi, il faut exactement que tu arrives à répondre comme la personne tech. pensent dans l'entreprise. C'est déjà arrivé, je ne sais pas si c'était l'entreprise en question, mais beaucoup de retours sur cette même entreprise où finalement, les gens étaient très, très bons par ailleurs. Ils ont même eu des postes excellentissimes. Mais en faisant l'exercice technique, en fait, comme ta vision du code n'était pas la vision tech, pure tech, du tech lead, en fait, ils ne passaient pas la suite des processus de recrutement. Et je trouve que les gens qui vraiment sont dans l'entre-soi technique, Ce sont des gens qui n'ont vu que la techno pour la techno, et des fois d'ailleurs on est un peu, je trouve, en interne dans une maison des petits cochons. Je ne sais pas si tu vois ce que je veux dire en disant ça, mais il y en a un, il adore Node, il a décidé de développer une brique sur Node, un autre il a développé sur du .NET, et puis une autre elle a dit, ah bah tiens moi aussi j'adore Java, donc au final on ne sait même plus à quoi sert la techno. Chacun se fait un petit peu plaisir, et au final ça devient complètement pas cohérent techniquement, ou trop homogène techniquement, c'est-à-dire que... aucune nouveauté est possible, ou alors les nouveautés c'est que pour son petit plaisir personnel. Je ne sais pas si je suis claire en disant ça, mais presque vraiment, plus l'entreprise a, je trouve, cette hauteur de vue sur l'usage de sa techno, plus la techno n'est pas au centre de ses préoccupations, à la fois dans le discours, sur le titre même du poste, tu remarqueras que des fois on voit un city au Java. Why not ? C'est bizarre, mais ok. Ou encore même, dans le contenu même de ce qu'ils attendent. Des fois, tu vois plein de stacks, ou alors plein de mots-clés, ou un truc que technique, technique, technique. Là, tu te rends compte qu'ils n'ont pas, entre guillemets, pris de maturité sur leur code. Donc j'essaie de reprendre un peu ce que tu as dit, mais pour t'expliquer un petit peu l'envers du décor aussi, dans ce que je perçois par rapport à la notion d'impact même, et aussi par rapport à, encore une fois, l'histoire de l'entre-soi.

• Sylvain

  Tu as tout dit, c'est bon, c'est dans la boîte. Non, clairement, je n'ai pas grand-chose à ajouter là-dessus. Je constate pas mal de choses qui vont effectivement dans ce sens-là. Je mettrais juste un disclaimer. On n'est pas en train de dire que maîtriser la tech, ce n'est pas bien. Il en faut et c'est important d'avoir des gens qui maîtrisent les outils sur le bout des doigts au sein d'une équipe parce qu'il y arrive des fois où... Mais encore une fois, c'est pour avoir de l'impact. Là, je l'ai eu même ce matin avec les collègues. C'est un mec d'une autre team qui est arrivé à côté pour libérer toute l'équipe d'une problématique. Il a fait des trucs de folie sur des outils auxquels je ne comprends rien. C'est un truc de fou. Mais des fois, il y a des gens qui ont des maîtrises ultra pointues, qui sont hyper spécialisés, mais qui savent se rendre dispo là-dessus. Et il y a plein, genre 10 000 anecdotes sur les gens qui sont trop techno-centrés, qui n'ont pas de... Qui n'ont pas de culture de partage, qui n'ont pas de culture d'impact. Ils font leur truc dans leur coin, ils sont très bons. Tu poses une question, ouais, non, mais c'est bon. Je ne sais pas, tu as des juniors autour de toi, il faut les accompagner, il faut les amener.

• Shirley

  C'est ça. En fait, le pire, c'est ce que j'allais dire, c'est que quand ces personnes sont à un niveau de responsabilité et qu'elles recrutent, ça fait des ravages, je trouve. À la limite, dans une équipe, tu as une personne comme ça, pourquoi pas ? Elle est très bonne, tant mieux. Et quand vraiment, ça devient la vision et la culture technique je trouve que ça peut faire quand même pas mal de ravages.

• Sylvain

  Ça peut faire, ouais, effectivement, du dégât. J'ai envie de proposer une conclusion à tout ce qu'on a dit. En fait, on l'a déjà dit 20 fois, mais je ne vais pas rafraiser. C'est un peu... Il y a plein de gens qui se disent « Ah, est-ce que je pourrais changer de stack ? Est-ce que c'est une bonne idée ? Est-ce que ça se tente ? » J'ai envie de dire, si vous êtes... curieux, curieuse, go. Il n'y a pas de barrière, en fait, autre que celle qu'on se met soi-même.

• Shirley

  Là,tu as dit go. On est d'accord, c'est le langage go.

• Sylvain

  Je n'ai jamais fait de go. J'ai ouvert une fois un projet en go, j'ai regardé, je me suis dit, ce n'est pas pour moi, ce truc-là.

• Shirley

  La fille qu'a rien compris, en fait. Elle arrive sur la fin, conclusion, elle comprend que dalle.

• Sylvain

  Go, go, non, non. Elle 'PERL' rien pour attendre. On a beaucoup de jeux de mots comme ça. Je sais que tu es spécialiste.

• Shirley

  Java bien, en fait!

• Sylvain

  Non, mais en vrai, il y a plein de gens qui se posent parfois des questions et qui n'osent pas. En fait, il faut oser, avec les garde-fous que tu précisais au début, faire gaffe un peu au domaine. Est-ce que c'est sur de la mission, plus orienté freelancing ? Est-ce que c'est sur du CDI ? Dans les contextes, et vraiment mettre en avant tout ce qu'on a d'autre quand il n'y a plus la stack. Je pense que ça peut être un exercice pour ce que je veux faire de ma carrière. Si j'enlève la stack, qu'est-ce que je sais faire aujourd'hui ? Qu'est-ce qu'il me reste ? S'il n'y a rien, sauf de se reposer la question et se revaloriser, puisque des fois, on se dit qu'on ne sait rien faire d'autre. C'est faux. Mais j'aurais envie d'encourager les gens à explorer plus de stack, plus de technos différentes pour pouvoir mieux s'en abstraire. J'ai des collègues qui disaient... Alors... religion entre guillemets d'apprentissage c'est une année un langage à apprendre chaque année un nouveau langage ça peut être compliqué parce que il faut du temps quand même pour rentrer dans les tréfonds un langage et en comprendre la la valeur mais mais c'est une optique ça ouvre beaucoup ça peut beaucoup ouvrir on peut se rendre compte qu'en fait déjà on va enlever ce côté doudou vas-y c'est mon truc que je maîtrise non mais en fait c'est bien à côté aussi Moi, il y a encore des gens, quand je dis que je suis parti de .NET et je suis arrivé en Jaffa, « Oh, mais le pauvre, mais qu'est-ce qui t'arrive ? » Non, je te jure, ça va. Mais vraiment, ça va très bien.

• Shirley

  Le langage qui prend cher, c'est quand même PHP aussi, ça, beaucoup. Tu vois, le côté très a priori, « Ah ouais, en fait, c'est pas un codeur. Ah ouais, en fait, mon pauvre, tu fais pas vraiment du développement. » Alors que plein de personnes, finalement, connaissent très mal le monde de l'autre. Et ça, c'est dans tous les domaines. Mais je trouve... D'explorer un langage, c'est bien pour sa connaissance personnelle, mais c'est aussi bien pour ouvrir un peu ses œillères, tu vois. De s'ouvrir à d'autres communautés, à d'autres paradigmes, à une autre vision de la tech aussi, peut-être. Des fois, il peut y avoir d'autres façons de voir le code aussi, quoi. Et je trouve que c'est ça qui manque parfois un peu beaucoup dans ce milieu.

• Sylvain

  Et en plus, je trouve qu'on contrôle mieux quand on connaît la stack. J'ai un collègue qui me dit, il me fait... Java, c'est le langage que je déteste le plus parce que c'est celui que je connais le plus. Donc, j'ai toutes les raisons de bien le détester, mais c'est quand même celui que je préfère parce que voilà, 20 ans d'XP, 20 ans de Java, je maîtrise à fond. Mais ce langage est pourri, mais j'adore, c'est mon langage préféré. Mais mon Dieu qu'il est pourri. Et la démonstration l'a pu, en plus, il nous a fait une belle démo récemment. Java est vraiment un langage à claquer au sol. Au moins, autant que JavaScript. On tacle beaucoup JS, mais Java doit se regarder dans son miroir des fois aussi. Je te remercie vraiment pour cet échange sur l'Est. C'était super intéressant. J'ai l'impression qu'on pourrait encore dérouler des trucs sur tout ça. Mais on a déjà un bon...

• Shirley

  Merci d'avoir pu parler de tout ça en sachant que je ne suis pas codeuse. Pour moi, c'était vraiment en mode... est-ce que je vais être pertinente alors que je ne développe pas en fait. Donc ça, c'est vraiment le sujet de ma vie. Des fois, c'est de donner des conseils, de donner mon regard de la tech. Sans être codeuse, t'es forcément décriée, t'es forcément critiquée, t'es forcément « vas-y, mais fais notre métier » . Donc voilà. Merci de m'avoir donné cet espace parce que c'est jamais simple déjà moi de me sentir ok, légitime pour parler de ça. Et puis d'être entendue comme ayant des conseils intéressants aussi. Donc ça fait plaisir.

• Sylvain

  Tu es, pour moi, tu es, tu resteras légitime sur ces sujets-là. J'en veux pour preuve que tu as plus de vocabulaire technique que moi. Il y a des choses que tu as écrites, des fois je fais, mais je ne connais pas ce stack de quoi elle parle. Et en fait, tu sais globalement les tenants aboutissants, où c'est utilisé. Tu vois, tu me parles de Go, c'est plus sur l'infra. J'en sais rien, je te crois sur parole. Donc, il n'y a pas de souci. Je rappellerai aux gens qui ont encore du scepticisme sur le monde du recrutement. Il y a des gens qui travaillent très, très bien. Tu es la personne qui m'a réconcilié avec le monde du recrutement, Shirley. J'avais beaucoup de rancoeur.

• Shirley

  Ouah trop de superlatifs là, attention, j'vais prendre le melon après!

• Sylvain

  Non, non, t'inquiète, t'inquiète. Il y a eu deux choses à ça. J'ai vu comment tu bossais. Je me suis dit, en fait, on peut recruter différemment. J'avais que le modèle un peu... Un peu intérimaire de l'ESN moderne. J'suis passée par là aussi. Oui mais on est beaucoup y être passé. Qui esquinte pas mal de gens. Je trouvais ça intéressant. Et puis, tu sais aussi qu'on s'est très bien entendus sur de l'écriture de chansons. Et ça, ça change beaucoup de choses.

• Shirley

  C'est ça, en fait, évidemment. Là, on s'est compris. La musique, ça réconcilie les peuples.

• Sylvain

  Exactement, exactement. je mettrais un peu tes liens ta présence sur les réseaux est-ce qu'il y a d'autres je sais pas d'autres liens que tu voudrais que je mette puisque tu as parlé de ta fonction d'agent de carrière on peut trouver ça où en ligne ?

• Shirley

  Sur GitHub en général sur mon profil GitHub j'ai mis toutes mes offres on va dire tout ce que je peux apporter donc c'est assez complet pour le coup j'ai mon site internet aussi que j'ai refait merci Et il a accès complet aussi, j'ai fini par mettre quand même pas mal de choses dessus, donc je peux t'envoyer les deux si ça t'intéresse et comme ça tu as de quoi regarder.

• Sylvain

  Je mettrais tout ça dedans, déjà j'ai envie de dire, t'es une recruteuse, t'es un GitHub quoi, non mais allô ?

• Shirley

  L'imposteur quoi ! C'est pas le syndrome moi, c'est clairement l'imposteur !

• Sylvain

  Mais non, justement, bien au contraire, je pense pas que y'en ait beaucoup. Tu ne penses pas qu'il y en ait beaucoup qui puissent se targuer d'avoir un argument pareil ? Non, mais je comprends ce que vous faites. J'ai mon GitHub, j'ai des trucs dessus.

• Shirley

  Après, là, pour le coup, j'ai envie de citer Jeanne Londich, qui clairement a été une source d'inspiration sur le sujet, parce qu'elle a mis ses annonces en ligne. Elle est beaucoup plus dans le monde PHP, pour le coup. Et vraiment, j'ai trouvé ça génial. Et donc après, je me suis dit, tiens, je vais pousser le curseur plus loin, je vais mettre aussi mes annonces, et je vais faire une présentation complète, comme ça, s'il y a des personnes qui sont intéressées, elles pourront même commenter et tout. Donc je me suis dit, tiens, c'est un bon moyen de... De s'inscrire vraiment pleinement dans la communauté tech. Je ne suis pas du tout la pionnière, on va dire, sur le sujet.

• Sylvain

  Ok. Bel élan de modestie.

• Shirley

  Voilà.

• Sylvain

  Encore une fois, merci beaucoup, Shirley, d'avoir répondu présente à l'appel, à l'invitation. Merci pour tes propos éclairants. C'était vraiment instructif. J'ai bien aimé ça. Au plaisir de continuer cette discussion. Et puis, si en nous écoutant, il y a des trucs qui vous inspirent, des questions, des remarques, vous n'êtes pas d'accord, n'hésitez pas à nous pinguer sur les réseaux. Ça me ferait plaisir de pouvoir continuer la discussion à ce sujet-là. Pour tout dire, j'ai l'impression que ça va être un peu le fil rouge de la fin de saison du podcast. J'ai d'autres gens avec qui j'ai envie de parler de ça. J'ai l'impression qu'il y a un vrai sujet autour du silotage, du changement de stack, des pratiques de base. Donc, ce sujet, je suis désolé pour l'auditoire. Ce sujet n'est pas fini sur le podcast. On va encore en reparler.

• Shirley

  Mais fais intervenir une personne complètement à l'opposé de mon discours, ça peut être intéressant. Des gens qui ne pensent pas du tout, qui sont très tech. Et peut-être que ça peut apporter une autre vision que moi, je n'ai pas non plus. Clairement, ça peut avoir du sens aussi d'avoir des personnes à l'extrême opposée de moi. Moi, j'aime bien ça.

• Sylvain

  Il faut que je prenne note de ça. Je vais avoir tendance à trop faire venir des gens avec qui je suis d'accord.

• Shirley

  Ouais, c'est ça.

• Sylvain

  Effet, j'allais dire, chambre d'écho. C'est mon réseau qui a les biais que je lui mets, même sans le faire exprès. Mais c'est intéressant, je vais tenter ça. Ouais, ça peut être intéressant. Trouver quelqu'un avec qui, une battle avec quelqu'un avec qui je ne suis pas d'accord.

• Shirley

  Ouais, mais ça c'est, pour moi, le vraie échange aussi, tu vois. C'est pas juste des gens qui sont d'accord avec toi. C'est aussi des personnes qui vont vraiment avoir une opinion opposée. Et tu dis, ah bah tiens, pourquoi ils pensent ça ? Qu'est-ce qui se passe ? C'est quoi ton sujet ? Evidemment, toujours dans le respect, bien sûr. Après, s'il n'y a plus de respect, ça ne sert à rien. Mais voilà. En tout cas, je trouve que ça peut avoir du sens.

• Sylvain

  Yes. Bon, et bien encore, merci une dernière fois. Merci aussi. Chaque fois que je dis ça, on vous rembraye sur d'autres choses.

• Shirley

  Exactement.

• Sylvain

  Et bah je te dis ouais à une prochaine je mettrai tout ça dans la description super et pour vous qui nous avez écouté jusqu'ici il me reste à vous souhaiter une excellente fin de semaine à la prochaine pour un nouvel épisode et d'ici là et bah cliquez bien et codez bien