Ma première idée a été d'ajouter un test, vérifié par un système d'intégration continue, afin de limiter le préjudice qu'il peut faire à votre projet, ce qui est aussi le point de réponse.

Ensuite, il y a le problème que ce type fait réellement de l'argent pour l'entreprise, d'une manière perverse. En faisant payer le client sur les heures passées, cela s'avère être un avantage monétaire d'avoir quelqu'un qui défait le travail des autres. Ce serait comme être engagé pour construire un mur et avoir à la fois un maçon en train de faire un mur et un autre employé le démolissant.

Cependant, à long terme, le client peut changer d'avis (peut-être pour ne plus jamais utiliser services de votre entreprise) s'il découvre que vous le faites (par inadvertance ou exprès), et que cela pourrait également être considéré comme une négligence de votre part.

Votre patron n'a probablement pas ces raisons machiavéliques pour pas le renvoyer, cependant. À ce stade, vous avez une personne dont le travail n'est pas du tout utile à l'entreprise. Je suggérerais de le changer pour une autre position . Vous dites que c'est une cause perdue de lui faire coder correctement python. Mais peut-être qu'il peut utiliser un bon manuel d'utilisation. Ou testez le programme sur ses différentes itérations pour vérifier que les fonctionnalités fonctionnent comme prévu. Techniquement, il ne travaillerait plus en tant que développeur . Cependant, c'est quelque chose qui repose assez souvent sur l'équipe de développeurs elle-même et, étant une petite entreprise, je suppose que vous n'avez pas d'équipe dédiée pour cela.

En tout cas, un mauvais testeur qui trouve qu'occasionnellement un bogue sera plus utile que l'anti-développeur qu'il semble avoir été en travaillant jusqu'à présent. Ainsi, toute tâche qui le tient occupé est probablement bénéfique, même avec un faible rendement. Et les compétences de développeur, lui permettant de lire et de comprendre le code, sont utiles pour diriger les cas de test, même s’il ne parvient pas à écrire le bon code (alors que ce n’est pas si grave s'il ne peut pas).

Un problème potentiel avec cette approche serait qu'il a réussi à tester le programme trop vite (peut-être parce qu'il saute la moitié des exigences?). La prochaine étape serait qu'il codait des tests automatisés pour vérifier les exigences du projet, afin qu'il n'ait pas besoin de passer du temps à effectuer en permanence les mêmes tâches ennuyeuses, et ils sont exécutés de manière cohérente à chaque fois. (Evidemment, de nombreuses itérations seront nécessaires pour pouvoir avoir une couverture complète des conditions requises)

En tant que son manager, il est de votre devoir de le tenir responsable de son absence de procédure de suivi. Je commencerais une trace écrite dans ce cas, car cet employé ne semble pas disposé à modifier ses mauvaises habitudes.

Si la trace écrite ne fonctionne pas, placez-le sur un plan officiel d'amélioration des performances [PIP] , en collaboration avec les RH, avec des objectifs clairement définis , des mesures et un délai pour atteindre les objectifs.

Si le développeur ne parvient pas à atteindre les objectifs, vous devez être libre et clair pour les laisser partir, et votre esprit doit être libre de toute culpabilité. Il peut également partir seul, ce qui résoudra également votre problème. J'espère que cela servira de réveil et qu'ils se ressaisiront.

Vous avez une longue liste de choses pour lesquelles il est mauvais.

Dans quoi est-il bon?

Découvrez-le et configurez-le à la place.

Autant que cela puisse me gêner de suggérer, avez-vous envisagé d'implémenter quelque chose comme les tests TDD ou BDD dans votre pipeline? D'après mon expérience, une suite de tests bien développée, même si elle n'est pas implémentée de manière stricte, peut faire des merveilles pour les sous-performants. Cela n'accélérera pas son développement, mais cela rendra les objectifs plus transparents en ce qui concerne ce qu'il doit faire pour que ses correctifs soient à jour. Mieux encore, des choses comme la couverture de code peuvent être un excellent outil pour pousser la motivation car il aura une métrique visible associée à son travail en plus des avantages évidents.

Cela signifie également s'il ne fait pas les tests passer, il ne peut pas passer à plus de destruction.

Mon avis

