Archives par étiquette : Opinions

image_thumb.png

L’incompétence des développeurs

Il y a un peu plus d’un mois je m’étais décidé à répondre au post “On a besoin de stars pas de managers”.

Romain David, co-fondateur de la startup Balloon y explique son désarroi face au grand nombres de développeurs qui ont comme objectif de :

ne pas rester éternellement développeur, mais devenir chef de projet

 

Ce qui dans le cas d’une startup est pénalisant puisque la société recherche des profils techniques pointus, autonomes, capables d’apporter une vraie valeur ajoutée par rapport à des “pisseurs de code” classiques.

La raison de ce désamour du métier de développeur qui incite à devenir chef de projet est selon moi identique à la raison pour laquelle les développeurs ont une mauvaise image.

Et cette raison est simple :

une très grande majorité des développeurs est incompétente

 

Je vous parlais il y a peu des 3 stades de maturité d’une équipe de développement, le problème est que selon mon expérience environ 75% des équipes (et donc des développeurs et chefs de projets) sont dans la phase du chaos, 20% dans la phase intermédiaire, et 5% sont autonomes. (N’hésitez pas à confirmer ou infirmer cette estimation dans les commentaires).

Et pour illustrer cette incompétence je vais m’attarder sur le profil des développeurs .net. Une majorité n’a pas des connaissances de bases telles que :

  • Connaissances de bases sur la POO (expliquer clairement la différence entre une classe et un objet, les différences entre une classe abstraite et une interface, notions de base sur l’héritage, donner un exemple de design pattern, etc.)
  • Comment gérer les erreurs (définir les différentes stratégies de gestion des exceptions)
  • Savoir définir avec une phrase claire ce qu’est le framework .net et quels sont les services fournis par le CLR.
  • Maitriser ce qui n’a pas attrait à l’écriture de code et que Microsoft regroupe sur le terme d’ALM (gestion des sources, gestion des tâches/bugs, builds, tests, etc.)
  • etc., etc., etc.

Quand je parle d’incompétence je ne parle donc de non-maitrise de concepts et notions mais de non-maitrise des fondamentaux essentiels au bon déroulement d’un projet de développement.

Durant les entretiens techniques que je fais passer, j’en suis “réduit” à poser des questions ouvertes afin de juger du recul du candidat sur différentes technologies (compréhension des principes et de la philosophie d’une techno, description des avantages et des inconvénients de la techno), et de juger de sa compréhension du métier de développeur (recul par rapport au métier, description des difficultés du métier, et comment y pallier). Ceci pour estimer de sa capacité à rapidement arriver au 2eme stade de compétence décrit rapidement ci-dessus.

Le fabuleux destin du développeur

Fort de cette incompétence, le développeur tel un forçat va devoir s’efforcer d’essayer de rattraper (souvent en vain) ses propres erreurs, les erreurs de ses collèges développeurs, du chef de projet, et des commerciaux. Oublier la notion d’horaires de travail et prendre un soin particulier à bien entretenir sa nouvelle petite amie : la machine à café.

Le tout en devant :

  • expliquer pourquoi une fonctionnalité qui marchait correctement auparavant ne fonctionne plus à cause d’une modification qui n’a (en apparence) aucun rapport avec celle-ci
  • parvenir à justifier pourquoi il serait plus simple de refaire depuis zéro

qui pourrait être traduit par :

  • “ah bravo tu es tellement mauvais que quand tu touches une partie de l’application, tu en casses une autre“
  • “tu es tellement mauvais que pour faire une tâche tu dois t’y reprendre à plusieurs fois en recommençant à zéro“

image

Ainsi après avoir passé plusieurs mois à travailler sur des projets en sachant pertinemment que le développement réalisé était de très mauvaise qualité, et en se demandant pourquoi on lui avait explique que les frameworks et outils actuels rendaient la vie du développeur très simple (on m’aurait menti ?) il est compréhensible que celui-ci veuille prendre la responsabilité de chef de projet.

Une partie des développeurs voudront assumer cette responsabilité afin d’essayer d’améliorer les choses.
Bien évidemment, n’ayant pas reçu de formation de chef de projets, la probabilité d’arriver à réellement améliorer les choses est assez faible. Et ceux qui font l’investissement de faire une pause dans leur cursus professionnel afin de retourner à l’école et suivre une vraie formation de chef de projet suite à de mauvaises expériences vécues en tant que développeur, se font recaler pour leur manque d’expérience (cas d’un récent candidat qui recherche donc à présent de nouveau un poste de développeur…)

Une seconde partie de développeurs voudra devenir chef de projet non pas pour améliorer les choses mais pour ne pas à avoir subir toutes les erreurs du projet tout en ayant un meilleur salaire. Comme dans beaucoup de secteurs, c’est le salarié tout en bas de l’échelle qui subit le plus les conséquences des erreurs qui ont pu être commises. Il est donc plus confortable de monter d’un niveau, on ne sera pas plus compétent mais au moins on se tuera moins à la tâche. Et oui, dans le domaine du développement le développeur est considéré comme l’ouvrier préposé aux tâches répétitives. Après tout, du code ça reste du code non ?

