Like any experienced engineer, I understand the desire to build the best, most flexible and robust system for every project. I do. But I also understand the common business constraints of every project: time and money. Most projects have a definite deadline and/or a specific budget that must be met and, often times, building something grand is just not feasible within either them. This is where the developer must make a conscious decision to limit creativity to meet the goals. There is no excuse for spending a week to setup a "proper" caching layer for database queries on a 20-row table, that is only used from the administrative panel by three publishers. Understand the use cases. As cool as it may be to build a flexible and expendable XHR framework to support variable simultaneous requests; you don’t need to invest in it if the only feature that will be using it is an update to a visitors counter on one page. Understand the scope. I cannot stress it enough: a good engineer is not the one who knows how to build the most advanced system, but the one who knows when not to build that system.
Il s’agit d’un manifeste engagé qui fait état de mes réflexions actuelles sur le métier de développeur, il est amené à évoluer dans le temps :
De l’utilité plus que de la qualité,
De l’expérimentation plus que du troll,
De la convivialité plus que de l’exhaustivité,
Du partage plus que de la mise en ligne,
De l’inconfort plus que de la sécurité,
De l’économie plus que de la performance,
Du savoir-être plus que du savoir-faire.
Utilité
J’ai eu l’occasion de développer des produits de qualité. J’ai aussi eu l’occasion de développer des produits utiles. Étrange d’opposer les deux et pourtant j’ai rarement pu avoir les deux à la fois. Et rétrospectivement, ce sont clairement les produits utiles qui ont donné du sens à mon savoir-faire. Un code de (sur-)qualité n’aura pas forcément une durée de vie plus longue mais il y a de grande chances qu’il mette beaucoup plus de temps à sortir, ce qui met en péril le projet — aussi utile soit-il.
Expérimentation
Les développeurs passent (perdent ?) beaucoup trop de temps à discuter de technologies sans même les avoir essayées. Prenez React par exemple, il serait facile de troller sur le fait qu’introduire du HTML directement dans du JS est une hérésie et pourtant après quelques heures de pratiques ça devient beaucoup plus pertinent. Et je prends du fun à coder avec ; sans me préoccuper des design patterns et autres best practices, il faut savoir lâcher prise et avancer à son rythme.
Convivialité
J’ai déjà eu l’occasion d’exposer ce que j’entendais par Open-Source conviviale et mon désir de rendre l’informatique plaisante. Je suis fatigué des frameworks que l’on sort systématiquement pour publier une page statique, de ces bibliothèques qui cachent un manque de compréhension du langage et de toute la complexité dans laquelle s’enferme le développement Web sur l’autel de son industrialisation. Il faut savoir revenir à la base : du contenu, des liens et des interactions.
Partage
Le partage va plus loin que de la solidarité entre développeurs, il y a une notion d’apprentissage et de retour d’expérience. Libérer son code est une chose, expliquer ses choix d’implémentation, ses échecs et les leçons apprises est autrement plus intéressant. Github et Stack Overflow sont les fast-foods du code, je veux prendre le temps de raconter ma recette et l’enrichir avec d’autres.
Inconfort
Plus un milieu est changeant, plus il en va de sa survie d’explorer et de s’adapter rapidement ; c’est difficile à accepter mais le confort d’aujourd’hui est la mise au rebut de demain dans un domaine comme le Web. Il ne s’agit pas forcément d’aller dans le sens du courant mais d’avoir la curiosité de découvrir de nouveaux domaines et le goût d’explorer de nouveaux concepts. Sortir de sa zone de confort est ce qui rend ce métier si stimulant.
Économie
La création d’usines à gaz génère forcément un gaspillage numérique non négligeable. On construit des 4x4 numériques dont on essaye d’optimiser la consommation alors que l’on aurait besoin de simples vélos ! De bons défauts sont l’une des conditions pour obtenir un produit minimaliste qui soit pertinent mais ne suffisent pas, il faut avoir une évolution culturelle et une démarche de co-création.
Savoir-être
Enfin, je n’ai pas envie de travailler avec un gourou, un ninja ou une rockstar. J’ai envie de collaborer avec quelqu’un à l’écoute, qui sait faire preuve de diplomatie dans sa critique, qui arrive à me faire douter sans forcément passer par la confrontation. La sur-compétence technique est contre-productive à toute forme d’échanges car elle crée un déséquilibre malsain.
Est-ce que ce manifeste fait pour autant l’apologie du code-poubelle codé à la RACHE™ ? Je ne pense pas. Il s’agit avant tout de revenir à un développement responsable qui donne du sens à notre métier et aux relations que l’on peut avoir avec nos pairs.