Parfois, dans les équipes, il y a quelqu'un qui ne rentre pas dans le moule et ça ne devrait vraiment pas être sur vos épaules, mais c'est ainsi que vous devrez gérer cela en interne. En fin de compte, en tant que responsable, vous devez prendre les bonnes décisions pour l'équipe et si cela signifie limiter ce qu'il peut travailler et faire, il doit en être ainsi. Personnellement, je saisirais toutes les occasions de le rendre évident s'il ne s'améliore pas vous ne pouvez pas vous tenir la main autant que possible . Travaillez avec la haute direction et s'il ne travaille toujours pas, il y a un moment où vous devez l'appeler et l'informer sans ambages que cela ne fonctionne pas et que votre poste est qu'il doit partir ou passer à une autre partie du Entreprise. Certaines des choses que vous avez mentionnées si elles étaient effectuées en série vous mettraient au chômage dans de nombreuses entreprises que je connais.

Mon opinion impopulaire

Vous êtes un responsable et vous êtes en contact direct avec la haute direction, il est peut-être temps d'aligner un remplaçant si son comportement continue.

"J'ai récemment été promu en tant que manager" - puis commencez à apprendre à devenir manager. Qu'on le veuille ou non, d'après ce que vous avez décrit, ils font le travail pour lequel ils sont payés, mais vous ne l'êtes pas.

Vous avez un employé auquel vous semblez avoir abandonné - ce n'est pas bien la gestion. Vous faites leur travail pour eux - ce n'est pas une bonne gestion. Vous leur permettez de perturber le projet - ce n'est pas une bonne gestion.

Cet employé est clairement (et peut-être à juste titre) mécontent, mais au lieu de traiter les causes de sa plainte, vous les aggravez. Peu importe que vous soyez un meilleur codeur ou que vous connaissiez mieux les subtilités de python que lui, car votre rôle actuel est un gestionnaire et non un codeur et le travail d'un gestionnaire est d'amener d'autres personnes, y compris lui, à veulent faire ce que vous voulez qu'ils fassent. Vous voulez qu'il produise un code qui réponde aux normes de votre entreprise. Découvrez pourquoi il ne veut pas et changez quelque chose pour qu'il le veuille. Dans le cas extrême, vous pouvez le forcer à choisir entre le faire à la manière de l'entreprise ou travailler pour une autre entreprise, mais vous devez considérer qu'il s'agit d'un échec de votre part, peu importe comment cela se passe.

Un développeur senior n'est pas censé être senior simplement en vieillissant et en étant là depuis longtemps, mais en étant un bon développeur. Cette personne ne ressemble pas à un développeur senior.

