Développeurs, apprendre est notre métier

Categories Damien Cavailles, Vie de développeur
Iron Man apprend aussi

Développeurs, apprendre est notre métier

C’est une chose passionnante dans notre métier. Depuis que j’ai commencé à étudier, j’ai l’impression de n’avoir jamais arrêté. Tous les jours j’apprends.
Pourtant, l’environnement dans lequel on évolue ne comprend pas forcément cette dimension.

C’est intéressant de lire les échanges qui ont lieu autour de l’article écrit par Shirley : “Immersion dans la tête d’un développeur”. Au delà des mains qui codent, il y a les têtes qui pensent.

A quoi ressemble un développeur productif ?

Combien de boîtes ont une table de ping-pong, un babyfoot et un “responsable de production” qui les regarde avec malveillance ?

Dans un blog post Linkedin nommé “10 common HR mistakes in Startups” on retrouve ces différents éléments. Pourquoi vous n’arrivez pas à recruter ? Le problème ne se situe pas uniquement sur le processus de recrutement. Jenny met le doigt sur pas mal d’autres soucis : Absence de mission, valeurs d’entreprise pas assez prononcées, “My CEO is Crazy”, un management inexpérimenté, votre culture d’entreprise c’est une table de ping pong et 3 posters. Les traits sont grossis, mais beaucoup reconnaitrons avec un peu de sympathie une expérience professionnelle.

Notre job ne se limite pas à une techno. Cela ressort dans un article écrit par Julien Bordellier en 2013 sur Human Coders. Il s’était alors prêté au jeu d’écrire l’offre d’emploi idéale selon lui. Sa réponse met en évidence la face immergée de l’iceberg. Derrière le recrutement des développeurs se retrouve souvent un problème de culture d’entreprise.

Julien met le doigt sur une question importante : On ne rentre pas en tant que développeur Java/SpringBoot/Maven dans une boite, on rentre en tant que développeur et on va évoluer. Souvent l’offre de poste est trop peu restreinte : “On recherche un développeur Go”. Et du coup, on cherche quelqu’un d’opérationnel avec 3 années d’expérience sur Go. C’est la mauvaise direction. On cherche un développeur qui a envie de devenir une pointure en Go. Et peut-être qu’un jour ce dev fera autre chose. Il fera des modèles en R, il installera un Hadoop…

Parfois, on se sent handicapé par l’étiquette qui nous a été collée à l’entrée dans une boite. “Tu es dev iOS.
– Ouais mais en fait, j’aime beaucoup faire des backends en node aussi.
– On a un dev qui fait des backends déjà.
– Ah okay…”

Je rentre dans une boite en tant que développeur Android, mais je vais pas faire de l’Android pendant 10 ans. Pour qu’un Dev puisse se projeter comme étant encore dans votre entreprise d’ici dix ans, il doit pouvoir imaginer qu’il aura changé de techno, qu’il sera monté en compétence sur une autre techno. En même temps, les technos vont et viennent. L’entreprise a besoin de cette agilité. Si vous êtes une agence mobile et que vous n’avez pas une réponse sur des technos hybrides natives (NativeScript, Xamarin, ReactNative), c’est compliqué. Est-ce que vous avez besoin d’embaucher pour construire cette réponse ? S’il y a déjà des développeurs dans la maison, ils peuvent construire cette réponse.

Votre entreprise a besoin de cette agilité.

Lorsque j’étais à la DroidCon Italy, avec plusieurs speakers, nous discutions des processus de recrutement chez Google et Facebook. Nous étions tous assez sceptique concernant la pertinence des tests techniques. L’un d’entre eux expliquait qu’il est un expert sur Android : il ne sait plus faire des trucs bêtes en Javascript ou implémenter un tri à bulles en C, il n’a donc pas validé cette étape. Un Googler (NDLR : un employé de Google) qui prenait un café bien corsé avec nous, nous a alors expliqué que chez Google, on n’est pas Développeur Android, on est Développeur tout court. On peut être amené à bosser sur différents projets et d’autres technologies.

C’est le retour du syndrome du maçon qui n’a qu’un marteau dans sa sacoche (tous les problèmes ont une tête de clou), que l’on retranscrit en un développeur Java qui refait tout en Java.

Si on valorisait un Développeur correctement, on ferait avant tout attention aux softskills. Alors que je n’étais même pas diplômé, un commercial de SSII m’a dit : “Le mec, il peut être le meilleur techniquement, s’il communique mal, le projet se passera pas bien”. Cette vision, au fur et à mesure de mes expériences, s’est toujours révélée correcte. Il disait qu’il fallait être capable de communiquer quand cela se passe mal. C’est un élément que l’on retrouve dans bien d’autres métiers.

