Comment progresser plus vite ? C'est une question qui revient super souvent sur LinkedIn ou
dans les commentaires de la chaîne Xavki.
Et bien ce que je vous propose, c'est quelques minutes juste de réflexion, en tout cas ma
réponse par rapport à ce cas de figure.
Pour progresser plus vite, il y a pas mal de méthodes.
On va dire la méthode un petit peu classique pédagogique, c'est-à-dire il va falloir
se documenter, apprendre, tester.
Ça bien sûr, c'est le cas un petit peu classique, mais derrière tout ça, il y a
quand même quelque chose qui l'emporte au-dessus des autres.
C'est le fait de prendre un maximum de choses et éviter de se poser des questions de « est-ce
que finalement j'ai un intérêt à le prendre ou pas ? Est-ce que ça m'intéresse ou pas
de le prendre ? » Ça, c'est plutôt la mauvaise posture qu'il faut éviter de prendre quand
vous êtes au travail en mode production.
C'est-à-dire que vous avez quelque chose, il y a une problématique, vous l'apprenez
quoi qu'il arrive et vous allez apprendre des choses.
Pourquoi derrière vous allez apprendre des choses et pourquoi vous allez potentiellement
apprendre plus de choses ? Généralement, ça va vous éviter de vous mettre dans une
situation de confort, de sortir de votre zone de confiance directement et se mettre dans
des conditions où pas forcément être complètement à l'aise.
Et ça, c'est hyper important pour pouvoir apprendre des choses.
D'une part, d'un point de vue fort, on va dire sur vous la manière d'appréhender
les choses et sortir un petit peu du train-train quotidien qui finalement par la routine devient
très facile, en tout cas confortable.
Et puis de l'autre côté, ça va permettre aussi de toucher à des choses que vous n'auriez
pas forcément touché d'habitude.
Et si vous vous sentez moins à l'aise dessus, généralement, vous n'allez pas forcément
avoir le réflexe de les choisir.
Donc ne pas se mettre cette barrière-là, c'est quelque chose qui est très important.
Prendre des risques, se mettre dans un contexte de production et généralement, le debug.
C'est quelque chose où on va apprendre beaucoup de choses.
Pourquoi ? Parce que débugger quelque chose, c'est vraiment être sur un cas relativement
précis et ça va nécessiter assez souvent le fait d'avoir à parcourir pas mal de
choses dans les logs, lire des logs.
Et lire des logs, c'est une opportunité.
C'est-à-dire que vous allez avoir des logs d'erreurs qui ne sont pas forcément générés
très souvent et que finalement, peu de personnes vont avoir sous les yeux l'occasion de décortiquer
comme ça.
Vous allez avoir des cas de figure qui se produisent des fois, une fois tous les deux
ans.
Donc, ça veut dire que toutes les personnes qui sont passées avant vous pendant deux
ans n'ont pas eu de l'occasion de voir ce type d'erreur, ce type de log.
Et vous avez la chance, entre guillemets, de pouvoir rencontrer ce type d'erreur.
Alors certes, sur le moment, ce n'est pas forcément très agréable, mais c'est l'occasion
de rentrer un peu plus dans le détail des choses, d'aller chercher de la documentation,
de parcourir des questions, réponses, etc.
Et ça, c'est extrêmement intéressant pour votre progression personnelle.
Donc, ça, c'est quelque chose qui est important.
Et faire ça, bien sûr, en production, ça met une petite pression supplémentaire, bien
sûr, une petite ou une grosse pression supplémentaire.
Ça, c'est aussi le paramètre qui est important.
C'est-à-dire, on peut débuguer des choses en mode développeur, etc.
Donc, effectivement, si vous avez des équipes de développement qui sont bloquées et que
c'est vous qui avez l'occasion de travailler sur la situation, ça, c'est intéressant.
Mais si vous êtes dans le domaine de la production, c'est encore plus intéressant parce que derrière,
voilà, vous allez être vraiment du concret, du cas de figure qui peut potentiellement se répéter ailleurs.
Et ça, c'est vraiment extrêmement cool.
Moi, le cas de figure qui a été hyper intéressant pour moi, ce n'est pas que ça m'a fait progresser,
pas forcément technologiquement parlant, mais j'étais sur une infrastructure à forte pression.
C'est-à-dire que la perte de quelque chose pendant quelques secondes,
c'était des millions, des dizaines de millions qui tombaient,
quoi, une infrastructure, un type d'infrastructure relativement rare.
Et ça, c'était pour moi une opportunité.
Par contre, tout ce qu'ils faisaient sur cette infrastructure, c'était forcément manuel.
C'est-à-dire, on se refusait tout automatisme, non pas à côté ops, mais côté hiérarchie,
parce que voilà, on ne voulait pas prendre de risque de déployer à large échelle des choses.
Et moi, qu'est-ce qu'il s'est passé ?
Un jour, on m'a demandé de monter sur plus d'une cinquantaine de machines un point de montage.
Et pour moi, c'était hors de question que je fasse ça manuellement,
hors de question, même avec un script bashe.
Pour moi, c'était quelque chose que je ne souhaitais pas faire de cette manière-là.
Je connaissais suffisamment bien Antibol pour le faire avec Antibol.
On avait un accès XSH, il n'y avait pas de raison de faire autrement.
En plus, j'avais les arguments qui pouvaient jouer en ma faveur dans ce sens-là.
C'est que je me disais, voilà, en Antibol, en plus, c'était important.
Imaginons que sur les cinq ans de machines,
j'en ai quelques-unes où ça ne se passe pas forcément très bien.
Je peux relancer une deuxième fois en intégralité sur toutes les machines
et je n'aurai aucun risque de perte.
Et bien, j'ai préparé les choses, mais la pression étant,
je l'ai préparé vraiment très, très finement.
C'est-à-dire, bien sûr, j'ai prévu le rollback en cas de problème,
mais j'ai aussi prévu différents cas de figure.
J'ai prévu le cas où les processus utilisaient des fichiers dans ces montages.
J'ai prévu différents cas de figure et essayer de prévoir le maximum de choses.
Et ça, c'est le moment où on va creuser les choses plus que de la coutumer.
Et ça, c'est extrêmement intéressant.
Mais de toute façon, là, on n'est pas vraiment dans le mode debug,
mais on était sur le mode production qui était vraiment pour moi extrêmement important.
Les autres cas de figure où j'ai appris, comme je dis, c'est vraiment le debug.
Le debug, c'est quelque chose qui est extrêmement intéressant.
On retrouve des ingénieurs de production qui pratiquent assez régulièrement
le trouble-shooting également.
Et je trouve ça vraiment, il faut le vivre comme une opportunité.
Ce n'est pas forcément sur les technologies et plus qui coûtent l'ole.
Et c'est super sympa, la grosse hype et tout ce qu'on veut, du Kubernetes, etc.
Non, non, trouble-shooter, c'est parfois aller juste consulter des logs, lire les logs,
faire des interprétations, remonter des chaînes de choses qui sont relativement chainées,
les unes avec les autres.
Et ça, c'est extrêmement sympathique.
Ça, c'est d'autant plus valable aussi également dans le domaine des bases de données également.
Vous allez pouvoir voir des points difficiles que d'autres n'ont pas forcément rencontré.
C'est ça qu'il faut vraiment se dire.
C'est-à-dire que le bug qui se produit une fois tous les deux ans, trois ans,
et qui est relativement rare, peu de gens finalement le rencontrent.
Et ça, c'est une opportunité pour vous.
Voilà, donc c'était un bref podcast sur cette notion de debug.
Il y a des gens qui excellent dans ce domaine.
Moi, je ne suis pas bon, je vous le dis tout de suite dans ce domaine.
Je pense que d'ailleurs, il y a une force de caractère, un type de caractère,
un type également de personnes qui sont douées dans ce domaine-là qui est le debug.
Je trouve que c'est une qualité extrêmement intéressante dans une équipe.
Il y a des gens qui excellent dans ce domaine-là.
Et je trouve que c'est bien d'avoir au moins une personne de ce type dans une équipe.
Ça crée un certain confort au sein de l'équipe parce qu'on sait qu'on a cette personne qui,
quoi qu'il arrive, il y a des gens, même s'ils ne connaissent pas les technologies,
on va leur demander de débugger.
Ils vont être à l'aise parce que c'est ce domaine-là où ils savent rechercher,
aller dans les détails, même s'en connaitre les couches logiques de l'ensemble des éléments.
Et ça, je trouve que c'est une qualité qui est extrêmement remarquable,
assez rare parce que je n'ai pas rencontré tant de gens que ça qui ont cette qualité-là.
De la même manière que j'ai rencontré des gens qui avaient des qualités assez
extraordinaires en matière de développement, de toucher à plein de technologies,
de faire des choses relativement complexes, de la même manière,
j'ai rencontré aussi peu de personnes qui ont cette qualité de débug.
Et c'est une vraie et réelle qualité parce que généralement,
il n'y a pas 36 personnes qui ont ces qualités-là.
Et au sein d'une société, généralement, on va faire appel ensuite à ces personnes-là.
Donc, c'est des personnes qui ont une ressource et une valeur, une plus-value assez importante.
Voilà. Donc, n'hésitez pas à vous abonner au podcast,
découvrir la chaîne d'Exavki si vous ne la connaissez pas encore.
Et moi, je vous dis à très bientôt.
Ciao à tous !