Je suggère un tête-à-tête où vous expliquez la situation, et que son travail n'est pas satisfaisant, qu'il ne vaut pas réellement son salaire (n'est-ce pas?), et ce qu'il pense qu'il et vous pouvez faire pour changer cela.

Je pense honnêtement que votre réponse réside dans votre titre "comment aider quelqu'un qui est au-delà de l'aide". Vous pensez qu'il est au-delà de l'aide. Je pense qu'il semble qu'il est au-delà de l'aide. Il pourrait en fait être au-delà de l'aide.

S'il s'agissait d'un développeur junior, vous accepteriez, au maximum, ce type de performance pendant les deux premiers mois - après cela, ils doivent livrer. C'est le maximum, je pense qu'embaucher quelqu'un qui ne peut pas produire de code le premier jour est une embauche risquée.

Ce gars porte le titre de senior, il est censé être celui qui encadre les développeurs juniors ou du moins fonctionne bien .

Vous avez essayé de le persuader de changer, et cela n'a pas fonctionné. Le changement doit être forcé, ce qui nécessite des mesures disciplinaires ou un licenciement - donc, une intervention de la direction.

Actuellement, je trouve plus facile et plus rapide de ne pas lui confier de tâches, les délais se rapprochent et c'est plus rapide pour les faire moi-même. En fait, j'envisage de changer d'emploi à cause de lui.

C'est ce que votre patron doit savoir. En fonction de votre relation, vous devrez décider de vous concentrer sur les échéances imminentes ou sur votre désir de changer d'emploi.

Puisque votre patron craint de perdre des heures facturables, vous pouvez lui signaler que le remplacement de $ SeniorDev avec un développeur efficace se traduira par le même nombre d'heures facturables tout en améliorant le moral et la capacité de respecter les délais. Cela fonctionne mieux pour vous deux.

D'après mon expérience dans le domaine des logiciels, si un développeur ne comprend pas l'importance de tester et de vérifier le code avant de s'enregistrer, alors il ne sert à rien d'essayer de travailler avec lui. Il est préférable de passer à autre chose et de concentrer vos efforts pour convaincre les autres de la nécessité de le faire.

Tout d'abord, vous n'avez pas expliqué quelles sont les exigences et les compétences du poste de direction dans votre entreprise. Un rôle senior signifiant que les compétences, les capacités et les attentes diffèrent considérablement d'une entreprise à l'autre. Il est senior là-bas donc il faut d'abord vérifier s'il remplit les critères définis par votre entreprise.
Concernant la situation et les problèmes que vous soulevez. Je pense que vous essayez d'aborder trop de choses à la fois.
Commencez par le plus important qui est le fait que le code n'est pas fonctionnellement ce dont le client a besoin, car les exigences sont manquantes.
Une fois que vous avez répondu, vous pouvez passez à la façon dont le code pourrait être meilleur, en passant éventuellement à la façon de coder correctement en Python.
Si vous commencez par de telles discussions, il est facile de se laisser distancer parce que les développeurs ont généralement des opinions différentes et assez fortes sur ces points.
Peut-être que le gars est dépassé ou n'aime pas Python et cela affecte ses performances.

D'après la façon dont vous avez décrit cela, je placerais probablement ce développeur dans le département "pas très bon" et je me demanderais si je le souhaite dans ma petite équipe, où chaque développeur a un impact énorme sur tout le reste. Les développeurs pauvres peuvent se cacher dans de grands magasins et travailler sur des zones de code partitionnées qui ont peu ou pas d'impact sur le reste, mais les petits magasins permettent généralement à tout le monde de toucher, et donc de casser, d'autres parties du code. Sortir un tel développeur du système est souvent un cas d ' addition par soustraction . Vous devriez expliquer ceci au grand patron, que vous préférez qu'il ne code pas du tout pour que l'autre développeur et vous-même puissiez en faire plus.

Si le problème concerne uniquement les heures facturables, alors vous pouvez également discuter avec le grand patron de la façon dont le remplacement de cette personne par une personne plus junior et moins chère peut être une double victoire. Vous obtenez des marges plus élevées sur les heures facturables et le remplacement, tout en ne pouvant peut-être pas résoudre les problèmes les plus difficiles, peut au moins être productif pour faire avancer les parties les plus faciles de la solution sans nuire au travail des autres.

Vous en faites donc une analyse de rentabilisation et vous la présentez au grand patron comme un moyen d'améliorer l'entreprise en remplaçant la zone problématique. En tant que manager, vous apprendrez que votre rôle va de la simple concentration sur la technologie à la réflexion en tant que propriétaire d'entreprise et à la compréhension de l'impact global.

En ce qui concerne la manière de coacher réellement cette personne, ce que je mets généralement en place tôt dans un magasin que je dirige est une Définition de Terminé solide, bien définie et socialisée. C'est la ligne dans le sable qui dit qu'aucun travail ne peut être considéré comme terminé (en fonction de votre configuration qui peut être fusionnée pour master, poussée pour produire, etc.) jusqu'à ce qu'il remplisse toutes les choses de votre DoD. Ensuite, vous appliquez cela avec TOUT le travail effectué par l'équipe de manière uniforme. Donc, si ledit développeur ne termine pas ses tests, le travail est arrêté dans ses voies avec une déclaration explicite de "tests adéquats manquants" et le développeur doit terminer cela avant de pouvoir passer à la tâche suivante.

Oui, cela signifie que vous devez maintenant utiliser une partie de votre temps pour auditer le travail de votre boutique, mais cela fait partie de la gestion. Vous pouvez également utiliser ceci, ou d'autres types d'examen par les pairs, pour parcourir les check-ins proposés et attraper certains de ces refacteurs nuisibles que vous avez mentionnés avant qu'ils n'affectent le reste de la base de code. Grâce à votre DoD, vous définissez des portes autour de la qualité (c'est-à-dire - passe un PR) qui empêchent les comportements dommageables.

Si vous appliquez ces portes et empêchez vraiment tout développeur de proposer des solutions partiellement ou mal faites, cela deviendra tout à fait évident qui obtient combien fait à quelle vitesse. Vous pouvez ensuite utiliser ce type de suivi pour quantifier la valeur de chaque développeur, vous aidant à faire valoir auprès du grand patron dont j'ai parlé plus haut la productivité réelle et le rapport qualité-prix de chaque développeur de l'équipe.

Il semble que son travail consiste à produire des heures facturables, pas des logiciels, et il fait bien son travail. Votre client est stupide, votre patron est sans scrupules. L'employé est au-delà de toute aide.

Vous avez deux choix: arrêter de vous soucier ou trouver un autre emploi.