Mon développeur, ma développeuse, il-elle fait de la merde ! Vraiment ?!

0
2217
developpeur developpeuse fait de la merde

Mon développeur, ma développeuse, il-elle fait de la merde ! C’est par cette phrase que j’ai envie de commencer cet article. On l’entend souvent, voire trop souvent, n’est-ce pas ?!

S’améliorer dans son métier

Le développeur, la développeuse doit se former, apprendre. Je dirais, comme tout personne, dans n’importe quel métier, non ? Surtout s’il, si elle, veut le fait bien.

Et pourtant, partout, dans n’importe quel métier, nous voyons autant des personnes qui réussissent que d’autres qui n’y arrivent pas. Et malgré ce qu’ils disent, ils n’y arrivent pas.

Votre équipe ?

Besoin de plus de cohésion !

Vos équipes peinent à se former ?

Vous souhaitez passer à l'étape supérieur pour vos projets ?

Plus de qualité, de plus de cohésion technique, d'équipe ?

Bouc émissaire ? Ils n’ont qu’à se former !

Et pourtant, c’est un peu trop facile de juger, et dire : oh ben ils ont qu’à se former.
Avec le ya qua faucon, on arrive à rien, non ?!

Des super pouvoirs ?

Il est facile de dire que si le projet n’est pas pérenne, que si le projet a des bugs, c’est tout de la faute du développeur, de la développeuse.

C’est trop facile de dire que s’il n’est pas super, s’il n’a pas réussi à sauver l’immeuble du feu, il ou elle est mauvais développeur-peuse.

Il deviendrait plus facile alors d’expliquer (de manière cynique) la cause d’échec de votre projet.

Un bon bouc-émissaire, en somme n’est-ce pas ?!

Savoir et savoir apprendre

Un développeur, une développeuse doit savoir la base, c’est sûr. La base essentielle qui permet de coder, de créer du code.
Et aujourd’hui, et depuis plusieurs années, la liste de ce que doit savoir un développeur s’allonge à vue d’oeil.

Il ou elle doit savoir :

  • avoir une architecture clean directe
  • savoir architecturer toute application, mobile, web, ou …
  • ecrire en tdd (tests unitaires en amont), tout en codant deux fois plus vite
  • se former, et s’autoformer tout le temps, …
  • créer des micro-services scalables (mises en échelle), ..

Ok ok, aujourd’hui ce métier devient et est devenu de plus en plus complexe.
C’est ce qui en fait sa beauté, son art. Et comme tout artisan, ça s’apprend !

Bon partout et bon nulle part ?

A force de chercher le mouton à 5 pattes, et de chercher des développeurs développeuses fullstack, avec 10 ans d’expériences, on en oublierait presque que même dans l’informatique, il existe des centaines de métiers différents (prenons déjà ce top 20 des métiers recherchés) !

Alors plutôt que vouloir être bon partout, et en fait être bon nulle part, il peut être intéressant d’avoir certaines spécialités.

Chaque métier a ses acquis de bases, les compétences à avoir pour bien démarrer, et après, comme chaque métier, ça s’apprend.
Et tout ne s’apprend pas à l’école ! Beaucoup de règles, de réflexes, de connaissances, se font sur le terrain, dans la « vraie » vie !
N’en déplaisent à certains formateurs, certaines employeurs.

Chercher à s’améliorer, une des meilleures compétences

Plutôt que de chercher une personne qui sait tout sur tout (il en existe c’est sûr, mais combien …), cherchons des personnes qui savent se remettre en question, qui ont soif d’apprendre, même si ce n’est pas leur passion première !
On peut faire un métier, et bien le faire, sans être passionné-e !

Votre équipe ?

Besoin de plus de cohésion !

Vos équipes peinent à se former ?

Vous souhaitez passer à l'étape supérieur pour vos projets ?

Plus de qualité, de plus de cohésion technique, d'équipe ?

La passion n’est pas une obligation

Oui, n’en déplaisent aux vieux de la veille, aux passionné-e-s du développement, aux nerds ou vrais geeks. On peut faire un travail, le faire de manière excellente, et réussir dans ce métier, sans être passionné-e !
C’est sûr, c’est étrange pour des passionnés, pour celles et ceux sont tombé-e-s dans la marmite étant petit-e !

Car la passion permet de justifier tous les vices :

  • comme celui de demander à ses salariés de se former le soir, après le travail.
  • ou alors, c’est celui qui va amener à travailler nuit et jour sans demander augmentation, jusqu’au point de rupture.
  • ou bien, de critiquer toute personne qui le soir, rentrant chez lui, ne développe pas toute la nuit sur son pc.

Et elle permet alors de critiquer un salarié, une freelance, qui ne se met pas à jour :
« ben alors, comment ça, tu ne te formes pas ? »

La vision d’un nerd qui bosse nuit et jour sur son ordinateur est encore très présente. Cette vision culpabilise beaucoup de développeurs et développeuses qui ne sont pas passionné-e-s. C’est une vision datant des années 70-80. Une période où coder n’avait pas la même saveur.
Alors, oui c’est sûr, coder aujourd’hui a toujours un je ne sais quoi de complexe, et de presque taré par moment. Et pourtant, c’est devenu un métier, presque comme un autre.

La passion à l’heure du no-code, low-code et des frameworkds multivitaminées

Un développeur qui créer un super projet via du no-code fait-il bien son métier ?
Une développeuse qui choisit Angular plutôt que React car elle veut avoir un framework stable, bien cadrée, c’est une bonne ou mauvaise développeuse ?

Plutôt que ce genre de jugement, est-ce que l’on ne se tromperait pas de combat ?

Travailler dans une équipe, dans une entreprise

Alors, au lieu de critiquer votre équipe qui fait de la merde,
Au lieu de prôner l’agilité alors que rien dans l’entreprise, ni avec le client, ne le permet (encore),
Ou bien, plutôt que de crier au scandale car vos développeurs et développeuses ne passent pas leurs soirées devant leur écran à se former,

Il est peut-être intéressant de se poser les vraies bonnes questions :

  • Mon équipe a-t-elle du temps pour apprendre de ce qu’elle réalise chaque semaine ?
  • Mes équipes trouvent-elles du temps pour faire de la veille sur les nouveautés, les bonnes pratiques ?
  • La cohésion technique de vos équipes permet-elle la critique apprenante ?
  • Des mentors sont-ils sont-elle présent-e-s dans votre entreprise ?
  • Ont-ils ont-elles envie, la motivation, de transmettre ce qu’ils-elles apprennent ?

Arrêter de pointer du doigt et avancer ensemble

Oui, votre projet a des bugs, et oui, ce sont vos développeurs et développeuses, vos infras, qui ont créé ce projet, et pourtant faut-il s’arrêter ça là dans l’analyse ?

Ne serait-il pas plus intéressant de creuser un peu, et chercher les vrais pourquoi du comment le projet en est arrivé là ?

Votre équipe ?

Besoin de plus de cohésion !

Vos équipes peinent à se former ?

Vous souhaitez passer à l'étape supérieur pour vos projets ?

Plus de qualité, de plus de cohésion technique, d'équipe ?

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici