Il y a à peu près 10 ans, je rentrais sur le marché du travail en tant que jeune développeur. À l'époque, le monde de l’IT commençait à esquisser ce que nous prenons aujourd’hui pour acquis.
Il n’y a pas si longtemps, des termes tels que Cloud ou BigData relevaient plus de la disruption que d’un lieu commun. Parler de conteneurisation était le meilleur moyen de gagner le badge de geek, et les approches Microservices vous rendaient instantanément Chief Architect Of The World.
En tant que développeur Java, junior qui plus est, un monde d’infinies possibilités s’étalait devant moi et j’en avais à peine conscience. Pourtant, avec le recul, les enseignements majeurs que je retiens sont moins du côté technique que du côté humain.
Cette décennie a certes été faite de rencontres technologiques, mais c’est à travers un certain nombre de situations que j’ai tiré les enseignements qui m’ont aidé à entretenir la flamme de la passion pour mon, voire mes métiers.
Je souhaite en partager les principaux pour aider le lecteur à pousser sa réflexion sur ses expériences personnelles et pourquoi pas la partager par un médium ou un autre.
Il est assez fréquent dans nos métiers d’invoquer les “bonnes pratiques” ou le “bon sens” comme arguments ultimes quant à l’adoption de tel ou tel pattern ou langage. Sans parler des conclusions tirées sur des cas particuliers. Anecdotique sur une conversation de coin de table, cette volonté d’avoir raison aura des conséquences difficiles à assumer sur une orientation produit.
Certes, vous ne risquez pas grand-chose à affirmer qu’une approche Microservices est la bonne. Si tel géant du Web l’a employé pour atteindre son niveau de disponibilité, c'est que vraisemblablement il faudrait en faire de même. Et puis, vous vous êtes fait l’ambassadeur de cette nouvelle approche, la remettre en cause serait donc une remise en cause personnelle.
Ne pas savoir mettre son égo de côté peut avoir des conséquences que vous devrez assez souvent assumer.
Il faut voir dans “chercher le vrai”, cette capacité à vous remettre en cause, à interroger la situation dans laquelle vous êtes et comprendre qu’un dialogue va dans les deux sens. Comprendre le raisonnement de votre contradicteur et potentiellement l’adopter, voire l’enrichir s’il s’avère assez solide est un bon moyen de progresser.
Il ne s’agit pas de perdre un débat, mais d’y participer et de l’enrichir. Toutes choses égales par ailleurs, dans une telle approche, dire “je ne sais pas” est tout à fait envisageable et parfois une conclusion.
Il m’est arrivé de voir en rayon un livre au titre volontairement provocateur de “l’art subtil de s’en foutre”. Livre que je n’ai pas lu et catégorisé dans la catégorie bien américaine des livres d’affirmation de soi, il n’en reste pas moins qu’il m’a évoqué certaines situations. J’insiste sur le terme “subtil” du titre pour bien préciser mon propos.
La plupart du temps, nous faisons face à des situations d’urgence permanente au point que l’expression “c’était pour hier” est devenue monnaie courante pour répondre à la question du temps imparti pour un projet. Pourtant, ce point n’est jamais accompagné de justification claire et dans la majorité des cas, il s’avère que le délai n’était relativement pas urgent.
Cette méthode qui consiste à tout présenter comme urgent pour gagner en crédibilité est en réalité le meilleur moyen de faire échouer un projet.
C’est le rôle du Product Owner / Manager de gérer cet aspect avec l’aide des profils techniques qui se doivent eux-mêmes d'émettre des critiques aux priorisations. Dans le meilleur des mondes, cette synergie fonctionne, mais le business peut assez rapidement prendre le pas sur des problématiques réelles telles que la haute disponibilité, résilience, sécurité, productivité des développeurs, etc. Un profil technique se doit de faire entendre sa voix, et parfois faire abstraction d’une “urgence”, pour trouver une solution temporaire et libérer du temps sur ce qui doit être traité.
Cela dit, il ne s’agit pas de renverser les rôles pour imposer une feuille de route axée uniquement sur les aspects techniques. Les profils techs peuvent assez vite enfermer le débat des évolutions futures à des préalables hors sols vis-à-vis du temps imparti. Au même titre que le métier peut prioriser selon un agenda purement métier, le profil technique peut lui-même oublier que la technique peut parfois attendre.
Cette dernière décennie a vu l’influence du réseau LinkedIn croître exponentiellement dans le domaine tertiaire. Initialement pensé comme un réseau professionnel, il a peu à peu pris la forme d’un réseau social se faisant le vecteur d’une certaine vision de la réussite dans le monde du travail centrée autour de la méritocratie et du “mythe de l'entrepreneur”.
Cela contraste néanmoins fortement avec la perception que nous avons de ce même monde du travail à travers nos interactions quotidiennes. Plutôt que de créer de l’inspiration, on pourrait même se demander si cela n’est pas source de frustration pour celles et ceux qui n'auraient pas eu “l’idée du siècle” dans leur garage et ainsi pouvoir passer sur BSmart en visio depuis Dubaï.
Ce genre de discours qui pousse à la performance est de mon point de vue une distraction plus qu’autre chose. Savoir choisir ses objectifs professionnels en y appliquant de la tempérance n’en procure pas moins de satisfaction tout en étant accessible. Il y a peut-être même plus d’ambition dans cette tempérance que dans la soumission à une sorte de diktat des influenceurs.
Ce genre de raisonnement provoquera sûrement la moquerie de ces derniers qui confondent hâtivement modestie avec médiocrité.
On peut néanmoins penser qu’elle pousse la réflexion plus loin que le genre de lieux communs qu’on nous sert tel que “En visant les étoiles, j’ai atteint la lune” ou “Ils ne savaient pas que c’était impossible, alors ils l’ont fait”. Tout un programme…
Il y a quelque temps, il était courant d’évoquer le syndrome de l'imposteur dans le monde de l’IT dans un élan de catharsis collective pour enfin se convaincre que la connaissance se travaille et n’est pas innée (et au passage que le salaire est mérité). Je pense toutefois qu’il faut moins se méfier du manque de confiance qui se règle avec l’expérience que de son excès inverse, à savoir douter de tout sauf de vous-même.
L’expertise peut trop facilement se ramener à un sentiment plutôt que des connaissances objectives portées par une expérience de terrain. La multiplication des certifications, ce nouveau commerce des indulgences, n’aide pas.
Aujourd’hui, il est factuellement simple de sortir d’école avec le titre d’expert apposé par un éditeur ou autre fournisseur Cloud. C’est jouer sur l'ambiguïté du terme “expert” qui peut certes dénoter d’un “prêt à penser” relevant d’un arbre de décision que vous connaissez sur le bout des doigts, mais dont les limitations apparaîtront sûrement avec le temps et les technologies qui avancent.
Autre point de vue, l’expertise c’est la capacité à faire évoluer vos sujets, à s’appuyer sur une expérience de terrain qui suggère des directions à creuser et des liens avec d’autres technologies qui ne demandent qu’à être intégrées. On peut tout à fait être expert en sortant d’école donc, mais cette vision réduit cette fois-ci fortement le nombre de candidats.
L’important à comprendre est que l’expertise se travaille sur la durée en se remettant en cause en permanence. Par vous-même et par vos pairs (cf. “Chercher le vrai plutôt que la victoire éphémère”).
Dans une interview donnée par Antonio Goncalves, nous évoquions le concept de “fatigue” lié à la profusion de services, technologie, next big things, dans laquelle nous baignons. Il s’agissait de comprendre comment accepter ce fait. Non pas pour en sortir démotivé, mais pour se forger une approche et une discipline à même de nous en donner une maîtrise.
Cette approche doit tenir compte de la limitation de notre temps et surtout de celui sur lequel nous pouvons rester concentré.
Des arbitrages doivent donc avoir lieu selon l’objectif visé. J’aime reprendre la catégorisation suivante de la connaissance : il y a ce que nous savons, ce que nous savons ne pas savoir et ce que nous ne savons pas ne pas savoir. S’il était possible d’illustrer la part de chacune sur la surface d’un cercle, la première représenterait un point, la seconde une tâche et la troisième tout le reste. Dans les métiers très mouvants de la tech, il est très important de réduire au maximum la portion occupée par cette troisième catégorie pour faire grandir la tâche du “ce que nous savons ne pas savoir”. Le temps étant une ressource finie, il y a des stratégies à implémenter et cela dépend fortement du domaine de métier, de l’ambition ou, plus terre à terre, de votre situation personnelle (avec ou sans enfant, jeune étudiant, …).
Cette stratégie sera donc amenée à évoluer avec le temps, mais doit faire l’objet d’arbitrage en connaissance de cause. J’illustre ci-dessous mon approche sous un format pyramidal : plus la surface est grande, plus elle représente “en quantité”.
L'adage “choisir, c’est renoncer” a ceci d’intéressant qu’il rappelle qu’on ne peut pas tout faire, quelle que soit la motivation initiale. Nous devons tous composer avec des limites physiques et temporelles. Pour autant, cela doit-il nécessairement nous restreindre dans ce que nous pouvons apprendre ?
Les métiers et en particulier ceux du domaine de la tech se basent énormément sur les échanges. Nous ne sommes jamais tout à fait seuls dans notre coin. Ainsi, nous ne sommes pas obligés de prendre à bras le corps un sujet pour y monter en compétence. La notion de délégation invoquée n’implique pas de relation hiérarchique, mais plus de comprendre que d'autres personnes peuvent et vont nous aider dans notre montée en compétence. Directement entre collègues ou indirectement par des vidéos, podcasts ou articles de blog.
À nous derrière de poser les bonnes questions, de challenger l’expertise, pour se faire notre propre idée du sujet sans pour autant le maîtriser bout en bout.
Rien n’est immuable. Pas même les connaissances. Il s’agit moins d’affirmer que nous oublions les choses que l'évolution et l’enrichissement de nos connaissances. Une approche Microservices d’aujourd’hui sera différente d’une approche homonyme d’il y a 10 ans. Pourtant, nous emploierons le même terme pour penser les concepts.
Le problème du langage oral est qu’il a du mal à capturer l’évolution des concepts et nous donne l’illusion que le badge d’expert est gagné à vie.
Pour rester pertinent dans sa compréhension de ce que l’on pense acquis, il est important de revenir sur ces concepts de temps en temps en profitant par exemple d’un besoin en mission ou en feuilletant votre livre O’Reilly d’il y a quelques années. Parce-qu’entre le moment où vous appréhendez un concept et votre retour dessus, un certain nombre de choses auront influencé votre connaissance sans que vous ne vous en rendiez compte. L’essentiel devient alors d’activer cette prise en compte.
Pour ressentir ce changement de perspective, il est important de le favoriser, car il n’émerge pas simplement du temps qui passe.
C’est par vos lectures, vos discussions, votre implication dans le domaine que viendra une meilleure accroche des sujets et commencera à venir l’expertise.
Nous nous sommes tous fait au moins une fois la remarque sur la qualité d’une architecture ou de code produit par nous même quelques années en amont. Plutôt que d’en être confus, il est préférable d’y voir une évolution personnelle vers une meilleure compréhension du sujet et in fine un réel accomplissement.
Plusieurs lectures à des moments différents permettent une compréhension profonde
Définissons le buzz word comme étant un mot ayant pris plus d’importance que le sens qu’il porte. Microservices et Datamesh en sont de bons exemples. Il est assez courant dans nos métiers de les employer pour faciliter les discussions, voire flatter nos égos. Le fait est que nous ne sommes pas dans la tête des gens et qu’à un moment donné, il faut s’assurer que nous parlons de la même chose.
Cela passe par comprendre soi-même de quoi l’on parle. Il ne s’agit pas de devenir expert du sujet, mais de répondre à un certain nombre de questions qu’on peut illustrer par la liste suivante : À quel besoin répond-on ? Quelles sont les solutions apportées ? Quelles en sont les limites ? Quelles implémentations existent ? Quand les employer ?
Autre symptôme de ce manque de perspective : nous raisonnons volontiers autour de noms de services ou d'outils sans tout à fait les comprendre. Bien sûr, l’usage d’un outil ne nécessite pas une étude systématiquement poussée, mais le choix judicieux de quelques services/outils donnera beaucoup plus de profondeur dans vos argumentaires sur le choix de telle ou telle technologie tout en vous apportant une étanchéité aux buzz words et autres effets de mode.
À terme, vous verrez des réponses communes revenir d’un outil/service à un autre et comprendre que les concepts sont finalement plus proches qu’à première vue. Cela vous aidera à monter rapidement en compétence, fort de votre compréhension macroscopique.
Par exemple, pouvez-vous faire le lien entre une architecture hexagonale qui relève du Software Design et le concept du Service Mesh qui relève du monde opérationnel ?
Il s’agit d’éviter de raisonner ainsi
Le système scolaire nous habitue (nous a habitué ?) à la définition de l’autonomie comme étant de faire les choses seule. Le problème de cette approche est qu’elle est trop ambiguë pour que des enfants ou adolescents aillent plus loin que le premier degré de ce postulat. En réalité, nous oublions trop rapidement que nous ne sommes pas seuls et que nous pouvons effectivement solliciter les gens… par nous-mêmes (seuls, donc).
Je préfère par conséquent la définition suivante : “Être autonome, c’est savoir lever la main quand on ne sait pas”. Dans le monde de l’IT, cela prend d’ailleurs un sens particulier que nous avons tous entendu au moins 1000 fois : RTFM.
Certes, nous pouvons solliciter des personnes, mais nous avons à disposition une infinité de ressources qui ont par ailleurs énormément gagné en qualité ces dernières années. Si les incompréhensions persistent, alors il sera temps de solliciter les sachants du domaine.
Plus le temps passe, et plus il m’est simple de reconnaître que je n’ai pas compris avec toujours cette volonté d’aller chercher l’information et au passage challenger l’expertise. C’est un gain de temps évident et un moyen simple de monter en compétence.
Conseil le plus évident et peut-être le plus déterminant. Je l’ai donc gardé en conclusion.
Nous connaissons tous l'adage “C’est en forgeant que l’on devient forgeron”. Certes, mais soyons plus explicite. C’est en appliquant des connaissances au-delà du basique que vient la connaissance profonde d’un sujet. Terminer un bouquin technique ou avoir un badge d’expertise est différent d’une expérience de production, l’écriture d’article de fond ou de tests dans les retranchements d’un outil.
C’est bien ces derniers cas de figure qui rendent votre profil unique, celui-là même qui voit les problèmes venir, qui sait s’en prémunir, et pour qui le pragmatisme est maître mot.
On remarquera d’ailleurs que l’un nourrit l’autre dans la mesure où c’est parce que nous bloquons sur un problème donné que nous ressentons le besoin de formation qui amène de nouvelles compétences à faire dialoguer avec celles déjà acquises.
Il est difficile d’être exhaustif lorsque l’on doit résumer plusieurs années de carrière en un seul article. Ce que j’ai partagé ici mérite sûrement des précisions, mais gageons que le niveau de détail suffit à rendre explicite l’esprit de ce que je tente de partager : un ensemble de lignes directrices qui m’ont paru les plus pertinentes ces dernières années afin de cadrer l’approche que j’ai sur un métier qui est en constante évolution.
On remarquera que ces points sont loin d’être spécifiques aux métiers de l’IT et pourraient avoir une grille de lecture intéressante dans d’autres domaines.
N’hésitez pas à partager vos retours d’expérience en commentaires dans le but d'enrichir cet article dont la vocation est d’inspirer la montée en compétence de toutes et tous.