De l’état du marché du développement

Il est possible de lire un peu tout et son contraire je trouve sur l’état du marché du développement en général. Il est tout à fait possible de tomber d’un côté, sur un article parlant de salaires incroyables, de recruteurs se battant et s’arrachant les vêtements pour attirer le top du top ; et de l’autre certains articles font état d’une réalité plus sordide, ou les développeurs indépendants, ou pas, luttent pour dépasser un certain seuil de rémunération, étant considérés comme des ouvriers vaguement qualifiés, interchangeables, tout juste bon à visser les boulons d’une vision géniale imaginée par quelqu’un n’ayant pas une once de culture tech, et donc mécaniquement ancrée dans une certaine mesure dans de la pensée magique.

J’avais envie d’ajouter mon grain de sel, pour tenter de décrire une réalité qui me semble bien plus complexe que «la méchante culture française fait qu’on utilise mal notre incroyable talent».

(petite note de lecture avant le suite : le terme “développeur” est hélas genré, mais par une flemme cosmique, et par souci de style, je prie le lecteur bien intentionné d’ajouter un “et développeuse” à chaque fois).

Photo by Émile Perron

Une histoire de magnétisme et de prophétie auto-réalisatrice

Disons qu’une entreprise n’ayant aucune connaissance particulière en développement ait décidé de réaliser une application quelconque, par un indépendant, entreprise, agence quelconque. Imaginons que cette personne ait réussi à les convaincre d’utiliser une technologie RAD (WordPress, Rails, Django, peu importe), car vous comprenez, les grands groupes font confiance à cette technologie, elle permet d’employer des juniors, il y a une grosse communauté, etc. Le prestataire peut empiler stagiaires et débutants sur le code, car c’est là la promesse de l’approche, leur mettre la pression, et après pas mal de larmes, de retard, et de dépit, une application dont personne n’est fier part en production. Peu de temps après, il faut tout de même la faire évoluer. Quelle est l’annonce qui va être produite pour le recrutement ? Cherche développeur wordpress/rails/django, niveau bac+5 exigé, aimant le challenge, connaissant au moins 10 blagues et étant force de proposition sous la pression.

Et c’est parti, le problème est maintenant auto-répliquant : l’entreprise ne va attirer que des personnes qui ne voient aucun souci avec ce qui a été produit. Ils vont peut être rire de comment ça a été mal fait, oubliant par la même la quantité de pression, et de décisions prises à la hâte ayant menées à cette situation.

Dans un monde comme celui-là, ce cycle paraît normal. C’est le jeu de l’informatique : tout est toujours hors budget, en retard et bugué. Du coup, autant ne pas payer cher quelque chose qui sera de toute manière cassé.

Pour expliquer le titre de cette section, que s’est-il passé ici ? Étant donné la configuration initiale, l’entreprise est un aimant à attirer les personnes en accord avec elles. Ainsi, oui elle n’attire que du pisseur de code, producteur de bugs. Donc, en pensant initialement que l’expérience ne sert à rien, que les bugs sont inévitables, que le logiciel est un centre de coût et qu’il faut embaucher à pas cher, et mettre la pression, l’entreprise n’attire que des profils qui vont valider ces hypothèses.

J’ai pris des frameworks RAD comme exemple, mais bien entendu, ces mots clefs sont remplaçables par n’importe quel autre, à n’importe quelle échelle : du moment qu’une technologie a été choisie indépendamment du problème, avec pour but d’économiser un maximum d’argent lors de la création du produit, ou pour tenter de pouvoir recruter du junior pressurisable, la situation est identique.

CV-driven

Une manière d’augmenter ses tarifs dans un tel écosystème, est de faire du CV-driven development. Le CV-driven development consiste à imposer des technologies à la mode sur un produit, indépendamment de leur pertinence, afin ensuite de trouver un emploi bien payé en tant qu’expert de cette technologie.

