Devrions-nous persister avec un employé qui écrit encore du mauvais code après plusieurs années? [fermé]

Je pose cette question aux programmeurs C ++ parce que: a) Seul un programmeur C ++ peut juger des mérites techniques des exemples; b) Seul un programmeur aura une idée du tempérament d'un autre programmeur qui écrit du code comme celui-ci.

Les RH et les administrateurs sont conscients qu'il y a un problème simplement parce qu'ils voient des preuves sur le terrain. C'est mon appel si nous donnons plus de temps au programmeur en question. Beaucoup d'erreurs sont à un niveau très basique - ma question (aux programmeurs) est de savoir si quelqu'un qui prétend être un développeur C ++ senior devrait bénéficier d'un doute basé sur des exemples de leur code actuel. Les non-programmeurs - même les personnes en dehors de la programmation C ++ - ne peuvent pas porter de jugement à ce sujet.

Pour le fond, on m'a confié la tâche de gérer les développeurs pour une entreprise bien établie. Ils ont un seul développeur spécialisé dans tous leurs codages C ++ (depuis toujours), mais la qualité du travail est épouvantable. Les examens et les tests de code ont révélé de nombreux problèmes, l'un des pires étant les fuites de mémoire. Le développeur n'a jamais testé son code pour les fuites, et j'ai découvert que les applications pouvaient fuir de nombreux Mo avec seulement une minute d'utilisation. L'utilisateur signalait d'énormes ralentissements, et sa conclusion était: "cela n'a rien à voir avec moi - s'ils arrêtent et redémarrent, tout recommence."

Je lui ai donné des outils pour détecter et localiser les fuites, et je me suis assis avec lui pendant plusieurs heures pour montrer comment les outils sont utilisés, où les problèmes se produisent et ce qu'il faut faire pour les corriger. Nous sommes 6 mois plus tard, et je lui ai confié la rédaction d'un nouveau module. Je l'ai examiné avant qu'il ne soit intégré à notre base de code plus large, et j'ai été consterné de découvrir le même mauvais codage qu'auparavant. La partie que je trouve incompréhensible est qu'une partie du codage est pire que l'amateurisme. Par exemple, il voulait une classe (Foo) qui pourrait remplir un objet d'une autre classe (Bar). Il a décidé que Foo détiendrait une référence à Bar, par exemple:

class Foo {
public:
    Foo(Bar& bar) : m_bar(bar) {}
private:
    Bar& m_bar;
};

