Speaker #0Je crois souvent que devenir architecte, c'est une question de compétences techniques, de design pattern ou de langage de programmation. Honnêtement, moi aussi, je croyais. Jusqu'au jour où tout a basculé. Et c'était prendre un simple entretien d'embauche. Salut et bienvenue dans On parle Dev. Aujourd'hui je vais te raconter une histoire. Une histoire qui a complètement changé ma façon de voir mon travail de dev. En fait, pendant longtemps, comme beaucoup d'entre vous j'imagine, je pensais que pour progresser, pour évoluer, il fallait seulement devenir meilleur développeur. Donc coder mieux, maîtriser des frameworks, être rapide, livrer plus. Mais... Ce jour-là, c'était un entretien d'embauche avec une compagnie de Montréal. J'ai réalisé que j'avais déjà en moi quelque chose de plus puissant que le dev, quelque chose qui me permettait de voir plus loin que le code, qui était là, mais je n'en avais pas conscience. Donc, pour te mettre en situation, j'étais à un entretien. Comme je te l'ai dit, j'étais dans notre tiers. J'étais confiant. Je connaissais ma stack. J'avais des compétences solides pour le poste. C'était pour du VJS, ça fait que j'étais à mon aise. Puis, au milieu des questions, le recruteur me pose une question qui m'a séché. Et si tu devais faire évoluer le produit, notre stack, comment tu t'y prendrais ? Ben là j'ai eu comme un blanc dans ma tête, puis en fait c'est fou parce que j'ai même pas eu besoin de réfléchir pour répondre. J'ai commencé à lui expliquer sans même me rendre compte que j'avais un plan déjà clair et détaillé dans ma tête par rapport à ce qu'il m'avait raconté sur leur produit. Donc j'ai expliqué directement comme ça, comment je découplerais le front-end et le back-end. soit plus flexible, quelle stack serait la meilleure pour garantir une meilleure performance et une meilleure scalabilité, puis les bonnes pratiques que je mettrais en place dès le début pour éviter les dettes techniques. Et plus je parlais, plus je voyais l'expression du recruteur en face qui changeait. Et j'ai compris qu'il m'écoutait comme si j'étais... que je n'étais pas simplement un dev, c'est comme si j'étais un architecte. Et c'est là que j'ai eu mon déclic, en fait. Moi, je pensais que pour être architecte, il fallait avoir des compétences techniques, des diplômes, je ne sais pas, connaître tous les principes, les principes solides par cœur, les design patterns et tout, tout le bordel. Mais à ce moment-là, j'ai compris que ce n'était pas vraiment ça. Bah si, c'est ça, mais pas seulement ça. La différence, en fait, c'est la vision. Comment on voit les choses. Le fait de comprendre comment les systèmes doivent évoluer, comment les composeurs doivent interagir entre eux, et comment anticiper les problèmes avant qu'ils nous pètent à la gueule. c'est ça qui m'a fait comprendre que j'avais déjà ça en moi. Donc j'avais cette vision sans m'en rendre compte et j'avais déjà le mindset de l'architecte. Alors, j'ai imaginé trois réflexions qui ont changé ma façon de penser. Alors, pour que ce soit plus concret pour toi, voilà trois réflexions qui pourront t'aider. Donc la première, c'est que le code, c'est juste un moyen. Tu peux être le meilleur développeur du monde, mais si tu ne comprends pas où tu vas, où va le produit, tu resteras un dev. Peut-être que ça. Ensuite, l'architecture, c'est une vision. Ce n'est pas seulement des connaissances techniques. C'est la capacité de voir comment tout s'abrique les uns dans les autres, comme si c'était un puzzle. Et c'est ça qui fait la différence. Encore une fois, plus c'est simple, mieux c'est. Un système qui est bien passé, c'est un système qui est évolutif, qui est clair et qui est simple. tas de technos compliqués et de complexité inutile. Alors ce que je te propose, c'est un plan d'action pour toi, pour que tu puisses commencer à penser autrement. Donc commence à réfléchir comme un architecte, même si tu es encore développeur. Quand tu codes une fonctionnalité, demande-toi comment est-ce que ça va évoluer, comment ça sera dans 6 mois et comment la... la plateforme sur laquelle tu travailles va évoluer. Si tu construis une solution, demande-toi est-ce que c'est la façon la plus simple de le faire. Ensuite, observe les produits sur lesquels tu travailles. Va voir le code qui existe et pose-toi les questions. Est-ce que c'est facilement évolutif ? Est-ce que l'architecture est claire ? Et surtout, demande-toi toujours pourquoi avant de coder. Pourquoi est-ce que... cette fonctionnalité est prioritaire et pourquoi utiliser cette stack plutôt qu'une autre. Chaque stack a ses avantages, ses inconvénients. Chacune d'entre elles doit être utilisée pour répondre à un besoin plutôt qu'un autre. Du coup, essaye de comprendre le pourquoi du comment. Ça te permettra de mieux comprendre le produit sur lequel tu travailles. mieux pouvoir anticiper et apporter des solutions plus pertinentes. Donc en résumé, dans l'épisode, je t'ai raconté comment un simple entretien d'embauche a révélé quelque chose que je ne savais même pas moi-même, donc que j'avais déjà la mentalité d'un architecte. Pas parce que je connais toutes les technos, loin de là, ou même toutes les théories d'architecture, honnêtement... Tout ce qui est théorique, je n'y suis pas encore, mais parce que j'avais cette capacité de voir plus loin que le code. Donc le code, c'est un moyen. L'architecture, c'est une vision. Et la simplicité, c'est une force. Surtout, tu n'as pas besoin de tout savoir pour croiser comme un architecte. Tu peux apprendre tout ce qui est théorie. Tu dois juste commencer à voir plus loin et écouter. ce que tu as en toi. Parce qu'au fil des projets, au fil des années, tu as dû accumuler beaucoup de connaissances, beaucoup d'expériences et tu sais par où il faut aller. Il faut juste t'écouter. J'ai compris que voir plus loin que le code, c'est la clé pour évoluer. Maintenant toi, c'est quoi ton plus grand blocage ? Partage-le en commentaire. J'essayerai de t'aider. Merci d'avoir écouté jusqu'au bout. Souviens-toi que la vraie progression, elle commence par une vision et pas forcément par des lignes de code. Si l'épisode t'a parlé, abonne-toi. Tu peux me laisser 5 étoiles sur Spotify et Apple Podcast. Ça va m'aider énormément à faire connaître le podcast. Partage-le aussi si tu as des amis qui pourraient t'intéresser. Et voilà, je te dis à bientôt pour un prochain épisode. Ciao !
