Tout le dev il est facile tout l’outil il est super

En relisant les deux articles que j’ai pour l’instant consacré à du développement, j’ai réalisé que j’avais, sans même y avoir pensé, produit quelque chose d’éminemment transgressif par rapport à la norme des articles sur le sujet : l’aborder sous l’angle de tentatives pas toujours fructueuses de résoudre des problèmes et des erreurs rencontrées ce faisant (et dans le cas de celui sur Divi même de la critique de l’outil utilisé) plutôt que celui de solutions évidentes et de comment ce qui est utilisé est pratique pour les atteindre. Le typique « aujourd’hui je vais vous montrer comment faire tel truc » tout aussi typiquement suivi d’un « regardez c’est facile il suffit de… » et assez régulièrement d’une ode à l’outil/langage/framework ayant permis d’arriver à ce résultat (y compris même quand environ 95% des développeurs dont très probablement l’auteur reconnaitraient en privé que ledit outil est une complète usine à gaz extrêmement désagréable et complexe à utiliser, je me rappelle même d’articles de ce style sur du développement d’application web Java EE fait sur Eclipse, c’est dire).

D’un coté je comprend les mérites d’aller directement à la solution plutôt que de perdre son temps à évoquer tout le cheminement ayant pu y conduire, après tout c’est ce que les gens qui cherchent une procédure pour faire une chose précise veulent trouver, évidemment ils seraient probablement moins attirés par des articles de 20 pages évoquant chaque moment où une faute de frappe dans un nom de variable a tout fait planter.

D’un autre j’ai le sentiment que ça donne une impression très fausse du métier (qui m’évoquerait presque celle que le post moyen sur Linkedin donne du monde du travail en général) et qui n’est pas pour rien dans le mal psychologique dont souffrent énormément de développeurs débutants (et même pas mal de seniors), ce qu’on appelle le syndrome de l’imposteur. Comment avoir confiance en ses propres capacités, pouvoir se présenter les yeux dans les yeux à un recruteur ou client comme un informaticien compétent quand on a une expérience aux antipodes de celles que semblent montrer l’immense majorité des contenus sur le sujet ? L’expérience d’un développeur réel dont la majorité du temps de travail consiste à se confronter à des problèmes et rencontrer des bugs, tenter de les résoudre de diverses manières, sans que ça marche généralement du premier coup, devoir aller se documenter sur les procédures à suivre et souvent n’en trouver que pour des cas de très loin similaires (typiquement 95 tutos auto-satisfaits sur la même chose facile à faire dans un environnement donné, mais bien moins sur celles qui seraient un peu plus ardues ou sur pourquoi les solutions proposées ne marchent pas dans un environnement légèrement différent), passer du temps à adapter celles ci en rencontrant de nouvelles erreurs, pester sur le langage/framework/outil utilisé qui n’avait rien prévu de facile pour tel ou tel cas de figure, finir par se développer des librairies entières de fonctions destinées à contourner ses faiblesses, se retrouver à passer deux jours sur un travail qu’on estimait à une heure, etc. En fait le contenu moyen sur le développement informatique peut facilement en finir par être, pour celui qui se confronte à sa réalité ce que la photo retouchée d’influenceuse Instagram ou autre défilé de top-models peut être à la femme d’apparence ordinaire (ou un film avec Rocco Siffredi à la plupart des hommes), une source infinie de complexes.

Et aussi pour d’autres, qui n’ont pas encore franchi le pas de s’y mettre, un risque de passer à coté de ce qui fait finalement une grande partie de l’attrait de cette discipline. Le coté défi intellectuel, la nécessité de faire appel à une certaine inventivité pour arriver à un résultat voulu en s’adaptant aux contraintes de son environnement de développement, la possibilité d’être créatif et d’y parvenir de dizaines de manières différentes, l’attrait qu’il peut y avoir à trouver d’abord une solution qui ne soit pas optimum à un problème, puis de version en version de l’améliorer ou d’en tenter d’autres jusqu’à parvenir à la plus efficiente. Le développement est en fait une activité bien plus passionnante que ne le laisseraient imaginer ceux qui le présentent sous l’angle de recettes toujours « faciles » et standardisées qu’il suffirait d’appliquer grâce à des outils systématiquement merveilleusement adaptés. 

Le pire c’est que beaucoup qui réalisent des tutos et autres comptes rendus de projets en en gommant toutes les aspérités doivent être parfaitement conscients qu’elles existent. Très probablement ils ont batailléEnfin hors ceux qui ne font que paraphraser les contenus des sites des outils qu'ils utilisent, de tutos déjà réalisés par d'autres ou commenter des solutions maintes fois postées sur Stackoverflow ou Github, quand ils ne font pas carrément rédiger problème, solution et commentaire par un chatbot. Je ne donnerai pas de noms de vloggeurs spécialisés connus mais quelques uns devraient peut-être songer à créditer à l'occasion les sources qu'ils plagient honteusement. x heures/jours sur un problème, à la recherche de la solution la plus irréprochable possible à présenter, avant d’en tirer la vidéo Youtube de 15 minutes ou l’article de 300 mots qui fera apparaître la manière de le résoudre à laquelle ils ont abouti comme évidente et facile (et l’outil utilisé fabuleux, même s’il a en fait allongé le travail préalable de x heures par rapport à d’autres). J’en suspecterais même quelques uns de souffrir eux-mêmes d’un certain syndrome de l’imposteur, et d’être en train d’essayer de le surmonter en cherchant à se convaincre autant que leur public qu’ils ont atteint un degré de compétence où tout deviendrait facile, tout en gommant de leur mémoire les moments moins glorieux ayant conduit à ce succès.

Après ça ne veut pas dire que quant à moi chaque fois que je vais parler de développement je veillerai à évoquer le moindre problème rencontré, et à me montrer aussi critique que possible des technologies utilisées. Là j’avais deux sujets qui s’y prêtaient, l’un dont tout l’intérêt était d’évoquer une méthode de résolution de problème, l’autre sur un premier travail sur un thème WordPress que je ne connaissais pas, et s’étant avéré bien plus ardu qu’imaginé au départ. Si demain je consacrais un article juste à indiquer quelques trucs et astuces que je connais depuis une éternité ou autre méthode sur laquelle je n’ai rencontré aucun problème particulier je n’irai pas me forcer à en inventer.

Mais dans les cas où parvenir à une solution s’est avéré plus ardu, je verrais presque comme un devoir de ceux qui l’évoqueraient de mentionner un minimum le cheminement qui y a conduit, combien de temps ça leur a pris, quels principaux problèmes ils ont rencontréCe qui serait au passage beaucoup plus utile aux gens allant se documenter précisément car ils les rencontrent dans le cadre d'un développement déjà commencé. etc. que de donner une idée fausse du métier en faisant comme si ces étapes n’existaient pas à coups de « c’est facile il suffit de… » (et pour consommer x articles sur des questions de développement, ou tutos vidéos sur le sujet par semaine, c’est facilement 90+% des contenus qui sont dans ce mode) et de publicités gratuitesEnfin pas nécessairement toujours dans le cas des vloggeurs spécialisés, qui peuvent aussi faire le métier d'influenceurs. pour des technologies rarement imperfectibles.