Si vous vous vendez sur vos connaissances techniques, vous allez aller dans des boîtes en accord avec ça. Étant donné que le CV-driven donne rarement de bons développeurs, vous allez donc être pisseur. Il est possible d’être mieux payé dans cette catégorie, en surfant sur la vague de la hype, mais votre valeur ne sera jamais perçue comme supérieure à celle d’un autre CV-driven plus jeune, et nécessairement moins cher.

Je ne sais pas si c’est une tendance de fond, mais je connais plusieurs anciens élèves s’étant lancés immédiatement en tant que freelance, grâce à une vague connaissance de ruby on rails, angular, react (peu importe encore une fois). C’est la quintessence du CV-driven démarré dès le début de carrière.

Cette approche peut éventuellement un jour vous transformer en un développeur expérimenté, mais les chances sont faibles. Les chances sont plutôt que vous deviendrez à un moment ou un autre, un expert local.

Expert local

Une autre approche pour augmenter son salaire consiste à devenir ce que j’appelle un expert local.

Dans une entreprise x ou y, vous êtes celui qui a mis en place tel ou tel projet, telle ou telle technologie, ou qui l’a repris. Vous vous êtes entêté, et vous êtes maintenant LA personne vers qui tout le monde se tourne en cas de souci sur cette plate-forme.

Soyons bien clair avec cette approche : cela ne fait pas de vous un développeur expérimenté, même après 40 ans de carrière : cela fait de vous l’expert local de cette entreprise. Votre valeur sur le marché est imperceptible. Peu m’importe que vous soyez l’expert SAP de cette entreprise, le fait est que vous ne savez rien sorti de ce contexte. C’est donc une position risquée également : en cas de changement de cap de l’entreprise, vous avez de fait, plus aucune valeur pour elle non plus. J’ai par exemple vu le cas chez des développeurs devenus maîtres dans l’art de patcher un vieux et très gros site en ASP (tout court). Au fils des années, cette solution a été remplacée par une nouvelle version en .NET. Elle n’était pas nécessairement mieux codée, mais certains développeurs se sont retrouvés sur le carreau, car ils n’avaient pas appris .NET pour tout un tas de raisons, et leurs connaissances du vieux système étaient devenues inutiles.

Briser le cercle : la posture du développeur expérimenté

Comme tout cercle vicieux, il existe toujours des moyens de le transformer en cercle vertueux.

Plutôt que de tenter d’agir sur quelque chose sur lequel je n’ai pas la main : les attentes des entreprises, et pleurer éternellement qu’elles ne comprennent pas; je préfère me concentrer sur quelque chose qui est à ma portée : ma propre attitude.

Qu’est-ce que l’expérience ? Pour ne pas refaire un énorme pavé, je vous encourage à relire mon article sur les phases du programmeur. En peu de mots, l’expérience, ce n’est pas la même année répétée 10 fois. L’expérience, c’est le recul sur la technologie, c’est la compréhension qu’un langage n’est qu’un modèle de pensée pour résoudre un problème, c’est la compréhension que faire une SPA, ce n’est pas être un développeur de génie, juste un développeur qui fait des applications comme on en faisait en WinForm il y a 20 ans. En gros, l’expérience, c’est avoir assez de connaissances pour avoir un recul considérable sur les outils, et pouvoir enfin nous concentrer sur le problème. Être expérimenté, c’est également savoir qu’on ne sait pas, mais savoir qu’on peut apprendre, ou avoir des intuitions sur des chemins à prendre que nous n’avons pourtant pas encore parcourus.

La posture du développeur expérimenté n’est non plus de créer de nouveaux problèmes dissimulant plus ou moins les anciens, mais bel et bien de les faire disparaître.

À partir de là, je fuis toute annonce ou demande alignant des mots-clefs, c’est un signe très clair que le client en face ne veut pas quelqu’un pour résoudre ses problèmes, mais quelqu’un pour augmenter le nombre d’heures qu’il peut aligner dans la construction de sa pyramide.

Pour augmenter la perception de ma valeur sur le marché, comparé à un junior, je vais avoir tendance à mettre en avant les problèmes que j’ai déjà aidé à résoudre, plutôt que les mots clefs que je peux aligner.