Mais (pour d'autres raisons), il avait également besoin d'un constructeur par défaut pour Foo et, plutôt que de remettre en question sa conception initiale, il a écrit ce joyau:

Foo::Foo() : m_bar(*(new Bar)) {}

Ainsi, chaque fois que le constructeur par défaut est appelé, une barre est divulguée. Pour aggraver les choses, Foo alloue de la mémoire à partir du tas pour 2 autres objets, mais il n'a pas écrit de destructeur ou de constructeur de copie. Donc, chaque allocation de Foo fait réellement fuir 3 objets différents, et vous pouvez imaginer ce qui s'est passé quand un Foo a été copié. Et - ça ne fait que s'améliorer - il a répété le même schéma sur trois autres classes, donc ce n'est pas un glissement unique. L'ensemble du concept est erroné à tant de niveaux.

Je me sentirais plus compréhensif si cela venait d'un novice total. Mais ce gars fait cela depuis de nombreuses années et a reçu une formation et des conseils très ciblés au cours des derniers mois. Je me rends compte qu'il a travaillé sans mentorat ni examen par les pairs la plupart du temps, mais je commence à sentir qu'il ne peut pas changer. Donc ma question est, persisteriez-vous avec quelqu'un qui écrit un code aussi mauvais?

Mon conseil serait de le confronter à cet exemple particulier et de voir ce qu'il dit. S'il nie qu'il y ait quelque chose de mal avec le code, alors j'ai bien peur que vous ne puissiez pas faire grand-chose. S'il accepte qu'il a fait une erreur (même s'il est défensif à ce sujet), alors au moins il y a place à amélioration. Si vous acceptez le temps et les efforts pour l'améliorer, alors vous ou un programmeur senior devrez l'assoir et coder ensemble jusqu'à ce que toutes ces tendances soient aplaties (soyez prêt à consacrer cette personne pendant au moins 1 mois).

Un mauvais programmeur, je peux généralement travailler avec, mais un programmeur qui ne peut pas s'améliorer, je ne peux pas.

Donc ma question est, persisteriez-vous avec quelqu'un qui écrit un code aussi mauvais?

Non, je licencierais n'importe quel développeur professionnel C ++ qui ne possédait pas les connaissances de base en gestion de mémoire.

Si c'est quelqu'un qui vient de Java ou de C # ou quelque chose que je leur donnerais un peu de latence, mais c'est de la pure incompétence.

Nous ne pouvons pas répondre à la partie plus large de votre question. À savoir, si vous gardez ou licenciez cet employé. Il est difficile de licencier un employé, mais c'est une décision qui ne relève pas de la compétence d'une communauté comme celle-ci.

Vous avez mis à jour votre question pour restreindre les réponses aux programmeurs C ++. Pour mes antécédents / qualifications: je me suis coupé les dents en C, et je peux coder en C ++, C # et Java. Et j'aime chasser les conditions de course entre les threads parce que je pense que c'est amusant. Oui, je "reçois" un peu du twiddling.

Votre réponse et enveloppements décision autour de ceci: Que quelqu'un ou ne peut pas changer dépend de l'individu et s'ils veulent changer.

Mais commençons par quelques questions:

1. Lui avez-vous posé des questions sur le code et l'exemple que vous avez mentionné? Quelle a été son impression de la critique?
2. Lui avez-vous donné des détails au cours de ces 6 mois sur la compréhension de la manipulation de la mémoire et la vérification que son code n'avait pas de fuites de mémoire?
3. Fournissiez-vous des commentaires raisonnablement fréquents au cours de ces 6 mois pour indiquer s'il progressait ou non?
4. Avez-vous explicitement déclaré que son ancienne méthode de codage n'était plus acceptable dans le nouveau code?

Vous devez vous assurer que vous pouvez dire oui à toutes ces questions. Sinon, il y a toujours un fardeau de preuve de votre part pour communiquer avec lui.

Sa réponse à votre récent examen sera la partie la plus révélatrice.

S'il a essayé et montre des signes de progrès, vous devrez peut-être revoir votre processus de mentorat. Si quoi que ce soit, vous devrez peut-être envisager de le jumeler avec un programmeur plus expérimenté afin qu'il puisse obtenir des commentaires immédiats pendant qu'il prend des décisions de conception. Je ne suis pas un fan de la programmation par paires, mais cela peut être très utile dans un cas comme celui-ci. L'envoyer continuellement pour faire de plus en plus de révisions de l'ancien code n'est pas toujours une voie pratique d'apprentissage.

S'il n'a pas essayé, alors vous devez mieux comprendre sa motivation. Est-ce qu'il ne comprend pas qu'il a besoin d'essayer plus fort? Ne s'en soucie-t-il simplement pas? Y a-t-il d'autres domaines dans l'équipe où ses compétences seraient mieux adaptées et il est plus intéressé par cela? S'il ne voulait pas essayer, alors vous devez comprendre pourquoi.

De là, vous saurez s'il veut changer et s'il peut changer. Aucun désir de changer n'équivaut à ne pas pouvoir changer. S'il y a du désir et un certain progrès, alors envisagez fortement de changer la façon dont vous essayez de le réhabiliter.

Je crains que son mauvais code ne soit pas le seul problème dans votre équipe.

1. Qui révise son code? Pourquoi s'est-il échappé sans avertissement pour avoir accepté du code avec vulnérabilité de fuite de mémoire?
2. Pourquoi les tests de résistance n'ont-ils pas trouvé ce problème? Les utilisez-vous? Si oui, alors pourquoi ne fonctionnent-ils pas?
3. Il a été laissé sans surveillance pendant une longue période. Pourquoi?
4. Il n'utilise pas les outils que vous lui avez donnés. Comment l'avez-vous motivé à commencer à utiliser les outils appropriés?

Vous dites qu'il est dans l'entreprise depuis longtemps. Le licenciement d'une telle personne est rarement une bonne idée (sauf s'il s'agit d'un employé de type Wally). Leur connaissance des besoins des clients, des produits que vous possédez, etc. est souvent beaucoup plus précieuse que le code qu'ils écrivent.

Solutions:

• le déplacer à QA pour lui permettre d'apprendre ce qu'il faut éviter
• jumeler la programmation avec quelqu'un qui peut signaler ses erreurs
• effort QA étendu sur son code
• lui faire écrire des tests de résistance, s'il voit sa machine de développement s'écraser après avoir créé et détruit 10 000 objets, peut-être qu'il apprendra
• quelques-uns / tous ci-dessus :)