Pour les développeurs qui ne souhaitent pas ou ne peuvent pas devenir chef de projet, plusieurs attitudes sont possibles. La plus courante est la résignation. Quand on a pleinement conscience de faire un travail de mauvaise qualité, soit on se rend malade en s’apitoyant sur son sort soit on prend du recul, de la distance, et on se détache petit à petit de son travail, en ne cherchant pas à s’impliquer et en renonçant totalement à essayer de faire changer les choses.

Je vous recommande la lecture de le post de Romain Verdier “Dégage sale programmeur ! ” qui décrit le problème avec infiniment plus de talent que moi.

Le métier de développeur est très complexe

Ce tableau assez noir n’est pas dû à la stupidité des personnes qui endossent le rôle de développeur (je pense que la majorité des développeurs est incompétente, je ne pense pas qu’ils sont stupides…) mais à la complexité du métier de développeur.

Un développeur doit posséder les compétences suivantes :

  • Etre avant tout un très bon “informaticien”. J’entends par là qu’il doit maitriser les notions fondamentales indispensables à la bonne utilisation et à la bonne exploitation de l’outil informatique. Maitrise d’un grand nombre de connaissances qui ne sont pas directement lié au développement (exemples : maitrise du fonctionnement d’un OS, de sa conception, de son architecture, sa gestion de la mémoire, maitriser la sécurité, savoir ce qu’est un process, un thread, maitriser la différence entre le 32 bits et le 64 bits, savoir ce qu’est une partition, savoir ce qu’est la virtualisation, connaitre les fondamentaux liés aux réseaux (ARP, DNS, IPV4, IPV6, MAC, etc.) etc., etc.)
  • Et après avoir acquis toutes ces connaissances “de base” sur l’informatique, le développeur pourra commencer à apprivoiser l’écriture de code et ceci via plusieurs langages puisqu’un seul ne suffira pas pour faire son métier (C#, VB, T-SQL, PL-SQL, XPath, Javascript, etc.). Il devra pour cela maitriser tous les fondamentaux de la programmation orientée objets, et découvrir par lui-même quelques bonnes pratiques qu’il n’a pas forcément ou pas correctement acquises durant sa formation. Puis au fil de son expérience devra comprendre en quoi consiste vraiment l’écriture de code (un code n’est pas figé et doit évoluer dans le temps = être maintenable, refactorisé et donc être testé, il doit de plus être géré via un source control (avec maitrise des concepts associés, checkin/checkout/label/shelve/merge, etc.).
  • Il devra également réellement comprendre en quoi consiste un projet de développement, le rôle et l’impact de chacun, et bien comprendre que développer ce n’est pas uniquement écrire du code.
  • Et bien évidemment comme l’informatique évolue très vite, une fois l’ensemble de ces connaissances acquises, le développeur doit être capable de les tenir à jour semaines après semaines en effectuant une veille technologique appropriée.

Bref, à mon avis un bon développeur se fait seul et n’apprends pas l’ensemble des concepts et notions qui feront de lui un développeur correct durant ses études (même après une école d’ingénieur). Cela nécessite un auto-apprentissage important (et donc un investissement personnel important) ce qui explique l’incompétence généralisée décrite au travers de ce post.

L’essentiel de la compétence d’un développeur s’acquiert via son expérience, il est nécessaire de réaliser que malgré toutes les compétences techniques qui ont pu (ou pas) être acquises durant les études, le métier de développeur nécessite de ne pas laisser tomber et de vraiment débuter à apprendre son métier lorsque l’on débute son expérience professionnelle le tout dans un contexte professionnel souvent très mauvais (mauvaise équipe de dév, mauvais chefs de projets, etc.)

Bon et bien évidemment, si vous pensez être dans les 5% évoqué ci-dessus ou même dans les autres 20%, je vous rappelle que je recherche du monde ! Clignement d'œil
(et maintenant vous connaissez certaines des questions que je pose durant les entretiens techniques…)

image

Les 3 stades de maturité d’une équipe de développement

Avec mon changement de métier en début d’année, j’ai naturellement enrichi ma liste de lectures avec des sites/blogs non techniques traitant du leadership d’équipes de développement.

Un des mes sites préférés dans ce domaine est le blog Five Whys de Roy Osherove et celui-ci identifie 3 stades de maturité d’une équipe de développement :

  • Le chaos : l’équipe ne possède pas les connaissances techniques fondamentales/de base/minimales nécessaires pour débuter à faire correctement les choses.
  • L’apprentissage : l’équipe possède certaines connaissances techniques ET non-techniques qui lui permettent de voir son niveau régulièrement s’améliorer
  • L’autonomie : l’équipe est quasiment autonome, et possède les connaissances nécessaires au bon déroulement d’un projet.

Vous pouvez vous référer à ce post ou encore à ces slides pour plus de détails sur ces stades de maturité.

image

Je n’avais jamais formalisé mon point de vue sur le niveau des équipes de dév. de cette manière avant d’avoir lu le blog de Roy Osherove, mais je suis entièrement d’accord avec ce découpage.

Et je trouve de plus qu’il permet d’expliquer énormément de choses concernant le monde du développement, et je vais m’attacher cette semaine à rédiger différents posts à ce sujet.

Stay tuned !