Développer après 35 ans

Last modified by Charles Sabourdin on 2015/03/05 15:00

Dec 18 2010

Dans un précédent blog, je regrettais qu’il soit présenté comme une mauvaise gestion de carrière que de continuer à développer au-delà de 35 ans. La première raison était le risque de créer une source de démotivation pour de jeunes professionnels, souvent passionnés. La seconde, que je voudrais développer, est que, de mon point de vue, c’est une façon de se priver, pour le développement informatique, de professionnels d’expérience. La chose est tellement évidente que je ne pense pas que les décideurs de ce milieu ne l’ait pas vue. S’il l’ont vue, c’est qu’ils estiment que cette expérience leur est inutile, ou trop cher (ce qui revient au même), que confier des développements à des débutants n’est pas un problème. Dans ce contexte de choses admises, l’activité de développement restera effectivement un travail de débutant, avec les taux de réussite que l’on connaît. 

Un développeur est jugé sur de nombreux paramètres, comme tout ingénieur ou assimilé, qui a la charge de produire quelque chose. Intéressons-nous à deux de ces paramètres : ses connaissances techniques, et son expérience technique. De quoi ces deux éléments sont-ils faits dans le domaine du développement informatique ? 

Séparer les connaissances de l’expérience est en fait très artificiel, car les unes ne fonctionnent pas sans l’autre. Admettons ici (ou supposons) que les connaissances techniques recouvrent l’ensemble de ce que l’on sait des langages informatiques, des API associées, des frameworks construits sur ce langage et ces API, et des patterns d’utilisation tels que publiés par les auteurs de ce langage, de ces API et de ces frameworks. Les connaissances ici sont donc purement documentaires. 

L’expérience, elle, concerne ce que l’on sait de la mise en pratique de telles approches pour résoudre tel problème donné. Une approche recouvre à la fois les patterns choisis, le framework s’il y en a un, les API mises en œuvre et le langage utilisé. 

La quantité et le niveau des connaissances techniques doivent augmenter régulièrement. L’informatique est un domaine dans lequel les techniques évoluent vite, les connaissances que l’on acquiert deviennent rapidement obsolètes, il faut donc les renouveler. Se « maintenir à niveau » consiste à suivre les évolutions de ce que l’on connaît, à détecter le point auquel les choses tombent en obsolescence, et dans le foisonnement des nouveautés, détecter lesquelles vont devenir les technologies dominantes de demain. Maintenir ses connaissances à jour consiste donc à suivre les cycles que connaît toute industrie, faits d’améliorations de l’existant, de réelles nouveautés, et d’abandons d’anciennes techniques. 

Le plus difficile dans cette activité est de comprendre ces cycles, et pour chaque suivi, d’en détecter le début et la fin.
Si détecter la fin de la vie d’un outil ou d’une technique n’est pas le plus dur, il l’est en revanche de l’abandonner, surtout si l’on en est devenu expert. En être capable est pourtant nécessaire si l’on veut continuer à aller de l’avant. S’accrocher trop longtemps à une expertise ne fait que compliquer l’acquisition de nouvelles connaissances, et le passage à l’expertise suivante. Abandonner cette expertise et les revenus qui vont avec peut être d’autant difficile que l’on est attaché à un commercial qui prendra la ligne de plus grande pente pour placer un développeur, sans se poser de questions. Au-delà d’un certain point, il faut bien en faire le constat, il est plus simple d’évoluer librement qu’en société. 

Détecter le début d’un nouveau cycle est à mon avis plus complexe, et c’est précisément là que l’expérience nous vient en aide. Tout d’abord, elle permet de mesurer l’originalité d’un nouvel outil : existe-t-il déjà, comble-t-il un manque dans ma boite à outils, les services qu’il rend sont-ils attendus ? Ensuite, elle permet de mesurer le caractère utilisable d’un outil ou d’une technique. De quelles connaissances ai-je besoin pour mettre cet outil en œuvre, ces connaissances sont-elles partagées par de nombreux développeurs (débutants, rappelons-le) ? Enfin, et ce n’est pas la moindre qualité de l’expérience, elle permet de former son intuition, ce subtil sentiment de prescience qui nous habite lorsque l’on découvre une nouvelle technique ou un nouvel outil. 

Comment alors organiser sa vie professionnelle afin de permettre l’augmentation continue de son expérience ?

La première raison d’être d’une vie professionnelle, du moins pour la majorité des mortels en ce bas monde, est d’assurer un revenu. Les projets que l’on prend en charge nous font vivre, et notre famille avec. Les aspects financiers sont parfois (souvent ?) déterminants. Mais il faut trouver la bonne mesure entre les projets lucratifs, et les projets plus exploratoires, qui vont nous permettre d’acquérir cette expérience indispensable. 

Les formations que l’on peut suivre au cours de sa vie professionnelle permettent-elles d’atteindre ce but ?

Je ne pense pas que ce soit leur finalité. La finalité d’une formation est le plus souvent de combler un déficit de compétence à un moment donné, et pour remplir une tâche donnée, en cours ou prévue dans le proche avenir. De plus, les formations, quelle qu’en soit la qualité, sont le plus souvent disponibles lorsque les outils ou techniques sur lesquels elles portent sont bien installés, c’est-à-dire trop tard pour celui qui veut devancer les choses plutôt que de les subir. 

Je suis convaincu que l’investissement dans des projets personnels, open source entre autres, est un excellent moyen de mettre en œuvre des techniques innovantes avant que les projets en entreprises ne commencent à les utiliser. Google l’a bien compris, en libérant 20% de leur temps de travail à ses développeurs. Peut-être un jour cette pratique se généralisera-t-elle ? 

Comme on le voit, pour continuer ce travail passionnant qu’est le développement informatique au-delà de la date de péremption admise, sa capacité à se prendre en main est déterminante : mieux vaut ne compter que sur soi-même.

Tags:
Created by Administrator on 2010/12/18 09:50
    
This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 6.2.4 - Documentation