L'autre jour, j'ai demandé à mon tech lead : "Comment t'es venu l'idée d’implémenter X solution dans l'infra ? ».
Il utilise des tags pour repérer des versions de déploiement avec un outil d'infra. Je passe les détails. Et quand il m’a répondu j'ai vu la lueur dans ses yeux alors qu’il m'expliquait.
Au départ il faisait ça manuellement. Puis ça a commencé à le fatiguer de plus en plus avec les contraintes et les horaires à respecter. Alors il a creusé, lu un article sur l'utilisation de tags dans ce contexte, et l'idée a germé dans sa tête. Il a fini par concevoir et implémenter la solution, et c'est devenu efficace.
J’en suis sorti avec de nouvelles connaissances sur de l’infra, d’où l’importance de poser des questions, et de prendre le temps de creuser soi-même les sujets.
C’est quelque chose que je fais tous les jours. Je prends un peu de temps chaque jour pour explorer les concepts que je rencontre dans ma mission.
Même si c’est pas nécessaire pour dérouler les tickets, je le fais quand même.
Je bosse sur un projet multi-market avec une archi clean, très paramétré et configurable avec des patterns de proxies, …
En soi, je pourrais juste me contenter d'apprendre à utiliser l’existant et ça irait. Mais je refuse de faire ça.
Y’a 2 choses distinctes :
1 Apprendre à utiliser l’existant (savoir utiliser un outil)
2 Comprendre l’origine de l’existant (comprendre pourquoi on a choisi cet outil et comment il fonctionne en profondeur)
Donc je me force (oui, force, car certains jours j’ai pas envie) chaque jour à prendre un temps pour creuser les notions techniques que je rencontre. Je vais plus loin dans la codebase, je passe du temps sur la config du projet. Pour moi c'est un très bon moyen de progresser en continu, et ça me permet d’apporter plus de valeur au projet et à l’équipe au passage.
Ça demande pas forcément beaucoup d’effort, mais il faut le faire régulièrement. Parfois ça peut être 30 minutes, parfois plus. Et des fois je peux y passer une partie de mon temps libre aussi.
Ça fait progresser techniquement mais également dans la compréhension globale du projet.
Parce que l’idée, c'est aussi de comprendre les choix d'architecture : tout seul c'est compliqué mais en creusant seul on arrive avec des questions pertinentes à poser aux anciens du projet, aux leads, tech lead, …
Et le truc, c’est qu’ils adorent expliquer les choix d'archi, et moi ça me permet de gagner de la compétence. C'est gagnant pour tout le monde.
Je trouve que le progrès est optimal quand on combine la pro-activité, la communication, et la psychologie (il faut savoir poser des questions qui stimulent nos interlocuteurs), avec le fait de passer du temps à creuser les sujets soi-même.
Et pour aller encore plus loin, on peut aussi bosser sur un projet perso qui fonctionne en synergie avec sa mission (un projet qui se base un peu sur les mêmes technos et qui donne l'occasion d'appliquer from scratch ce qu'on manipule au quotidien).
Expert en architecture et développement | Gestion de projets IT | Développement Web | Autodidacte passionné
2 moisC’est probablement ce gars là qui devrait être nommé à Matignon.