Je suis en pleine réflexion ces temps-ci quant au travail fourni par deux apprentis que j’encadre. Ils sont de niveau bac+2, et j’ai fais pour ma part un stage à ce niveau, donc je peux faire un parallèle entre eux et moi. Et quelque chose me frappe: Ils sont seuls au monde. Quand ils développaient, ils ont oublié qu’il existait des gens autour d’eux, des gens avec qui ils doivent travailler, des gens à qui il faut vendre leur produit et des gens qui doivent utiliser leur produit et à qui il faut assurer un support.

De plus, dans une très petite société (moins de 10), un développeur doit dépasser son contexte. Il doit pouvoir s’adapter à chaque situation, et celle ci peut passer du tout au tout à chaque moment de la journée de travail. Les développeurs l’oublient. Comme ils restent dans leur bulle, ils oublient que d’autres gens vont utiliser ce qu’ils produient. Ces développeurs produisent leur code à leur image, lisent une spec, la code, au mieux la teste, mais oublient tout simplement tout le reste.

⇀ Ils oublient leurs collègues développeurs, en décidant de ne pas respecter les conventions de codage, les règles de nommage, les principes de base, de documenter leur code, de le commenter;

⇀ Ils abandonnent l’ingénieur système, qui met en production leur application, en ne discutant pas avec eux aux moyens de remonter les problèmes (logs), en ne testant pas préalablement les package générés, en développant sur leur système en oubliant la configuration des systèmes en prod, en ne documentant pas les fichiers de configuration, les variables, les comportements attendus en cas de problème;

⇀ Ils ne facilitent pas la vie de la QA, en ne leur fournissant pas les moyens d’exploiter avec satisfaction l’application produite à des fins de tests: En faisant une application inutilisable, la QA prendra le moins de temps possible à la valider, et au final le produit ne sera pas testé. C’est au développeur de définir avec lui les moyens de tests, outils, jeux de données prèts à être utilisés;

⇀ Ils oublient de vendre leur application. Qui n’a jamais été la « victime » de l’effet démo ? Personne. Et la faute à qui ? Une coupure réseau pendant une démo d’une appli sur le net, certes, ça arrive. Mais la plupart du temps, c’est juste la faute du développeur, qui est resté dans sa propre idée de l’utilisation du soft. Il a juste oublié d’imaginer donc de jouer un simple test fonctionnel;

⇀ Et au final, et pour moi le pire, ils ignorent totalement le client final. Et là je me demande à quoi ils servent si ils ne réfléchissent pas un seul instant à cet utilisateur qui va devoir utiliser l’outil qu’ils produisent pour eux au quotidien. Je ne parle pas juste que de l’ergonomie générale de l’application qu’ils auront oublié, du manuel d’utilisation qu’ils n’auront pas rédigé, mais des tests de leur application qu’ils ne prennent même pas la peine de faire (je ne parle pas des tests unitaires, fonctionnels qu’ils sont censés faire !), du bâclage de la correction des bugs, des petits détails qui rendent utilisables le logiciel en question… toutes ces choses qui en font un outil formidable.

Alors, je n’ai qu’un conseil: Regardez autour de vous. Vous n’êtes pas seuls. Vous êtes entourés de gens surement compétants, surement formidables, de clients pressés d’utiliser vos produits (et au final de vous nourrir, pensez-y), alors ne les oubliez pas. Ils sont là, allez leur parler, communiquez, échangez. Pour moi, dans monde idéal, avant de la vendre, le développeur devrait faire tester à plusieurs personnes de sa société plus longtemps qu’un simple test leur application. Ca peut suffire de faire d’un tool qui passerait durement pour un prototype à un outil prêt à mettre en production.

Ceci est une adaptation un peu libre d’un article de Ted Dziuba initialement intitulé Why Engineers Hop Jobs.

Pourquoi autant de haine envers ma génération ? Tout a commencé quand quelqu’un quitta l’entreprise de Jason Calacanis, une start-up qui prone le spam à un rythme industriel, Mahalo, pour un job mieux payé chez un concurrent. Sans relache, Calacanis descenda en public le mec, et provoqua une cascade de réactions dans la blogosphère à propos des ingénieurs logiciels et de leur soif: Ils seraient des glandeurs, on ne pourrait pas compter sur eux, tout leur appartiendrait.

Je suis un glandeur et pas fiable, mais ce n’est pas pour ça que j’ai changé de job dans le passé. Les mecs de ma génération ont une très faible tolérance du bullshit. Et de façon générale, bosser dans le logiciel, c’est faire carrière dans le bullshit. Et si en plus, vous prenez en compte de la charge de bullshit rajoutée par votre boss style bac+5 grande école non technique, comme pas mal de CEO qui essaient en vain de devenir riche dans la Silicon Valley en engageant des dévelopeurs pour « coder cette idée rapidement », alors sans surprise un bon ingénieur se cassera du job après seulement quelques mois.

Quand vous êtes ingénieur, vous vous entendez dire que vous êtes « chanceux d’avoir un job », car il y a des « centaines de mecs qui font la queue dehors pour l’avoir et qui sont prèts pour ». (En oubliant qu’il y en a un milier prêt à prendre le job du riche connard qui dit aux autres ce qu’ils ont à faire). Faut être mentalement malade pour dire ça. Un CEO qui fait travailler un ingénieur 80h par semaine est un entreprenneur accompli, mais un ingénieur qui demande une chaise confortable c’est une princesse. Du coup, quand on en a marre d’être à genoux à cause des vos exigeances farfelues, ne soyez pas surpris qu’on quitte le navire pour un meilleur salaire.

Cependant, je reconnais la valeur ajoutée des commerciaux et du management. Quelqu’un doit vendre le code que j’écris, et qui en retour me donne à manger. Comme je suis ingénieur, j’aime l’optimisation itérative. A chaque fois que je quitte un boulot, j’affine la liste des nécessités d’un probable futur employeur pour que je sois d’accord de travailler avec. Après chaque boulot, j’ajoute un ou deux besoins à la liste, et au final, je n’en suis que plus heureux à chaque fois.

Ma liste est:

• L’organisation doit avoir besoin de moi autant que j’ai besoin d’elle;
• Mon manager direct doit avoir eu un cursus technique, assez pour comprendre que la programmation, c’est difficile;
• Mon manager direct doit avoir assez d’expérience ou d’intelligence pour que je puisse croire à ses décisions, même si je ne comprends pas complètement le raisonnement;
• Je dois avoir une confiance absolue quant au business plan;
• Je dois avoir une confiance asbolue en « le coté business » pour executer ce plan;

Donc, Jason, quand un mec quitte Mahalo, il ne t’a pas seulement laissé en plan. Il a aussi rajouté quelque chose à cette liste. Peut-être que t’arriveras à trouver ce que c’est.