index.md 10KB
title: Comment ne pas se laisser dévorer par la veille techno ?
url: http://www.miximum.fr/veille-techno-efficace.html
hash_url: 3a17eb00a6
L'obsolescence des compétences est l'un des dangers qui guettent le vaillant travailleur du Web. Notre domaine d'activité évolue tellement vite, tant au niveau des outils, des méthodes, des pratiques, des technologies… que rester à la page est un défi permanent.
Si, fraîchement émoulu de son école, notre jeune Webie·ne se lancera à corps perdu dans l'apprentissage du x-ième framework Javascript avec un enthousiasme toujours renouvelé, le senior finira peut-être par ressentir ennui et lassitude face à la répétitivité de la chose.
Comment prendre de la distance avec sa veille techno sans pour autant se laisser distancer par le Web ?
Denver, le dernier dinosaure du Web
N'avons nous pas tous déjà rencontré l'un ou l'une de ces vieux schnocks tellement engoncé dans ses vieilles habitudes, ses vieux outils, ses vieilles méthodes, qu'il est devenu incapable d'apporter la moindre contribution utile à un projet moderne ?
Ces dinosaures du Web se sont reposés sur leurs lauriers tellement longtemps qu'on dirait que le monde a continué de tourner sans eux, qu'ils sont restés coincés à une autre époque. Pour un peu, on les verrais porter un haut de forme, priser du tabac et entendrais proférer des expressions comme Diante ! et Morbleu !
Je précise à l'égard de mes éventuels pairs plus âgés qu'il ne s'agit absolument pas d'une question d'années. J'ai connu des ingénieurs obsolètes à 25 ans.
S'ils peuvent encore se rendre utile en se chargeant de la maintenance de projets antédiluviens (coucou le Cobol !), leur intervention sera désastreuse sur les projets récents dans lesquels ils importent leurs sales habitudes et leurs pratiques obsolètes.
C'est encore pire quand ces néandertaliens du code pervertissent les vierges esprits des stagiaires et nouvelles recrues en répandant leurs compétences véreuses comme la parole du messie, et s'arrogent des rôles de décideurs en invoquant des préceptes fumeux tel que le « respect dû aux aînés ».
Bref ! S'il a de la chance, le dinosaure se fait des couilles en or en travaillant sur des projets poussiéreux pour l'industrie financière, mais il finit la plupart du temps dans un placard, là ou il sera le moins nuisible.
Fast and furious veille techno
Si elle est essentielle, la veille techno est exigeante. Parce que oui, tester un nouvel outil, un nouveau framework, une nouvelle librairie, une nouvelle méthode, ça prend du temps (du moins, quand on le fait sérieusement). Et le temps, plus ça va, moins on en a.
Sans oublier le côté répétitif de la chose. Apprendre à utiliser son premier framework Js, c'est fun. Se plonger dans la doc du quinzième, c'est franchement barbant.
à titre personnel, 2014 a été une année charnière. J'ai découvert, un peu étonné, que l'idée de passer un week-end entier à manger des chips et jouer avec une nouvelle librairie Python ne provoquait plus en moi cet enthousiasme, cette drôle d'excitation (oserais-je dire presque charnelle ?) dont j'avais l'habitude. Cette lassitude s'est doublée par une volonté de consacrer plus de temps à d'autres passions.
Une nuit, j'ai fait un cauchemar. Je suis vu moi même, 20 ans plus tard, en cardigan et pantalon en velours côtelé, recouvert par une épaisse couche de poussière, corrigeant des bugs vieux de plusieurs décennies dans des langages depuis longtemps disparus.
Réveillé en sursaut et en sueur, je me suis alors rendu compte qu'il fallait que je change ma manière d'aborder la veille technologique. Voici quelques unes des stratégies que j'essaye de mettre en place.
Donner plus de valeur à son temps
J'avais l'habitude de me lancer dans d'innombrables side projects, parfois sans autre motivation que l'excitation de l'idée, et toujours avec l'inavouable espoir de devenir riche et célèbre. Que d'heures perdues sur des projets jamais terminés !
Aujourd'hui, le temps libre est devenue une ressource (très) rare (et j'exprime mon profond respect à mes collègues qui en plus ont des gosses). Par conséquent, j'essaye de le dépenser à meilleur escient.
Ãa signifie que je ne démarre plus un side project sur un coup de tête. Quand je me lance dans un développement personnel, j'ai laissé mûrir l'idée, défini des objectifs, et je sais à l'avance la valeur que je vais en retirer (cf. plus bas).
Privilégier la qualité à la quantité
Quand une personne sans doute bien intentionnée décide de publier un n-ième clone de Grunt ou Backbone.js, j'avoue que je dois pallier à de pressantes pulsions meurtrières en me gavant de beurre de cacahuètes.
J'ai arrêté d'essayer de me tenir à la page sur la dernière techno à la mode ou le dernier framework top tendance.
Aujourd'hui, si je prends le temps de tester / apprendre un nouvel outil / langage / techno / truc, c'est pour l'une de ces deux raisons :
- C'est quelque chose de totalement différent par rapport à ce que je maîtrise, porteur de concepts qui me sont étrangers, et qui va m'ouvrir l'esprit (Android, Bitcoin, programmation fonctionnelle, etc.) ;
- C'est une techno fiable et mature répondant à un besoin réel et que je vais pouvoir intégrer directement dans ma trousse à outil.
Si je n'apprends rien, je perds mon temps. J'agis en conséquence.
Laisser mûrir les technos
Combien de temps perdu à tester des technos soi-disant révolutionnaires et qui ont fini aux oubliettes de l'e-histoire.
La vérité est qu'une techno récente, quelque soit son aspect novateur, peut rarement être intégrée dans un projet amené à passer en production.
Il y a toujours une phase de défrichage, de maturation, pendant laquelle les early adopters paieront les pots cassés.
Aujourd'hui, j'attends qu'une techno soit mâture avant de m'y intéresser. Par mâture, j'entends qu'elle réponde aux critères suivants :
- la techno est techniquement robuste (pas de bugs en pagaille) ;
- la documentation et les différents tutoriels éparpillés sur le Web permettent une prise en main rapide ;
- il existe suffisamment de retours d'expérience pour que je puisse me faire une idée claire des cas d'utilisation pertinents.
Attacher de l'importance aux retours d'utilisation
J'ai tendance à attribuer de plus en plus d'importance aux retours d'utilisation plutôt qu'à l'aspect technique et fonctionnel de la techno.
Plutôt que de lire des tutoriels techniques, je préfère m'intéresser aux expériences des early adopters. Dans quels cas cette techno est-elle appropriée ou non ? Quels sont ses avantages et ses inconvénients ? Quelles sont ses forces et ses faiblesses ? Quels gains réels espérer, et à quelles galères s'attendre ?
L'exemple emblématique, c'est Docker. Docker, un outil qui permet de faire des machines virtuelles de manière simple et rapide à l'échelle d'un processus. Sur le papier, c'est génial. En démo, c'est étourdissant. En pratique, je n'ai trouvé aucun retour d'utilisation décrivant comment Docker, mis en place sur un projet en production, a enlevé de la complexité au lieu d'en rajouter.
Aller à des conférences, échanger
Le meilleur moyen de discuter avec d'autres travailleur·se·s du Web, c'est encore de trouver un nid.
En l'occurrence, les conférences sont un excellent moyen de cuisiner des dévs, des admin sys, des intés, des agilistes… sur les derniers trucs qui valent le coup qu'on s'y penche.
C'est quoi cette techno ? Est-ce que ça marche bien ? Quels sont les avantages par rapport à X ? Autant de questions qui trouveront plus facilement réponse autour d'un croissant ou d'une bière que derrière un clavier.
Conclusion
La veille techno est un processus essentiel, mais plus le temps passe, et plus le besoin de s'y consacrer avec une certaine efficacité se fait sentir. Faute de quoi, ennui et lassitude finiront par s'emparer de l'ingénieur·e.
Sur ces quelques réflexions, je vous laisse, je vais découper du saucisson.