Cette réflexion commence par un échange avec un ami. Nous trollons sur un sujet stratégique: vaut-il mieux développer en PHP / Symphony ou en Ruby on Rails?
Il argumente que les développeurs PHP sont plus nombreux, ce que je concède. Il marque un point.
J’argumente que trouver un bon développeur Ruby on Rails est plus facile que trouver un bon développeur PHP, ce qu’il concède. Je marque un point.
C’est alors qu’il lance l’estocade finale:
“Oui mais moi je ne cherche pas un bon développeur, je cherche juste un mec qui pisse du code. J’ai juste besoin d’un bon lead dev.”
Je suis terrassé. A court d’argument il remporte le troll.
D’abord je suis émotionnellement atteint. Je déteste cette expression de ‘pisseur de code’. Elle montre une forme de mépris qui déclenche chez moi des émotions désagréables: un mélange de colère et de haine…
Elle renvoie pour moi à l’idée d’un développeur qui n’utilise pas vraiment son cerveau et qui code sans se poser la moindre question.
Le mec qui allonge les lignes de code comme on allongeait les produits sur une chaîne de montage des années 1900.
J’aimerais juste revenir sur le terme: pisseur de code.
La pisse, c’est de l’urine, un déchet pour notre organisme.
T’es vraiment certain d’avoir envie que ton application soit faite avec de l’urine?
Ensuite elle renvoie à une idée implicite qui me dérange encore plus: l’interchangeabilité des ressources. Cela relève du même mécanisme productiviste qu’à l’ère de l’industrialisation: abaisser le niveau de compétence pour tirer sur les salaires. Ce faisant paupériser les artisans de leur savoir faire et les priver de leur liberté pour les aligner dans des usines afin de maximiser les profits.
Sauf que l’industrialisation de notre métier est une chimère héritée du siècle dernier.
Tout d’abord le marché est en notre faveur: le rapport de force est trop déséquilibré. A nous d’en tirer profit pour défendre notre métier tant que le vent souffle dans nos voiles.
Mais surtout cette utopie est le reflet d’une profonde incompréhension de notre travail et de ses enjeux.
Un aspect fondamental du métier
L’ambiguïté vient de ce que notre métier est né dans la famille des sciences dite ‘dures’, perçues comme très rationnelles et ‘carrées’.
Oui.
Sauf que développer est un acte créatif. Chaque ligne de code est unique, même si elles se ressemblent toutes.
Chaque ligne de code contribue à l’oeuvre comme chaque touche de pinceau affine le tableau.
C’est très rationnel et technique comme peuvent l’être les proportions d’un motif, ou l’utilisation d’outils spécifiques comme un pinceau ou un couteau.
Et c’est aussi émotionnel comme peuvent l’être la lecture d’un texte littéraire ou l’écoute d’un concert.
Développer est un art.
Les enjeux
Développer mobilise notre cerveau et celui-ci n’a pas de limite.
Produire du jus de cerveau n’est pas linéaire, c’est complexe: quelques faibles variations des paramètres peut avoir des impacts multiplicateurs ou diviseurs de 10 ou 100.
C’est ce qui fait que Free, à 7 dans un garage, met une énorme mine à Orange, 1000+ ingénieurs, en sortant en premier l’offre triple play ADSL.
L’enjeu va bien au delà de baisser le turn over:
Avoir des développeurs motivés est une clef essentielle de succès du projet.
Du coup je pensais que trouver un bon développeur était universel. Il me semblait évident qu’il était préférable d’avoir des gens qui réfléchissent… Non.
Encore une vérité qui s’effondre.
Le bon et le mauvais développeur
Mais revenons au sujet initial: c’est quoi pour moi la différence entre un bon développeur et un mauvais développeur?
Ca me fait penser au sketch des inconnus sur les chasseurs…
Un bon développeur, il voit une feature, il code. Un mauvais développeur, il voit une feature, il code.
Un mauvais développeur, il a son client/utilisateur/patron qui lui demande une fonctionnalité, il se met à coder et il réfléchit après quand il a livré. Parfois il a fait mouche. Souvent il est à côté de la plaque.
Le problème c’est qu’il a livré à la dernière limite de la deadline. Donc ce n’est plus possible de corriger le tir sauf à rallonger les délais. S’il s’est planté dans ses estimations, le client est mis devant le fait accompli.
Si j’en parle facilement, c’est que je suis passé par là. Donc je ne jette la pierre à personne. Avant d’être bon, on commence souvent par être médiocre, même avec du talent…
Dans chaque mauvais développeur se cache un bon développeur en attente d’éclore.
Le bon développeur, il a son client/utilisateur/patron qui lui demande une fonctionnalité, il se met à poser des questions, il cherche à comprendre le métier qu’il modélise, puis il conceptualise. Enfin il code. Souvent il fait mouche. Parfois il est à côté de la plaque. Mais ce n’est pas tellement un problème car il livre régulièrement son travail ce qui permet un ajustement progressif via des cycles de feedback. S’il s’est planté dans ses estimations, le client a pu voir le truc arriver et ajuster les choses. Cela devient alors une opportunité de se concentrer sur ce qui amènera le plus de valeur et maximiser le retour sur investissement.
Bref
- Notre métier ne rentre pas dans le moule des concepts ‘Fordistes’ du siècle dernier.
- Je déteste les sociétés de service qui fleurtent avec le déli de marchandage.
- Nous faisons un métier dans lequel la créativité a une place centrale.
sudo killall besoin_de_reconnaissance
sudo sed -i « s/ami/autre ami/g » /etc/amis
Salut Guillaume,
J’aime ce genre d’humour de développeur!
Sur le besoin de reconnaissance, crois-tu qu’il soit réellement crédible de le supprimer?
Si ce besoin s’exprime de diverse manière il est quand même un fondamental de l’être humain, non?
En quoi cela te gène?
#++
Dans tous les cas le développeur exécute les ordres du chef. Qu’il soit un pisseur ou non.
Ce n’est pas ma vision du métier.
Symfony*
Après, « pisseur de code », c’est juste pour exprimer le fait qu’ils recrachent(raient ?) juste des codes comme on recrache une leçon sur une feuille de papier…faut pas voir plus loin que ça.