Développeur ou codeur ?

( 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:     

1. Contexte
2. Le métier de développeur est en crise 
3. Le marché du travail perverti par une gestion inadaptée
4. Donc un dév c’est quoi ?
5. 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