C'est quoi un dev?

J'ai récemment présenté aux Human Talks de Lyon cette thématique de la définition du dev. En voici une version revue et augmentée.

Au fil des de mes discussions et de mes expériences, je me suis rendu compte que comme tout métier pointu, il est particulièrement difficile d'expliquer ce que nous faisons aux personnes qui ne sont pas proche de notre secteur d'activité. Cet écueil me semble néanmoins relativement normal, je me sens moi-même bien ignorant quand je discute avec un ingénieur de l'agro-alimentaire ou un banquier d'affaire. Ce sont, je pense, des métiers dotés de spécificités fortes et qui ont le mauvais gout d'être des activités de service, donc impalpables par nature. Schématiser ce que fait un artisan (qu'il soit boulanger, menuisier ou paysagiste) est aisé car il y a certaines étapes ainsi qu'un résultat tous bien visibles, même au profane. En revanche, essayez d'amener un enfant chez le boulanger en lui disant que c'est la personne avec les mains pleines de farines qui fait le pain, ça lui fera le même effet qu'un magicien faisait apparaitre des cartes de sa manche. Il ne commencera à envisager le comment de la production qu'après en avoir clairement vu certaines étapes (pétrir, mettre au four,...).

Concernant l'activité du développeur, la plupart des gens ne voient que le résultat fini: le logiciel. Quant à prendre conscience des étapes liées au développement, les rares images dont ils disposent sont celles proposées par les productions hollywoodiennes dans lesquelles un nerd à lunette écrit du code au kilomètre, les yeux fermés, pour pirater la CIA, en buvant son café et en usant de mots vidés de leur sens "serveur, pare-feu, hacké, ...". Partant de là, expliquer à votre grande tante Léontine de 75 ans que non vous ne piratez pas le FBI, que non vous ne pouvez pas réparer son appareil photo numérique offert par ses enfants et que non, vous ne pouvez pas créer le nouveau facebook dans votre cave pour devenir millionnaire et lui offrir une croisière sur le Nil...

Encore une fois, que monsieur et madame tout le monde aient du mal à appréhender notre métier n'est ni gênant ni anormal. Là où cette ignorance devient problématique, c'est quand elle siège chez les personnes qui prétendent vouloir nous employer et utiliser nos compétences. Je ne referai un long plaidoyer contre le modèle des ESN, je l'ai déjà fait et je n'aurais rien de plus constructif à y ajouter. En revanche, il me semble nécessaire, en tant que développeur, de me prendre par la main(ou de m'en sortir les doigts comme pourrait nous y inviter quelque bon roi) et d'aller expliquer quelques tenants de notre profession à ces personnes.

Pour en revenir à la présentation faite aux Human Talks, j'avais choisi de présenter le métier de développeur par ses différentes facettes. Chaque facette étant une image issue d'une autre profession.

Ainsi nous sommes tantôt ingénieur dans la mesure où nous concevons des système complexes à l'aide de savoirs issus du génie logiciel. Nous sommes également des architectes dans la conception et le suivi de réalisation de ces système. Nous sommes en plus les techniciens et les maçons de ces systèmes puisque responsables de la réalisation du logiciel. Il nous arrive souvent d'être des sortes de pompiers du logiciel quand nous débarquons sur des applications sinistrées en pleine urgence opérationnelle.

Parallèlement, nous pouvons considérer notre activité comme celle d'un auteur dans la mesure où le logiciel se résume à des lignes de codes produites dans un langage spécifique. Il est à noter qu'en France, la plupart des logiciels sont protégés par le droit d'auteur plus que le brevet industriel. Dans le contexte de cette activité d'écriture nous pouvons également nous considérer comme linguistes et traducteurs spécialisés dans les langages artificiels (en opposition aux langues naturelles).

En amont de tout ce travail opérationnel, nous devons également être capables de comprendre le métier de notre client, ses besoins, ses envies, son mode de fonctionnement, ainsi que ses biais d'expression qui lui empêchent parfois de formuler clairement sa problématique. Nous nous prenons de fait pour des psychologues en herbe cherchant à comprendre les problèmes de nos interlocuteurs afin de leur apporter des solutions pertinentes qu'il pourra éprouver et ainsi faire évoluer la remise en question de ses propres besoins. Au travers toutes ces questions que nous posons à nos clients et que nous nous posons à nous-mêmes, nous prenons par là même une voix de philosophe à la recherche d'une forme de vérité: "mon implémentation est-elle la bonne?", "comment ma conception va supporter le poids des ans et des évolutions?",...

En recherche perpétuelle de réponses à ces questionnements profonds, nous choisissons bien souvent de rester de perpétuels étudiants, toujours en phase d'apprentissage afin de parfaire notre panoplie technologique et tactique afin de toujours être en mesure d'apporter plus de pertinences aux réponses apportées. Cet apprentissage permanent peut sembler tantôt stimulant tantôt éreintant tant la tâche est sans fin. La condition nécessaire pour accepter ce chemin réside pour moi dans une certaine forme de passion ou du moins d'un gout prononcé pour ce métier. Celui pour qui coder est seulement une activité pécuniaire journalière aura bien du mal à fournir un tel investissement dans un apprentissage récurrent.

De cette passion risque de naitre un gout esthétique prononcé pour ce qui est beau, du code à la conception en passant par le rendu final du logiciel. Ce faisant nous risquons de nous transformer en artiste plus intéressé par la beauté de notre production que sa finalité. Ainsi, la finalité de notre démarche est de nous tourner non pas vers l'art, mais plutôt vers l'artisanat. C'est ce sens donné par le software crafting qui me semble être aujourd'hui le plus "dans le vrai" pour ce qui est de répondre aux attentes de métiers en évolution permanente et aux besoins toujours plus précis nécessitant des réponses toutes aussi spécifiques.

Tout cet inventaire ne se veut ni exhaustif et encore moins dogmatique. Chaque dev est avant tout un être Humain dans sa richesse, ses limitations, ses forces et ses faiblesses.

Aux manager, RH, chefs de projet, commerciaux, si vous souhaitez que vos devs vous rapportent (et pas qu'à très court terme), laissez-les s'épanouir en leur permettant de cultiver les facettes qui leur seront profitables. N'hésitez pas non plus à leur présenter de nouvelles facettes dont ils ignorent encore l'existence.

Aux développeurs, n'oubliez jamais de communiquer sur toutes les facettes que vous mettez en œuvre au quotidien. Plus vos interlocuteurs auront une image de votre travail, plus ils seront à même de comprendre vos velléités d'apprentissage. Si vous savez soigneusement sélectionner votre entourage, il se pourrait même que certains aient compris l'intérêt de financer ce travail. Dans le cas contraire, je vous encourage à en changer, voir même d'envisager de devenir #freelance et ainsi reprendre la main sur cette facette fondamentale de l'apprentissage et de la formation continue.