En voilà une question qu’elle est bonne !

Depuis maintenant un ou deux ans, apparaissent régulièrement de nombreux articles sur la remise en question du de .

Les développeurs prennent la parole pour décrire leur . Pour défendre même celui-ci. Il y a comme une lutte des classes non-violente. Un quelque chose qui rappelle le combat que mènent chaque jour les femmes pour reprendre la place qui est la leur dans la société.

Cet article, voilà un an que je tourne en rond pour l’écrire, ne sachant pas par quel bout le prendre et surtout quelle direction lui donner.

Car la question est extrêmement difficile à répondre et encore une fois, c’est Shirley Almosni Chiche (décidément 🙂 qui m’inspire et m’a fait comprendre comment rédiger cet article après son tweet :

Par curiosité, comment évaluez-vous un(e) bon(ne) (se) en entretien technique ?

Renforçant l’idée qui m’est venu en rédigeant l’article Réflexion sur le recrutement et les recruteurs, que recruteur et développeur doivent travailler ensemble, car sur le chemin du bon emploi, il faut être deux.

Commençons par une petite chanson, sur l’air Le petit zinzin d’Henris Dès :

Dis papa, dis papa, dis-moi, dis-moi, c’est quoi le métier de développeur.

Et la réponse :

C’est trop compliqué, j’peux pas t’expliquer.

D’analyste-programmeur à développeur

Il faut remonter l’histoire, faire un peu d’archéologie pour retrouver les traces de la naissance du développeur. En effet, dans les années 70/80/90 on parlait d’analyste-programmeur, puis dans les années 2000 le terme développeur a peu à peu été généralisé.

Le titre d’analyste-programmeur a disparu, y compris des référentiels emplois.

Mais que s’est-il passé ?

Je pense sincèrement que seul un(e)/des sociologue(s) peut/peuvent répondre avec exactitude à la réponse.

Je me demande si c’est n’est pas avec l’explosion des besoins de développement et la pénurie d’analyste-programmeur dans les années 2000 qui a amené cette situation.

En effet, à cette période des milliers de gens ont été reconverti dans l’ pour les positionner dans le développement.

Le souci est que nombre d’entre eux n’avait pas le profil répondant aux exigences du développement (j’entends profil intellectuel). Naturellement, ils ont été positionnés sur du j’écris du code sans me poser de question et sur du j’écris des spécifications fonctionnelles sans comprendre l’après.

Ce qui inévitablement a amené à séparer les rôles. D’un côté la partie métier, de l’autre la partie technique. Et dans la technique une séparation entre ceux qui pensent (les techniciens expérimentés) et ceux qui font.

Et c’est ainsi qu’apparaissent des annonces avec des titres qui font froid dans le dos Ingénieur études et développement JAVA/J2EE confirmé (H/F) avec un descriptif :

De formation Bac +5 en tant qu’Ingénieur Développement Logiciel (école d’ingénieur, Master ou équivalent). Vous possédez plus de 5 ans d’expérience professionnelle en développement logiciel. Vous avez des connaissances approfondies en Java/J2EE (Spring, Hibernate, JSF, Struts, EJB.) De bonnes connaissances en C, C++ seraient appréciées.

PS: je travaille avec un collègue qui a été reconverti développeur et dans son cas c’est une réussite, il faut donc regarder au cas par cas.

Extinction Crétacé-Tertiaire

Oui mais voilà, le boum des usages et des technologies est venu détruire ce monde, comme ont été victime les dinosaures. Car oui, la séparation des rôles ne survie pas, elle n’est plus adapté au présent.

Ce sont donc les mammifères, qui reprennent le territoire.

Toutefois, il y a des espèces qui ne se sont pas éteintes (à l’image des fournies, des crocodiles…) et c’est eux qu’on nomme développeur.

PS : si vous vous dites que les deux phrases précédentes n’ont aucun sens, vous n’avez pas tout à fait tord 🙂

Ces personnes ont compris depuis le début que les règles du jeu sont extrêmement complexes, et notamment que les limites ne sont pas franches (un développeur doit comprendre du fonctionnel et du technique, sans nécessairement être un expert). Règles que cet article ne pourra pas expliquer.

De développeur à psychanalyste-développeur

Aujourd’hui, il faut comprendre qu’un développeur n’est pas une encyclopédie technique au risque de devenir comme certains mécaniciens qui devant une voiture ancienne (une Peugeot 309 SR de 1987 pour être précis) vous répondent (c’est du vécu) [1] :

Je peux pas réparer votre voiture, je peux pas brancher la mallette de diagnostic. Comme je vais savoir la panne moi ?

[1] On pourrait faire un parallèle intéressant avec ce cas et la tendance actuelle du développement qui consiste à empiler des frameworks. Mais c’est un autre sujet.

De mon point de vue (là j’insiste, cet article n’est pas une vérité absolue, juste un sujet de réflexion), le développeur doit entamer la même démarche qu’un psychanalyste ou psychothérapeute.

Il doit comprendre les implications de la demande du client et travailler avec lui pour l’amener à réfléchir sur le bien fondé de sa demande et l’implication de celle-ci.

Car le développeur n’est pas un expert ! C’est un médecin généraliste, qui a une vision large, sait où orienter son client. Et c’est lui qui est le plus à même de comprendre de façon macro les implications (coût, risque..).

Son avis est donc crucial et c’est pour cela que client et développeur doivent travailler dans une confiance mutuelle.

Un développeur va donc répondre aux besoins de base d’un client (en terme d’architecture, de technique, de technologie…) et devra faire appelle à un expert pour certains points.

Comment je recrute un développeur ?

A lire les annonces d’emploi et avec l’expérience, j’ai vraiment le sentiment qu’il y a une confusion des recruteurs ET entreprises entre développeur et expert.

Un expert, c’est relativement simple, il a un domaine et doit maîtriser ce domaine. On va donc pouvoir l’interroger sur des points techniques précis (c’est là où le relativement simple prend sa place, car seul un expert peut évaluer un expert).

Un développeur (si on reprend mon point de vue évidemment) est une personne dont l’atout principal est :

  • la généralité,
  • la curiosité,
  • l’envie de résoudre des problématiques.

On est donc sur du savoir-être (vous savez cette ligne que personne ne comprend en entretien annuel), plus que du savoir.

Et c’est pas fini !

Avec tout ça, vous êtes bien avancé. Finalement, on ne sait toujours pas vraiment ce qu’est un développeur.

C’est normal !

En effet, nous sommes dans un bouillonnement permanent et les lignes ne font que de bouger.

Il y a quelques années, un administrateur de base de données s’occupaient des SGBD relationnel, il devait connaitre le langage SQL.

Maintenant, il doit aussi gérer les bases de données NoSql comme MongoDb, Cassandra, Couchebase… Et là, les paradigmes sont différents.

PS : Si un poste d’expert bouge autant, imaginer celui de généraliste 🙂

Un dernier exemple pour la route

Pour conclure sur une non conclusion, nous allons prendre un cas concret.

Si on reprend l’exemple de NoSql (et oui, c’était pas par hasard cette échappé). Un développeur va estimer au vu du besoin de son client qu’il faut partir avec MongoDb.

La volumétrie au départ est faible, le développeur à toute les compétences requises pour comprendre le fonctionnement de MongoDb et le mettre en place dans un mode simple.

Mais avec le temps la volumétrie augmente et c’est là qu’intervient l’expertise de l’administrateur de base de données (clustering, indexation…).

Conclusion

Allez, vous attendez une conclusion, la voici :

Développer c’est créer mentalement quelque chose de virtuelle qui a une réalité physiquement inaccessible par les sens humains

Un développeur de qualité (attention rien à voir avec le non-sens du bon développeur), à mon sens, c’est :

  • quelqu’un qui aime résoudre les problèmes pour aider son prochain (ma préférence c’est quelqu’un qui aime résoudre les problèmes de façon simple pour le client),
  • quelqu’un de curieux (~veille techno mais aussi sa curiosité pour autre chose que l’),
  • quelqu’un de motivé voir même passionné,
  • quelqu’un de modeste (et donc qui aide son prochain sans en tirer une gloire),
  • quelqu’un qui aime la technique,
  • quelqu’un qui se remet en question (pas besoin d’être le dalai lama) et qui remet en question l’environnement (rien de pire que bah, c’est comme ça alors je le fais),
  • quelqu’un qui partage (donc il partage sa connaissance, son point de vue…),
  • quelqu’un qui ne choisit pas une techno/framework que parce qu’il a envie, il faut qu’il y ait une réflexion derrière.

L’avantage de ces critères c’est qu’il s’évaluent de la même façon que la personne soit débutante ou expérimentée.

L’inconvénient c’est de créer les conditions pour évaluer ces critères en entretien.

Et pour la partie technique ?

Ne pas oublier que si vous exigez quelque chose de quelqu’un, celui-ci aura les mêmes exigences en retour. Restez donc modeste et ne pensez pas en terme de coût, un salarié c’est un gain, pas un coût (sinon c’est qu’il y a un problème).

Emeric Martineau

Emeric Martineau

Emeric Martineau intervient actuellement chez Voyages-Sncf.com au sein de la mission DevOps.

Accompagnant les projets pour améliorer les processus de delivery, il développe divers outils autour des technologies : Angular JS, Java, Redis, Puppet, Rundeck

Consultez son blog pour connaitre les thèmes qu’il rencontre au quotidien dans son travail !

Retrouvez l’article et le profil d’Emeric sur Linkedin