Il arrive un moment dans l'exercice d'une tâche technique où les détails deviennent des automatismes. Je ne sais pas vous, mais j'ai depuis longtemps oublié la séquence suivant laquelle les muscles de mes jambes doivent se contracter/relâcher pour exécuter un mouvement de marche.
On me demande souvent ce que je fais comme métier. Pour simplifier, je dis que j'écris du code pour faire des sites internet. Je n'aime pas dire que je suis développeur, parce que j'ai l'impression que le terme nie la dimension créative de ce que je fais toute la journée (et parfois le soir pour mon plaisir) pour en faire un boulot de technicien purement exécutant. Or j'ai l'orgueil de croire qu'aucune machine ne pourra jamais remplacer mon travail, du moins pas totalement. Ce que la machine pourra/peut remplacer, lorsque je dois l'accomplir, m'emplit en général d'une frustration immense et source de la majeure partie de la fatigue qui me fait m'effondrer sur mon lit comme une masse en rentrant chez moi le soir.
On me demande comment, ce travail, qui est perçu comme technique peut être créatif. On me demande si je parle de design, de graphisme. Je ri dans ces cas-là, et je réponds qu'absolument pas du tout, je suis probablement la dernière personne au monde à qui il faudrait confier une tâche de graphisme. Non, je parle bien de créativité dans le code. Et je donne cet exemple : Un ordinateur, c'est un tas de plastique, de cuivre et de silicium qui, à peu de chose près, ne sait rien faire. Le peu de chose se résume à comprendre les instructions suivantes : enregistrer des nombres et des textes dans sa mémoire, lire ces nombres/textes dans sa mémoire, tester si deux nombres sont égaux ou non. Ça n'est pas grand-chose, mais ça suffit amplement pour tout faire. Tout comme indiquer un chemin pour se rendre d'un point à un autre revient à donner une suite de directions en fonction de lieu que le touriste devra reconnaître. Et tout comme il y a mille manières plus ou moins coûteuses (en temps, en argent), plus ou moins agréables, plus ou moins flexible (si le touriste veut faire un détour par un lieu de son choix) de choisir un itinéraire dans une ville, il y a mille manières de donner des instructions à un ordinateur pour qu'il accomplisse ce qui est désiré ("afficher par ordre de prix les vols en partance de Paris à destination de Florence le jeudi 11 novembre").
Mon métier consiste donc à ça : donner des suites d'instructions à une machine pour qu'elle les accomplisse de la manière la moins coûteuse (en temps et argent), la plus lisible et la plus flexible.
Lorsque j'avais parlé à la conférence PHP l'an dernier (ou était-ce l'année d'avant, je n'ai aucune notion du temps), j'avais insisté sur le fait que la notion de flexibilité était extrêmement relative. On voit souvent aujourd'hui, les clients demander à ce qu'on utilise des "outils open-source avec un large public" sous prétexte qu'en faisant ces choix, l'objet final pourra être repris par d'autres personnes immédiatement. C'est un leurre. La capacité d'un code à être repris dépend selon moi de la capacité du code à pouvoir être expliqué par un programmeur expérimenté en langage humain à quelqu'un qui n'a absolument aucune notion d'informatique, voire de logique élémentaire ET de la capacité du code à pouvoir être modifié sans changer fondamentalement sa structure selon les demandes de l'humain "normal" (pourvu que cette demande ne soit pas un changement radical). Il est évident et tout à fait normal que l'être humain non expérimenté ne comprenne rien au code. D'une part parce qu'il ne parle pas le langage, d'autre part parce que même si il le parle un peu, la traduction langage naturel-code la plus naïve est rarement la plus efficace et la plus flexible et n'a donc pas été retenue par le codeur expérimenté.
Fidèle lecteur de nombreux blogs sur les bonnes pratiques de code, il n'est pas rare que j'oublie pourquoi certaines choses sont à faire et d'autres à proscrire et je me retrouve parfois bien en peine de justifier pourquoi une solution me rebute alors qu'elle semble naïvement la meilleure. Je sais que croiser ses pieds (mettre le pied gauche plus à droite que le pied droit) est une mauvaise idée lorsque l'on descend une pente en randonnée en montagne alors même que c'est bien souvent le choix le plus pratique si l'on veut conserver un rythme de marche normal (un pied en avant puis le suivant en avant et ainsi de suite) sur un sentier où les zones stables sont réparties aléatoirement à gauche puis à droite. C'est une mauvaise idée parce qu'à vouloir conserver ce rythme de marche normal, on décuple le risque de se faire une entorse. (cette explication mériterait un petit schéma, mais je ne sais pas dessiner).
Une pratique courante en PHP (le langage que j'utilise professionellement) consiste à ne jamais afficher les erreurs du programme, sauf en cas d'erreur grave qui planterait complètement le programme (par exemple si vous demandez à votre machine de diviser par zéro). Tout le monde le fait, mais c'est selon moi une très mauvaise habitude. Ça revient à indiquer son chemin à un enfant dans une ville en oubliant de lui préciser qu'il ne faut pas traverser quand le feu des voitures est vert. On se dit qu'il va bien comprendre qu'il ne doit pas se jeter sous un bus et attendre que la voie soit dégagée. Sauf qu'en vrai, un ordinateur c'est encore plus bête qu'un enfant, et ça finit parfois mal. Et on blâme alors le chauffard alors même que notre responsabilité est aussi en cause. Lorsque j'avais passé mon entretien chez last.fm ils m'avaient demandé quelle était la première cause de bugs dans les programmes et c'est ce que j'avais répondu, ils avaient ri (j'avais tourné ça d'une manière un peu plus drôle)
Je me rappelle également d'une dicussion sur la terrasse du toit du Théâtre du Châtelet où l'on me demandait pourquoi je détestais tant eZPublish. eZPublish, c'est un outil de gestion de contenu, open-source, utilisé par un large public comme les aime les clients. Et c'est l'archétype parfait (pléonasme) du leurre. Certes, il fait son travail d'outil de gestion de contenu, bien que je n'ai dans mon entourage aucun utilisateur/rédacteur qui en soit un tant soit peu satisfait. Mais pour le développeur qui cherche à faire d'un site simple une véritable application, il atteint immédiatement ses limites : il n'est pas pratique, les outils sont rarement découpés en éléments simples réutilisables ; il n'est pas structurant, le développeur est laissé à lui-même, il n'est nullement tenu de respecter quelconque convention et peut tout à fait pondre quelquechose de parfaitement non-maintenable et obscur; il est contraignant, le développeur doit multiplier les lignes de codes pour parvenir à faire des choses basiques si il veut respecter utiliser les données du CMS. Bref, une horreur. Je suis un fervent défenseur de Zend Framework que je trouve structurant et pratique (bien que parfois un peu contraignant) mais il y a tout un tas d'autres outils bien meilleurs que eZ.
Voilà quel est mon métier, et tous les choix quotidiens qu'il implique. La plupart des choix que je donne ici peuvent sembler d'ordre purement technique, mais ils se résument beaucoup plus souvent à un choix de philosophie de code et de goût. Ce que j'aime, c'est créer du code que mes collègues, lorsqu'ils auront à l'utiliser, trouveront "pratique" et utiliseront sans mal, c'est penser que j'ai travaillé une fois mais que ce travail sera réutilisé tout un tas de fois sans effort par les autres. Et c'est dans cette tâche que joue à plein ce que j'appelle ma créativité.