Développeur ou codeur ?

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.

Auteur : Nicolas Bouteillier

Si Nicolas était une liste de tags: développeur, technicien, artisan, entrepreneur, geek. Nicolas est développeur depuis 2002, il a accompagné en mode lean startup plusieurs démarrages de projets, gérant de sa SARL, autoentrepreneur, salarié, c'est un touche à tout riche d'expériences variées qui a accosté sur les rives de l'agilité sans jamais quitter le monde entrepreneurial.

19 réflexions sur « Développeur ou codeur ? »

      1. C’est de la branlette, croire que nos métiers ont une certaine noblesse et hauteur d’esprit.

        Développeurs/codeurs, nous ne sommes que les nouveaux ouvriers spécialisés du néo-libéralisme mondialisé ( à comparer avec le secteur automobile dans les années 70).

        Nos métiers n’ont qu’un seul et unique but : optimiser les flux capitalistes, rien d’autre et croire qu’il a une certaine portée philosophique dans nos métiers est de la pure branlette !

        Pas de création ici, nous appliquons chaque jour, des normes, valeurs, issues de processus de standardisation et de normalisation qui n’ont qu’un seul but : rendre l’homme interchangeable dans un process industriel (certifications, normes, ISO…).

        1. Ah ! Merci !
          Là c’est construit et intéressant.
          Je pense tout le contraire.
          Le logo prend exactement ses racines contre cette pensée. ✊
          Après chacun est libre d’y adhérer ou pas.

          1. Dans tous les cas, je te remercie pour ton honnêteté intellectuelle et ta vraie ouverture d’esprit. Sur d’autres blogs, j’aurais déjà été traité de nazi car entre le monde open source libriste et l’extrême gauche, il n’y a qu’un pas.

            Bonne continuation à toi.

        2. Salut Albi-bibi,
          je trouve ça vraiment très triste comme vision, même si elle est en partie vraie, car c’est une partie de la réalité pour une proportion importante de travailleurs.

          Mais je ne pense pas que ça soit une fatalité, et clairement je ne veux pas l’appréhender comme ça. On essaye ici de partager notre passion, notre vision pour faire bouger les lignes, ou au moins attirer l’attention et soulever le débat.

          Merci d’avoir pris le temps de répondre et de donner ton ressenti !

          1. Attention qu’on se comprenne bien, ce que je décris n’est pas quelque chose en lequel je crois, je décris seulement ce que j’observe depuis 30 ans.

            Je milite également pour une vision plus artisanale, plus humaine de nos métiers.

            Je suis agréablement surpris par la qualité des interventions que je trouve sur ce blog, cela devient rare.

            Bonne continuation à vous.

  1. Je te rejoins sur la différence notable entre un développeur A (disons que c’est celui/celle qui ne fait que pisser du code) et un développeur B (celui/celle qui à plus de recul, plus de connaissances et qui apporte des compétences transverses). Nommer le A « codeur », si tu veux.
    Peu importe en fait, le débat est stérile et vise à faire entrer dans des cases des individus selon une dénomination. A titre d’exemple, un autre pourrait raconter la même histoire, avec les mêmes arguments, pour distinguer un « Ingénieur en développement logiciel » d’un « Développeur ».

    Sur le fond maintenant.
    « 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. »
    Le marché – des formations accélérées aux métiers du dev – ne se trompe pas. Un marché existe ou n’existe pas, c’est binaire. C’est le besoin qui dicte si un marché doit exister. Ici il y a un vrai besoin qui se résume à : pas assez de développeurs.
    J’aime l’idée des formation accélérée et je me félicite qu’elles emergent de toute part. Probablement qu’elles sont toutes imparfaites et qu’elles ne se valent pas toutes, certes. Et alors ?
    Je me félicite que des autodidactes, des personnes en reconversion professionnelle, des personnes qui ont en marres d’être payer une misère puissent avoir l’opportunité de changer de vie. Alors peut être qu’elles débuteront en pissant du code. Mais peut être aussi qu’elles auront envie de continuer à apprendre ? Peut être que ces mêmes personnes deviendront des développeurs B ?

    Il y a une chose que tu ne mentionnes pas dans ton billet, probablement de façon involontaire parce qu’acquis depuis longtemps : nous, développeurs, sommes des nantis. Nous sommes généralement bien payés, nous sautons d’un job à l’autre avec une aisance nonchalante et nos revendications sont, le plus souvent, entendues. Il n’existe pas beaucoup de métiers qui peuvent offrir autant. Tout cela est justement dictée par la tension actuelle du marché.

    Bref, je pense que c’est important de se rappeler de temps en temps la chance que nous avons de faire ce métier, de prendre un peu de hauteur sur tout ça.

    1. Point de vue intéressant, merci Frédéric.
      Je pense que la question des écoles de formations accélérées n’est pas un souci en soit.
      Ce qui est un souci c’est quand elles font des promesses du genre : vient apprendre à coder de 0 et dans 3 mois tu es un pro.
      Ce serait dommage de s’arrêter là en terme de formation et malheureusement le marché du service n’incite pas à aller plus loin…

    2. Merci pour ton retour, et oui je te rejoins c’est top qu’on puisse se former, changer de métier, évoluer, mais ce qui me dérange c’est une baisse de qualité et des attentes vis à vis des professionnels pour faire du volume.

      Si tu formes quelqu’un en lui disant, écoutes tu as de quoi travailler demain, mais pour compléter ta formation, il y a ça, ça et ça, c’est parfait ! Mais si tu lui dis, écoutes dans 3 mois t’es un dév, tu vas faire 50K+/an et c’est tout bon, c’est dérangeant.

      Quand je dis que le marché se trompe, tu me renvoi un de mes arguments préférés, en effet le marché est une entité vivante et indépendante, il est ce qu’il est. Une forme plus complète pour expliquer mon point de vue pourrait être que:  » les entreprises qui cherchent à embaucher de la ressource jetable et interchangeable qui code sans réfléchir pour le coût le plus bas possible, et qui de fait créent la demande se trompent « .

      J’essaye de soulever le débat (mais pas d’ordre sémantique ^^) et de sensibiliser autant les étudiants (de tous âges et de toutes les formations) que les organismes qui dispensent les formations.

      Nous sommes des artisans développeurs, nous devons essayer d’inspirer, de pousser la qualité et les bonnes pratiques, si dans les cursus accélérés, il y avait systématiquement de la qualité (tests, tdd, bdd, review), un peu d’automatisation (CI etc), et surtout les ouvertures vers les autres compétences à acquérir pour compléter, je ne vois aucun problème à ce que la formation « produise » des gens qui écrivent du code pour travailler de suite, faut bien manger, si ils sont conscients de ce qu’ils doivent aller chercher pour compléter leurs compétences et devenir des développeurs complets.
      Il faut leur apprendre que ce métier demande un apprentissage perpetuel.

      Pour la sémentique, sur linkedin un commentaire parle d’analyste-programmeur, c’est bien aussi.

      Par contre, pour moi c’est pas une chance d’être un dév, c’est de la passion, du travail, de la lecture, des tutos, des tests, des nuits passées à casser et réparer du code … Un investissement constant piloté par la passion.

      1. Merci pour ton retour Nicolas. Tu fais bien de préciser.
        Loin de moi l’idée qu’être développeur est affaire de chance. C’est, comme tu le dis, de la passion et du travail. Mais je pense que tu auras compris mon propos : ce qui en est une chance pour nous développeurs c’est que la demande soit si forte.

  2. J’avoue être généralement assez sceptique lorsque je vois un titre comme celui-là.
    Je me dis qu’on va parler du bon chasseur et du mauvais chasseur et vois effectivement un petit drapeau « attention rhétorique » qui s’agite.

    Eh bien pas du tout, je trouve l’article intelligent et plaisant à lire.
    Il aurait été cependant intéressant de préciser que la réalité est malheureusement cruelle car nombre d’entreprises cherchent sans réellement l’admettre des codeurs et non des développeurs.

    Il est plus confortable pour elles d’avoir des gens assez dociles qui se laissent dicter des solutions sans trop réfléchir ni les challenger. Car on leur demande de faire de la maintenance de l’existant et de la solution « quick & dirty » plutôt que de la solution adaptée et pérenne.

    La phrase de Benoit « lorsque tu n’as qu’un marteau toutes les vis ressemblent à des clous » prends tout son sens quand on a cotoyé ce genre de mentalités.

    PS: Cette phrase rentre dans mes favoris. J’adore !!

    1. Merci Nicolas pour ton retour.
      « Je vois un petit drapeau « attention rhétorique » qui s’agite »
      Bah oui, bien sûr… 😅
      Le but est de capter l’attention !
      Merci d’être allé au delà et d’être entré dans le fond de l’article !
      Effectivement je trouve ça intéressant comme point de vue : c’est plus confortable pour les boites…
      En gros : soyez innovants et réfléchissez, mais pas trop quand même…
      En fait c’est pas une question de ‘trop’ c’est plutôt une question de quand ça arrange…

    2. Merci Nicolas pour le compliment 🙂
      J’essaye de créer le début, soulever des idées, et déranger un peu aussi des fois.

      Oui, la réalité est malheureusement différente de notre vision, mais c’est pour ça qu’on fait ce qu’on fait, on partage au maximum pour faire bouger les lignes, pixels par pixels, sur le long terme

  3. La moitié des commentaires sont affligeants. Il est temp de reboot et de nettoyer les SSD qui vous servent de cerveaux messieurs les-votent-à-droite.

    L’article se veut bienveillant, instructif et pleinement lucide sur un métier en partie méconnue pour probablement la moitié des travailleurs Français et décrié dans notre société droguée à la rentabilité à tout prix.

    Bravo à l’auteur,

    Résistance.

    1. Merci pour ton message, le compliment et le soutien !

      Ceci dit, tu as raison, on veut être bienveillant, donc même si on est pas forcément d’accord avec tout le monde, on évite de s’envoyer des boîtes 😉

      ps: c’est pas bien les ssd ? Ça donne des cerveaux plus rapides non ?

      1. C’est justement là qu’est toute la dichotomie, Citoyen Bouteillier, les gens réfléchissent et émettent à toute vitesse mais la profondeur et la consistance de leurs pensées se fait de plus en plus… creuses.

        Remerciez Twitter.

        Résistance.

  4. Sur le terme de «codeur» :

    «I find it bizarre that people use the term « coding » to mean programming. For decades, we used the word « coding » for the work of low-level staff in a business programming team. The designer would write a detailed flow chart, then the « coders » would write code to implement the flow chart. This is quite different from what we did and do in the hacker community — with us, one person designs the program and writes its code as a single activity. When I developed GNU programs, that was programming, but it was definitely not coding. » R. Stallman

    https://stallman.org/stallman-computing.html

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.