Un premier contact chez Arpinum du coup peut être un peu déroutant : là ou certains clients veulent tout de suite parler technique, nous passons notre temps à éviter le sujet, et creuser les raisons profondes de leur présence. C’est vraiment dans un dernier temps que nous allons cogiter à un chemin technique pour résoudre les problèmes que nous avons identifiés.

Un impératif : ne pas avoir plus de développeurs, mais plus de développeurs (réellement) expérimentés

Il est strictement contre-productif, irréaliste, et bête, de blâmer des juniors pour leur absence de connaissance. De plus, étant donné qu’il est strictement impossible de fabriquer une formation permettant d’être réellement prêt à coder en sortant, cela veut dire que la charge de la formation repose sur les épaules des développeurs expérimentés. Par le binomage, par la création d’environnements permettant de se remettre de ses erreurs, par des revues de code, par le partage des bonnes informations au bon moment, petit à petit on peut passer du stade du développeur sachant à peine ce qu’il est train de faire, au stade du développeur expérimenté.

Le souci, c’est que les chiffres sont en notre défaveur : il y a beaucoup trop de nouveaux entrants sur le marché par rapport aux personnes de bonnes volontés pour les accompagner (ou dans l’entreprise, ou à l’extérieur).

Le paradoxe, c’est que cette absence participe à l’hémorragie des développeurs : après plusieurs années en tant que développeur dans un milieu toxique, si jamais personne ne nous a montré que ce n’est pas une fatalité, qu’il est possible de faire autrement, pire, de prendre du plaisir à faire ce métier, alors on abandonne, d’une manière ou d’une autre.

L’autre paradoxe que j’ai déjà abordé dans mes billets et conférences, c’est que la posture du développeur expérimenté est souvent prise, parfois à raison, parfois à tort, comme de l’arrogance, ou du corporatisme. Quand on associe ça à la propension de notre profession à ne pas avoir d’histoire, cela crée ce gouffre de compréhension qui fait dire “TDD, c’est pour des extrémistes qui veulent nous faire sentir coupable de ne pas avoir de test”. Ou bien “on n’a rien à apprendre du développement de clients lourds, nous on fait du web”. etc. La solution bien sûr est également de laisser son ego à la porte quand on participe au développement d’un produit, mais c’est également un trait qui accompagne l’expérience hélas.

Tout ceci est bien dommage, car d’un autre côté, le bon environnement permet de progresser très vite. J’ai déjà travaillé avec des personnes fraichement diplômées, qui en à peine un an ou deux, m’avaient rattrapé ou dépassé.

C’est pour cela, je pense, qu’il faut arrêter de prétendre qu’apprendre à développer est facile. Oui en deux mois on peut commencer à être un amateur passionné, mais pas le CTO d’une startup hautement technologique. Il faut arrêter de cautionner des environnements de travail toxiques, cautionner des heures de travail de forçats imposées à des stagiaires pensant que c’est bien normal. Il faut arrêter de chercher encore et encore les mêmes profils, et diversifier les idées et cultures que nous sommes prêts à accueillir dans nos entreprises.

Il n’y a rien de neuf sous le soleil, cette situation n’est pas propre à l’informatique. Seulement, nous confions bien trop d’aspect de nos vies à du code pour que cela ne m’inquiète pas. Et même sans prendre cet aspect en compte, il s’agit tout simplement d’assurer le bonheur à ceux et celles qui veulent faire ce métier tellement passionnant.

Conclusion

Si vous ne devez retenir que quatre choses de ce trop long billet c’est :

• Si vous êtes développeur junior, cherchez un ou plusieurs mentors, internes ou externes, de préférence non formaté dans le même moule que votre entreprise
• Si vous êtes un développeur expérimenté, participez activement à la formation des juniors.
• Si vous êtes chef de projet/entreprise, etc, ne recrutez plus au mot clef. En payant des cacahuètes, vous n’obtiendrez que des singes.
• Et nous tous, arrêtons de faire briller ce miroir aux alouettes, faisant croire que développer est facile.