Que dois-je dire sur mon CV si j'ai été promu pour avoir baissé la qualité du code afin de respecter les délais ?
J'avais un contrat de 12 mois (je vis dans un pays où ce n'est pas habituel pour les nouveaux développeurs) jusqu'à il y a quelques semaines, lorsque la direction de mon entreprise m'a fait une offre et m'a augmenté pour devenir un employé permanent. Je tiens à ce que mon curriculum vitae soit toujours à jour (surtout compte tenu du COVID). J'ai donc fait des recherches sur Google pour savoir comment l'inscrire sur mon curriculum vitae.
Les conseils que j'ai trouvés sont que je devrais généralement mentionner la réalisation qui a motivé l'embauche. Je suis d'accord.
Le problème, c'est que cette réussite consistait toujours à respecter les délais serrés des clients et, franchement, j'y suis parvenu en décidant que l'ingénierie pouvait être moins brillante dans des cas ciblés (ce que la direction a accepté).
Je suis un développeur relativement junior dans une équipe de 6 développeurs. Cependant, je suis rapidement devenu l'un des développeurs en qui la direction a le plus confiance pour livrer les choses quand je dis que je les livrerai et pour les tenir informés des compromis relatifs pour y parvenir. Depuis le peu de temps que je suis ici, j'ai toujours été capable de livrer quelque chose quand j'ai dit que je pouvais le faire.
J'ai eu quelques cas de ce genre, mais celui-ci est celui que j'ai réalisé juste avant que l'on m'offre le poste permanent. L'un de nos produits est une API batch qui est appelée une fois par jour par un seul client. Elle n'a pas besoin de renvoyer quoi que ce soit, si ce n'est un CSV des entrées échouées par courrier électronique. Le client souhaitait l'ajout d'une nouvelle fonctionnalité et le vendeur s'était engagé contractuellement à la lui fournir avant la fin du mois. Pour diverses raisons, cette demande de fonctionnalité ne nous est parvenue que le lundi de la dernière semaine du mois.
Le développeur principal a dit au directeur que le développement ne pouvait pas être fait correctement et de dire au client que cela ne pouvait pas être fait. Je ne contredis pas les développeurs seniors lors des réunions de planification de sprint, mais il était peut-être évident que je n’étais pas d’accord avec le senior. Je n'étais pas en désaccord, mais une option existait avec certains compromis. Les autres développeurs sont également assez passifs, donc personne d'autre ne l'a contredit non plus. Le directeur n'était pas content de cette situation, car le client est déjà en colère contre nous parce que nous ne tenons pas nos promesses. Le manager m'a convoqué dans son bureau après la réunion pour me demander si je voyais une alternative. Je lui ai dit que je pouvais faire en sorte que quelque chose fonctionne, mais que cela doublerait probablement le temps de traitement de l'API (ce qui ajouterait 4 minutes) puisque je n'ai pas de compétences particulières en SQL. Le directeur a accepté et, apparemment, le client n’a même pas remarqué.
Je ne sais pas quelles auraient été les conséquences d'un dépassement du délai, mais elles ont été suffisamment importantes pour que le PDG de notre entreprise de 1000 personnes m'envoie un courriel de remerciement pour l'avoir livré.
Un autre cas n'a pas attiré autant d'attention, mais il s'agissait d'un processus que nous devions exécuter sur une base de données. La bonne façon de procéder aurait été d'écrire un processus batch correct dans le méga système Java que nous utilisons, de le soumettre à tous les processus d'assurance qualité habituels et de le laisser sortir deux semaines plus tard. J'ai proposé au responsable un script Python qui devrait être exécuté manuellement et serait terriblement inefficace (il devait être exécuté pendant la nuit), mais qui, s'il était déclenché une fois par mois, permettrait de tenir le problème à distance jusqu'à l'arrivée d'une solution permanente. Comme il s'agissait d'un problème de production, il a accepté cette solution comme mesure palliative. Il s'agissait essentiellement d'une boucle for bon marché qui vérifiait les lignes pour un certain type de données erronées et les reformatait.
Existe-t-il un moyen d’indiquer ce type de choses sur mon CV sans que j’ai l’air d’un programmeur de pacotille qui sape les développeurs seniors ? J'admets que mes solutions ne sont pas solides d'un point de vue technique, mais elles répondaient aux besoins de l'entreprise à l'époque et l'inefficacité n'était pas pertinente dans la plupart des cas.
Vous avez trouvé plusieurs façons efficaces (et non efficientes) de résoudre les problèmes sans avoir recours à l'ingénierie à outrance et "Le fait est mieux que la perfection" ;
Trouver une solution qui est juste assez bonne est une capacité importante pour un ingénieur, car sinon vous passeriez beaucoup de temps à optimiser quelque chose qui ne vaut pas la peine d'être optimisé. Si quelque chose n’est pas utilisé souvent, il est souvent inutile de l’optimiser. Il existe un joli [XKCD-Comic][1] avec un tableau qui vous indique combien de temps vous devez investir dans quelque chose.
Une solution n'a de valeur que si elle est (ou peut être) utilisée, donc avec un hack vous avez permis au client de continuer à travailler jusqu'à ce que vous ayez une solution.
Il n'y a aucune raison de dire à qui que ce soit que vous n'étiez pas d'accord avec votre supérieur. Choisissez simplement quelque chose comme "Capable de produire des solutions efficaces sous la pression du temps".
J'admets que mes solutions ne sont pas solides sur le plan technique, mais elles étaient adaptées aux besoins de l'entreprise. mais elles répondaient aux besoins de l'entreprise à l'époque et l'échange d'inefficacité n'était pas pertinent. n'était pas pertinente dans la plupart des cas.
Vous n'aviez qu'une seule tâche : "trouver une solution qui fonctionne dans les limites du temps imparti et qui résout le problème". Et c'est exactement ce que vous avez fait.
[1] : https://xkcd.com/1205/
J'ai l'impression que seule la direction a donné des réponses ici, car il n'y a eu que des éloges pour le respect de délais déraisonnables.
Il y a un autre point de vue ici. Il ne faut pas sous-estimer les perturbations sociales que vous déclenchez au sein de l'équipe de développement lorsque la direction prend des raccourcis et ignore les opinions des développeurs seniors. Il existe un dicton qui va à peu près dans ce sens :
C'est une chose si vous vous engagez une ou deux fois dans la voie de la piraterie parce que vous y êtes contraint, mais c'en est une toute autre si elle devient la norme. Et d'après votre description, il me semble que la direction est devenue assez à l'aise avec la pratique qui consiste à vous utiliser pour prendre des raccourcis. Vous devriez sérieusement envisager de soulever cette question auprès de votre direction et de vos cadres supérieurs afin de maintenir un environnement de travail sain. Une entreprise est un équilibre entre le développement et la gestion, et non une simple structure descendante. Le mot "non" n'existe pas pour rien et vous devriez vous entraîner à l'utiliser.
Toutefois, il s'agit encore plus d'une question de gestion que de la vôtre. Il n'y a donc aucune raison de le mentionner d'une manière ou d'une autre dans votre CV. Je suis donc d'accord avec vous :
Comme le dit l'adage "la perfection est l'ennemi du bien", faire des compromis techniques pour satisfaire les besoins de l'entreprise est pratiquement de rigueur. Les bons développeurs/programmeurs/ingénieurs sont ceux qui peuvent identifier les compromis acceptables qui peuvent être faits.
Dans votre exemple d'API, le client était clairement prêt à accepter un retard de 4 minutes dans le traitement pour quelque chose qui fonctionnait et était livré à temps.
Idéalement, vous devriez chercher à minimiser la dette technique lorsque vous faites ces compromis - mais cela fait partie intégrante de l’expérience et du fait de savoir où vous pouvez gagner du temps et quand vous devez vous assurer que quelque chose est fait "correctement" afin de gagner plus de temps à long terme.
Ma question fondamentale est la suivante : existe-t-il un moyen d’inscrire ce type de choses sur mon CV sans que j’ai l’air d’un programmeur de pacotille qui sape les développeurs seniors ?
Dans votre CV, il n’est pas nécessaire d’entrer dans les détails de votre solution - vous pouvez simplement dire que vous avez de bons antécédents en matière de respect des délais sur des projets sensibles au facteur temps et mentionner des exemples sans donner de détails sur la mise en œuvre réelle.
Ce que vous faites n'est PAS du "hacking", mais de la "recherche de solutions".
Je travaille comme développeur et consultant depuis 20 ans maintenant, et cette compétence est ce que les employeurs recherchent : Ne la laissez pas de côté dans votre CV, mais mettez-la en avant : Vous essayez de trouver des solutions, même si cela signifie emprunter des chemins "inhabituels" ;.
N'écrivez pas que vous le faites dans le dos des développeurs seniors, mais que vous le faites chaque fois qu'on vous demande des solutions, même si des personnes plus expérimentées ne sont pas d'accord ou disent que ce n'est pas possible.
Il existe une citation d'Albert Einstein qui décrit exactement votre situation :
Tout le monde savait que c’était impossible, jusqu’à ce qu’un idiot qui ne le savait pas arrive et le fasse.
J'ai travaillé avec de nombreux développeurs et je connais toutes les facettes de la situation :
J'ai travaillé avec un développeur qui fait partie du top 1 % des experts en JavaScript sur stackoverflow. C'est un génie et j'admire vraiment chaque ligne de code qu'il écrit. Mais très souvent, il ne terminait pas ses projets : Il préférait ne pas finir quelque chose plutôt que de le finir alors qu'il n'était pas satisfait de la beauté du code.
Et j'ai travaillé avec des développeurs qui étaient extrêmement efficaces, mais qui prenaient beaucoup de raccourcis qui rendaient les solutions presque impossibles à maintenir (chemins codés en dur, nombres magiques, etc.).
J'ai toujours préféré le "fait" au "beau", et mes clients ont fini par faire de même : Ils préfèrent avoir "quelque chose" à la date limite plutôt que "rien, mais ce sera beau dans un peu plus de temps" ;
Une seule chose : les solutions de contournement, les raccourcis et les "hacks" doivent être compréhensibles, documentés et maintenables, alors il n'y a rien contre des solutions comme la vôtre.
Vous avez donc créé un logiciel qui a mis quatre minutes à fonctionner (parce que votre code n'était pas très bon). S'il me faut 12 heures pour faire le travail à la main, votre logiciel me fait gagner 11 heures 56 minutes. Si vous avez écrit un meilleur code qui fonctionne en une seconde, cela me fait gagner 11 heures, 59 minutes, 59 secondes. Si le meilleur code a été livré une semaine plus tard et que j'ai donc dû faire le travail manuellement cinq fois, les 3 minutes 59 secondes supplémentaires ne compenseront jamais le temps perdu.
Ou le rendre plus extrême. Le logiciel doit fonctionner en 24 heures. Votre code est mauvais, il nous faut donc un ordinateur de 5 000 dollars pour le faire fonctionner en 24 heures. Avec un meilleur code, un ordinateur à 2 000 $ pourrait le faire fonctionner en 24 heures. Une économie de 3 000 $. S'il vous faut deux semaines pour rendre le code plus rapide, c'est une perte globale.
Être capable de le livrer au moment voulu est une très, très bonne chose. De plus, un très bon développeur peut écrire un mauvais code de manière à pouvoir l'améliorer facilement par la suite. Les mauvais développeurs écrivent un mauvais code qui est difficile à remanier pour le remettre en bon état, les bons développeurs sous la pression du temps écrivent un mauvais code qui est facile à améliorer.
Paraphrasant Einstein,
Je sais que de nombreux développeurs sont fiers du code qu'ils écrivent et ne sont pas du tout d'accord avec cela. Mais d'un point de vue commercial, dès que l'objectif de qualité du logiciel est atteint, améliorer encore la qualité revient à dépenser du travail supplémentaire pour quelque chose qu'on ne vous a pas demandé de faire ou pour lequel vous n'êtes pas payé. La qualité absolue n'est tout simplement pas atteignable : quelle que soit la qualité de votre logiciel, il est toujours possible de l'améliorer.
Il est clair que vous n'avez pas été félicité pour avoir abandonné la qualité de votre code. Vous avez été félicité pour avoir maintenu une qualité de code acceptable tout en respectant un délai. C'est ainsi que vous devriez le formuler dans votre CV.
Je n'ai pas d'opinion particulière sur ce qu'il faut mettre sur votre CV pour cela, même si j'ai tendance à être d'accord avec les réponses qui disent que ce genre de choses ne rentre pas vraiment dans un CV.
Cependant, j'aimerais souligner ce qui se passerait si je vous interrogeais et que vous décriviez la situation comme vous l'avez fait dans la question.
Ma première pensée serait : "Bien, j'aime quelqu'un qui peut faire ce qui est nécessaire à court terme tout en reconnaissant les compromis qu'il fait". Mais il y a aussi un problème assez clairement identifiable dans la gestion des projets logiciels de votre entreprise que je vous demande d'identifier.
La réponse que j'aimerais entendre est que quelqu'un qui ne fait pas partie de l'équipe technique a promis quelque chose à un client dans un délai précis sans avoir en main un devis de l'équipe technique pour savoir quand il pourrait être livré. Ce faisant, on s'expose à un désastre à long terme. Si vous ne pouviez pas identifier ce genre de problème, je serais très méfiant de vous avoir dans mon équipe.
En outre, une fois le problème identifié, quelqu'un doit mettre en œuvre des solutions à long terme pour s'assurer que le problème est progressivement réduit et, idéalement, finalement éliminé. Je vous demande ce que vous avez fait, dans votre nouveau rôle de gestionnaire, pour que cela se produise. Si vous ne pouvez pas me donner une bonne réponse à cette question, encore une fois, je serais très réticent à vous engager. C'est bien d'assumer la responsabilité de solutions à court terme coûteuses, mais si vous n'assumez pas la responsabilité de solutions à long terme qui éliminent la nécessité de ces solutions coûteuses à court terme et font économiser du temps et de l'argent à l'entreprise dans son ensemble, je considérerais que vous n'êtes apte qu'à un rôle subalterne jusqu'à ce que vous appreniez à le faire.