( Post original sur https://artisandeveloppeur.fr/developpeur-ou-codeur/ – si vous voulez commenter, allez sur l’article original. Je vous invite au passage à aller lire les posts des autres contributeurs sur cet excellent blog ! )
Qu’est ce que réellement le métier de développeur ?
Qu’est ce qu’on doit attendre d’un développeur ?
Est-ce qu’un codeur est un développeur ?
Pour répondre à ces questions nous allons avancer ensemble à travers 4 courtes parties:
- Contexte
- Le métier de développeur est en crise
- Le marché du travail perverti par une gestion inadaptée
- Donc un dév c’est quoi ?
- Conclusion
1 – Contexte:
Avant tout il faut faire la différence entre le professionnel que tu es et le poste que tu occupes.
En tant que professionnel tu n’es pas défini par:
- par ta formation
- par ton langage/framework/techno
- par le titre de ton poste
- tes responsabilités dans ta boîte
- tes certifications
Tu es défini par la manière dont tu vois et tu pratiques ton métier, ta mentalité, tes valeurs.
Dans
cet article et plus largement dans notre communauté d’artisans
développeurs ce qui nous intéresse c’est la manière dont tu travailles,
dont tu abordes le développement.
2 – Le métier de développeur est en crise
Alors
oui, je plaide coupable c’est un titre de paragraphe provocateur mais
le métier de développeur à été dévoyé et les dév sont vus à tord comme
«des gens qui écrivent du code».
Une
ressource qu’ils mettent derrière un bureau, qui prend ses user
stories, ou ses specs et qui doit « juste coder ce qu’on lui demande ».
En
réalité un développeur est avant tout un interlocuteur qui doit
comprendre les besoins, le métier, évaluer et synthétiser. C’est le
lien, le dernier maillon entre la vision et l’implémentation.
Beaucoup
de formations, souvent « accélérées », sont apparues ces dernières
années pour apprendre à développer. Mais elles apprennent à coder et pas
à développer.
Je
soupçonne une grande partie des organismes de profiter du besoin
croissant de dévs, de dispenser des formations pour « produire » les
employés dont le marché à besoin.
Cependant, et c’est l’objet de la partie suivante, je pense que le marché se trompe, et il prends un très mauvais chemin.
Donc, lorsque tu as appris à coder tu n’es pas un développeur.
C’est sûr, là tu vas te dire, c’est de la rhétorique, c’est pareil: codeur, développeur, programmeur, programmateur (IMAGE)
Oui,
je fais la différence entre un développeur (appelé dév tout au long de
cette article) et un codeur (appelé … non en fait on l’appelle pas :p ).
3 – Le marché du travail perverti par une gestion inadaptée
Je
ne suis pas historien et je n’ai pas 40 ans d’expérience en
informatique, mais à mon avis ce qui s’est passé, c’est qu’avec les
méthodes de gestion de projet héritées des industries, de la
construction et toutes ces choses très rigides, petit à petit on a
découpé les rôles, on a donné à certains métiers la charge de concevoir,
et d’autres la charge d’exécuter, comme l’architecte et les maçons. On a
cloisonné pour chercher la rentabilité. Chercher à être rentable est en
soit une bonne chose, c’est même primordial lorsqu’on gère en
entreprise, mais la manière n’est pas la bonne dans ce cas.
Les
dirigeants qui ont suivis ce chemin se sont fourvoyés sur une chose,
être développeur c’est un ensemble de compétences, si tu extrais le
codeur du développeur, tu vas diluer les qualités professionnelles qui
mènent à du code pérenne. Et la qualité baisse.
C’est
là où le fossé se creuse entre les entreprises qui veulent faire du bon
travail en étant rentables et les entreprises qui veulent seulement
être (très) rentables.
Je reviens sur mon analogie avec la construction, on peut trouver:
- l’équipe du terrassement (les ops)
- gros œuvres (les dév backend)
- les carreleurs (dév front)
- les peintres (UX)
- l’architecte (l’ingénieur commercial + l’ingénieur architecte logiciel)
Quand
l’informatique est arrivée elle a été gérée comme le reste, pourquoi
réinventer alors les méthodes de gestions de projets ?
Mais ça ne va pas fonctionner sur le long terme et il ne faut pas que ça fonctionne comme ça : nous
faisons de l’immatériel, qui doit rester en mouvement en permanence,
changer, s’adapter, s’améliorer, appliquer des méthodes de gestion de
projets finis, rigides, ne permet pas cette souplesse et cette capacité
d’adaptation.
On
se rend bien compte maintenant que l’informatique en général et le
développement en particulier est indispensable, complètement dissocié du
reste, c’est immatériel, on ne doit pas le gérer comme du matériel.
Le développement intervient partout, rien ne va plus lui échapper: télé, réfrigérateur, voiture, robots, médecine.
L’autre
point important lors du découpage de compétences, c’est que le codeur
se retrouve très souvent à faire toujours la même chose ou du
ressemblant, il devient super spécialisé et à force c’est la créativité
qui souffre, et sans créativité, pas de solution innovantes, pas de
designs pertinents, pas de nouveautés …
Il
est tellement enfermé dans sa spécialité qu’il trouve toujours comment
faire correspondre un besoin à ce qu’il sait faire, et il déforme le
besoin. Je cite Benoît (Gantaume) dans une épisode du podcast, « lorsque
tu n’as qu’un marteau toutes les vis ressemblent à des clous »
Heureusement
les méthodes agiles remettent l’humain à sa place dans les
organisations, et si tu t’y intéresses un peu tu vois bien que le schéma
qui ressort comme idéal est une équipe pas trop grosse qui sait tout
faire, et qui fait en équipe.
Chacun a évidemment des compétences avancées dans son domaine, mais tout le monde participe.
Dans
ces équipes, les dévs reprennent leur place, il participent à la
conception, encore faut il qu’ils aient correctement appris à le faire.
4 – Donc un dév c’est quoi ?
Tout
ça pour dire quoi ? Tout ça pour dire que le métier de développeur
n’est pas un métier d’écriture de code. Il englobe cette activité parmi
d’autres. Si ma seule activité était de coder je serais malheureux,
coder est un très bon moment dans mon métier de dév parce qu’il y a
justement les autres aspects.
Pour développer un logiciel il faut :
- comprendre les besoins et le métier
- poser et expliciter les problématiques
- poser et expliciter les fonctionnalités attendues
- concevoir les solutions aux problématiques
- choisir la(les) meilleur(es) technologie(s), langage(s), framework pour implémenter ces solutions
- passer à l’écriture du code (les tests sont compris, on reste dans une optique de TDD)
- tester les fonctionnalités (chercher du retour utilisateur)
Dès lors on voit bien que juste coder ne permets pas de développer.
Une
des différences fondamentales entre un codeur et un développeur est
l’abstraction, lorsque tu es développeur tu es capable de faire
abstraction de ton langage de prédilection, de ton framework lorsque tu
penses conception.
La
conception doit être agnostique, les compétences à mettre en œuvre à ce
moment ne sont pas les compétences d’écriture du code. Pour expliquer
une fonctionnalité, à travers une User Story aucun langage de
programmation ne vient se mettre au milieu :
« En tant que client, je veux pouvoir télécharger ma facture en PDF pour la conserver chez moi »
Est-ce que tu va utiliser une librairie genre TCPDF, et le générer à la volée ?
Est
ce que tu vas conserver le fichier, et vérifier si il y a eu des
changements la prochaine fois pour éviter de le générer à nouveau ?
Comment dimensionner la prod si tu gardes les fichiers ? Quel impact sur les snapshots ou les rsync automatiques ?
Ce
sont des questions qui n’ont pas leur place à ce moment là, tu dois te
forcer à ne pas penser à l’implémentation, sinon ta conception va être
biaisée.
Tu
dois apprendre ou réapprendre à réfléchir à la conception, sans penser à
ton langage. Je précise ici que la « conception » pour moi est le
moment où tu imagines ton logiciel, ou tu réfléchis à ce dont tu as
besoin, gérer des utilisateurs, des commandes, des factures etc.
La conception que tu peux modéliser avec UML, ou merise par exemple.
Mais
pour faire ça il faut connaître les principes de base, le socle commun,
ce que Benoît Gantaume nomme « les compétences profondes », par
exemples: les principes de programmation orientée objet, les design
pattern …
5 – Conclusion:
Un développeur est un professionnel capable de s’imprégner du métier pour lequel il crée un logiciel, de concevoir les solutions aux problèmes posés, et d’imaginer les fonctionnalités nécessaires de manière agnostique, sans penser à l’implémentation. Quelles sont les fonctionnalités que je dois produire pour satisfaire les besoins des utilisateurs. Au final il implémentera ce qu’il a imaginé de la meilleur manière possible en utilisant les techniques, langages, framework les plus adaptés. En aucun cas je ne minimise l’investissement et le temps passé à apprendre à coder, je ne dénigre pas le contenu des formations de ce genre, et je suis très content qu’elles puissent permettre des réorientations ou des prises de postes assez rapides dans le domaine. Et pour finir la bonne nouvelle, si tu as appris à coder, il ne te reste plus qu’à continuer ta formation pour devenir développeur, apprendre la POO, les design pattern, le clean code, les bonnes pratiques … Ce fameux socle qui te permettra d’évoluer de « codeur en langage X » à « développeur », et les ressources ne manquent pas 🙂
Je t’invite a écouter le podcast de Benoit Gantaume sur le sujet , et l’échange entre Benoit et JP Lambert sur la chaîne scrum life.
https://www.youtube.com/watch?v=xcrKO5-R03Y