Après, j’ai entendu Thomas Gautier parler de tribus de développeurs et dire qu’aujourd’hui, le plus important chez un développeur c’est l’empathie client. Traduisez “Empathie utilisateur” si vous travaillez sur un produit en employeur final. Le Management Produit n’est pas la responsabilité d’une seule personne, mais de tous. Et les meilleurs développeurs sont ceux qui savent faire ça. Ceux qui vont sur le terrain, ceux qui interrogent les utilisateurs, ceux qui comprennent pourquoi la solution ne résout pas le problème. Ceux qui savent transcrire un besoin utilisateur en Feature Request. Ceux qui ont une mission, et on re-boucle avec la mission de l’entreprise comme pilier de la culture d’entreprise pour le développeur.

Le développeur prend une responsabilité également. Le développeur c’est celui qui s’engage à ce que ça marche (et si possible dans un temps limité). Je vois des jeunes qui sortent de l’école et qui se disent : “Oui, mais je n’ai pas d’expérience, je ferais mieux d’aller bosser en agence et je ferais du freelance ensuite”, ce qui est un non-sens. Cela voudrait dire que tu vas apprendre pendant les deux premières années de ta vie, un boulot que tu feras encore 10 ans après. La compétence que tu vas y apprendre, tu voudrais la monétiser ensuite pendant 10 ans au moins. Je ne suis pas sûr de vouloir aller par là. Et si être freelance consiste uniquement à monétiser une compétence, c’est pas joyeux non plus.

Le client et le freelance signent un contrat de prestation de service. Cela veut dire que le prestataire s’engage à régler les problèmes du client, et le client à le rétribuer financièrement. Et la responsabilité se décharge sur le développeur. C’est la même chose lorsqu’un développeur s’engage à livrer une fonctionnalité en fin de sprint. Souvent, le client veut s’assurer que tu sais déjà le faire. Il veut être sûr que tu ailles jusqu’au bout. Alors bien sûr tu n’as pas la science infuse et il y a toujours une part d’inconnu, et tu ne peux pas, avec pragmatisme, assurer à 100% que tu iras au bout. En fait, il est important à ce moment là de faire preuve d’humain pour mettre le client en confiance.

Apprendre est encore notre métier à ce niveau. Essaye d’envoyer à ton client une facture qui comprend 3 jours de documentation en amont des phases de développement, il risque de faire la tête. Et pourtant ça fait partie de la prestation. Ta mission est de résoudre ce problème, et pour ce faire, il te faut apprendre.

Aussi, même le développeur qui bosse à la Défense, il y a des fois où il a l’air improductif. Il lit de la doc, des tutos ou encore il fait des petits projets, pour apprendre. Mais oui, à ce moment là, il n’est pas en train de produire, il ne bosse pas sur son projet. Et clairement, si le dev est chargé avec 5 jours de prod par semaine, il ne pourra pas s’épanouir, il ne pourra pas grandir. C’est pourquoi, un des premiers trucs que font les devs désabusés qui se mettent en freelance, est de se garder une journée ou deux par semaine sans projet client.

Mais c’est aussi dans nos choix techniques qu’il faut prendre des risques. Prendre des risques ou encore sortir de notre zone de confort. Quand tu es face à un problème, il faut prendre d’une part le temps d’étudier les solutions en dehors de celles que tu connais, mais surtout ne pas avoir peur de choisir une solution que tu ne connais pas. Pour démarrer ce nouveau projet, tu pourrais faire le backend en Rails, parce que tu en as déjà fait, tu vas aller vite. Oui, mais bon il y a des websockets à aller chercher, avec du Node, ça serait pas bête, même si tu n’en as jamais fait.

Stephanie (membre du Club) explique à ses étudiants : « Ce n’est pas une techno pour les gouverner mais plutôt une techno pour une problématique précise ».

C’est avec ce genre d’attitude que l’on peut avancer, progresser et continuer d’apprendre.

Merci pour votre attention ! N’hésitez pas à nous partager votre vision du métier ou vos expériences en commentaire ❤
Merci aux membres du Club by JeChercheUnDev.fr pour leur contributions et leur soutien 🙂 ! Rencontrez les meilleurs freelances sur LeClub !
Nous réconcilions les développeurs avec le recrutement sur DreamJob ! Crée ton profil maintenant !

Fondateur de JeChercheUnDev.fr
Pour chaque développeur, trouver son job de rêve et changer sa vie :-)

Laisser un commentaire