Prendre la décision de renvoyer quelqu'un est une décision difficile à prendre. Votre situation est cependant aggravée par plusieurs facteurs:

1. Il semble que ce développeur soit dans l'entreprise depuis plusieurs années
2. Le développeur écrit tout le code C ++ de l'entreprise
3. Il semble qu'avant vous, personne n'a jamais discuté du niveau de mauvais code avec le développeur
4. En tant que nouveau manager, vous n'avez aucune idée de qui / ce que le développeur sait dans / sur l'entreprise et quelles sont les ramifications politiques du licenciement du développeur

Cela dit, vous avez passé les 6 derniers mois à montrer au développeur l'erreur de ses manières et son nouveau code ne s'est pas encore amélioré.

À ce stade, vous devez vraiment commencer une gestion proactive afin que dans les 3 mois, vous

• Un programmeur C ++ décent qui sait ce qu'il fait

ou

• Terminé le développeur.

Pour ce faire, bien que vous deviez vous asseoir avec le développeur, expliquer ce qui ne va pas par écrit / e-mail, expliquer comment le développeur peut s'améliorer et déclarer très clairement que si l'amélioration attendue ne se concrétise pas, il sera résilié en 3 mois.

Vous devez également être très clair sur le fait que l'amélioration est attendue à partir de ce moment pour le reste de son emploi dans l'entreprise et pas seulement pour la période de 3 mois!

Vous devez également informer votre propre responsable et le service RH (le cas échéant).

Au cours de ce processus, vous devrez gérer activement le développeur et revoir les tâches / codes tous les 1-2 jours et vous assurer qu'ils sont à jour, en détaillant ceux qui ne le sont pas et expliquer ce qui peut être fait pour les améliorer.

Soit vous n'avez pas été clair sur le sérieux avec lequel vous prenez son mauvais travail (c'est-à-dire qu'il peut voir le temps que vous avez passé avec lui comme une option s'il veut s'améliorer plutôt que par une nécessité absolue), ou il a une mauvaise attitude insoutenable. S'il n'est pas déjà clair pour ce développeur que vous envisagez sa position sur ce problème, alors il doit être précisé (en supposant que votre leadership est d'accord avec votre autorité pour mettre fin). Nous espérons que le choc entraînera des changements.

La décision d'embauche a des implications beaucoup plus larges que ce type, vous devez tenir compte de l'impact sur l'équipe. Si son attitude est autorisée à prospérer, elle peut susciter du ressentiment de la part des autres ou inciter les autres à penser que ce genre de chose est également acceptable. Du point de vue de l'équipe, il doit être absolument clair que s'il y est allé, c'était pour les bonnes raisons et il avait amplement l'occasion de s'améliorer.

Un joyau que j'ai ramassé il y a quelques années est le fait que les personnes ayant des connaissances techniques que d'autres n'ont pas peuvent amener la direction à leur donner du mou. C'est mauvais pour l'équipe. Vous pouvez avoir peur de perdre le seul développeur c ++, mais ils peuvent être remplacés. De toute évidence, il existe des risques inhérents s'il connaît bien les produits commercialisés, mais j'ai souvent vu des personnes aux connaissances techniques / produits apparemment irremplaçables remplacées plus facilement que prévu. Les équipes et les organisations peuvent souvent combler des lacunes qui semblent initialement difficiles à combler. Bien sûr, s'il n'a pas de compétences en C ++ ou de connaissances spécifiques à l'organisation que vous pensez difficiles à remplacer, il y a beaucoup moins de problème!

Bien sûr que non. N'oubliez pas que ce n'est pas un organisme de bienfaisance, vous échangez de l'argent contre du travail. S'il ne résiste pas à son accord, comme toute transaction, j'arrêterais de payer.

Si vous voulez lui donner une chance, développez un test standardisé qui rassemble des mesures sur les fuites de mémoire. Surveillez ses progrès sur une base hebdomadaire, en insistant pour voir le code qu'il a changé, et cherchez des améliorations. S'il ne peut pas gérer à ce point, renvoyez l'invective inutile.