Inspirer un collègue à adopter de meilleures pratiques de codage?

Dans la question Manipuler mon collègue désuet , diverses personnes ont discuté de stratégies pour traiter avec des collègues qui ne souhaitent pas intégrer leur flux de travail à celui de l'équipe.

J'aimerais, si possible, apprendre quelques stratégies pour "enseigner" à un collègue qui est simplement ignorant des techniques et outils modernes, et peut-être un peu apathique.

J'ai commencé à travailler avec un programmeur qui, jusqu'à récemment, travaillait dans un isolement relatif, dans une autre partie de l'entreprise. Il possède une connaissance approfondie du domaine et, surtout, il a démontré de bonnes compétences en résolution de problèmes , ce que de nombreux candidats semblent manquer.

Cependant, le code (C #) réel que j'ai vu est un retour aux jours VB6. Structure procédurale, notation hongroise, variables globales (abus de static), pas d'interfaces, pas de tests, non-utilisation de génériques, lancer System.Exception... vous avez l'idée.

Ce programmeur est un peu plus âgé que moi et, à première vue au moins, ne cherche pas activement un changement positif. Je ne vais pas dire résistant au changement, car je pense que c'est en grande partie une question de savoir comment le sujet est abordé , et je veux être prêt.

Les programmeurs ont tendance à être des gens têtus, et entrer avec des armes à feu flamboyantes et instituer des revues de code rip-it-to-shreds et des politiques strictement appliquées ne va probablement pas produire le résultat final que je veux. S'il s'agissait d'une nouvelle recrue, d'un programmeur junior, je ne penserais pas à deux fois à prendre une position de «mentor», mais je suis extrêmement prudent de traiter un employé expérimenté comme un débutant sans aucune idée (ce qu'il n'est pas - il n'a tout simplement pas suivi certaines avancées dans le domaine).

Comment pourrais-je augmenter la norme de qualité du code de ce développeur à la manière de Dale Carnegie, par une persuasion douce et des incitations non matérielles? Quelle serait la meilleure stratégie pour effectuer des changements subtils et graduels, sans créer de situation contradictoire?

D'autres personnes - en particulier les développeurs principaux - ont-elles déjà été dans ce type de situation? Quelles stratégies ont réussi à stimuler l'intérêt et à créer une dynamique de groupe positive? Quelles stratégies n'ont pas réussi et seraient mieux à éviter?

Précisions:

J'ai vraiment l'impression que plusieurs personnes répondent en fonction de leurs sentiments personnels sans réellement lire tous les détails de la question. Veuillez noter les éléments suivants, qui auraient dû être sous-entendus, mais j'explique maintenant:

• Ce collègue n'est que mon "senior" en raison de son âge. Je n'ai jamais dit que son titre, sa sphère d'influence ou ses années au sein de l'organisation dépassaient le mien, et en fait, aucune de ces choses n'est vraie. C'est un programmeur LOB qui a été absorbé par l'atelier de développement principal. C'est ça.

• Je ne suis pas un nouvel embauché, un programmeur junior ou un autre idiot naïf avec de grands projets pour transformer l'entreprise du jour au lendemain. Je suis essentiellement en charge du processus logiciel, mais comme beaucoup de ceux qui ont travaillé en tant que "leads" le savent, les responsabilités ne sont pas toujours en corrélation précise avec l'organigramme.

• Je ne demande pas aux gens comment se débrouiller, venir en enfer ou à marée haute . Je pourrais le faire si je le voulais, avec pour résultat net que cette personne deviendrait rancunière et / ou renoncerait. Essayez de comprendre que je recherche une méthode sociale et coopérative pour conduire le changement.

• La mention de "... variables globales ... pas de tests ... de lancer System.Exception" visait à démontrer que les problèmes ne sont pas seulement superficiels ou esthétiques . Les pratiques qui peuvent fonctionner pour des applications CRUD relativement petites ne fonctionnent pas nécessairement pour les applications de grandes entreprises, et en fait, aucun du code n'a jusqu'à présent réussi les tests d'intégration.

S'il vous plaît, essayez de prendre la question pour argent comptant, acceptez que je sache de quoi je parle et répondez à la question que j'ai posée ou passez à autre chose.

PS Ma sincère gratitude à ceux qui - ont offert - des conseils constructifs plutôt que de discuter avec la prémisse. Je vais laisser cela ouvert encore un peu car j'espère en savoir plus sur la manière des expériences du monde réel.

Le point de départ est de connaître votre public . Vous semblez déjà comprendre cela parce que vous connaissez la différence entre le mentorat d'un collègue junior et l'influence d'un collègue senior.

Vous devez encore comprendre ce qui motivera cette personne en particulier. Ce qui fonctionne sur un vieux geezer (comme moi), pourrait ne pas fonctionner pour votre ancien geezer.

S'il aime encadrer / enseigner aux autres, vous pouvez aborder un problème en posant des questions comme «pourquoi faites-vous de cette façon? Cela peut ouvrir un dialogue où vous pouvez lui demander d'évaluer de nouvelles approches et de donner son avis.

Si cela ne fonctionne pas, vous pouvez signaler des bogues qui peuvent être évités en utilisant les pratiques ou les styles que vous souhaitez qu'il adopte. Cela demande beaucoup plus de travail car vous devez trouver les bogues et montrer comment les comportements que vous souhaitez encourager pourraient vous aider.

S'il semble disposé à aider les autres, vous pourriez faire appel à son désir d'aider les débutants . Expliquez que «les enfants d'aujourd'hui» ne sont pas habitués à voir son style de codage et seront plus susceptibles de casser son code à cause de cela.

Parfois, il vous suffira peut-être de lui mettre le nez dans la figure et de forcer le problème. Vous devez choisir ces batailles avec soin. Assurez-vous de commencer par un sujet où vous savez que vous pouvez lui prouver que vous avez une meilleure façon.

Je pense que vous avez la bonne attitude. Assurez-vous simplement de pointer pour dire toutes les bonnes choses que vous avez déjà dites - Excellentes compétences en résolution de problèmes, maîtrise de l'entreprise, etc. et demandez-lui juste un peu de son temps pour lui montrer les normes actuelles du groupe. utiliser et lui donner une chance de poser quelques questions à leur sujet.

Lorsque vous vous réunissez, apportez-lui un café ou quelque chose, et faites-lui savoir que le respect des normes lui sera bénéfique en lui facilitant la prise en charge de votre code existant et en facilitant également la tâche de quelqu'un pour l'aider s'il est couvert par le travail (un gros plus pour quelqu'un qui travaille de façon isolée), etc.

Assurez-vous qu'il est engagé et obtient de bonnes explications sur les raisons pour lesquelles vous faites les choses que vous faites et ne vous concentrez pas sur les raisons pour lesquelles il ne devrait pas faire les choses qu'il faisait, faites venir d'autres personnes si vous le devez et faites-leur vous expliquer. Rendez-vous disponible ensuite s'il a des questions et faites un suivi avec quelques endroits auxquels il peut se référer pour des exemples de vos normes.

S'il n'est pas intéressé après cela, vous pouvez vous référer à la première question que vous avez liée.

C'est vraiment le travail de votre manager de

1. Sachez que l'entreprise doit avoir une norme de codage. Chaque entreprise quelque peu professionnelle a cela, peu importe la taille de l'entreprise.
2. Demandez à tout le monde de s'asseoir ensemble et de commencer à élaborer une norme. De cette façon, tout le monde peut avoir son mot à dire, et il sera alors plus motivé à suivre la norme.

Si votre manager ne s'en rend pas compte par lui-même, il n'est pas qualifié pour son travail. Et si c'est le cas, vous devriez leur donner quelques coups de pouce au-dessus des deux ci-dessus. Les avantages d'avoir une norme de codage sont si nombreux qu'il n'y a vraiment aucun argument contre d'en avoir une. (Si certains programmeurs estiment qu'ils sont des "artistes" et ne devraient pas être limités par les limites du professionnalisme, ils devraient plutôt trouver un emploi dans les beaux-arts.)

La norme de codage en elle-même devrait avant tout se concentrer sur l'interdiction des pratiques dangereuses et des fonctions de bibliothèque dangereuses. Travaillez vers un sous-ensemble plus sûr et plus pur de la langue que vous utilisez. Gardez la norme de codage exempte de "style de codage", car le style de codage est beaucoup plus difficile à convenir et pas aussi important. Il est plutôt classique qu'une entreprise décide de créer une norme de codage, puis se retrouve immédiatement coincée dans une discussion absurde passionnée sur l'emplacement des accolades {}.

Pour référence, vérifiez comment les normes MISRA-C / C ++ et CERT C / C ++ / Java sont écrites.

Tout d'abord, vous devez clarifier POURQUOI vous voulez changer la façon de travailler de cette personne. Si c'est uniquement pour des raisons esthétiques, je pense que vous devriez reconsidérer, car cette personne a démontré que sa façon de travailler fonctionne réellement.

Si, cependant, il y a une raison technique à cela, alors vous devriez envisager d'approcher ladite personne avec quelque chose comme:

J'ai une suggestion sur la façon dont vous pouvez économiser du temps fastidieux pour vous et de l'argent pour l'entreprise. Es tu intéressé?

Sachez que cela devrait être des fruits à faible pendaison car ils nécessiteront très probablement un changement des habitudes existantes qui nécessitent toujours un effort supplémentaire.

Même si vous avez des millions de suggestions, choisissez-en une ou deux et montrez que ce sera un changement pour le mieux.

Soit cela fonctionnera, et il vous sera demandé si vous avez plus de suggestions, ou ce ne sera pas le cas et les dommages sont limités à une ou deux suggestions.

Notez qu'il est très important que cela devienne un succès et qu'il le fasse rapidement.

Vous devez également faire attention. Il peut y avoir de très bonnes raisons de faire les choses comme elles sont faites, mais que vous êtes trop nouveau pour avoir compris pourquoi. Par conséquent, soyez respectueux envers votre aîné et demandez avant de supposer que votre suggestion est meilleure. Vous pourriez apprendre une chose ou deux.

Je voudrais vous décourager sérieusement de vous mettre dans la figure car cela aggraverait la situation très rapidement. Je me rends compte qu'elle a été présentée comme un type de mesure de dernier recours, mais d'après mon expérience, à ce stade, le développeur a cessé de participer.

Forcer le problème pourrait transformer l'individu en ennemi où il se bat avec chacune de vos actions. Cela aurait vraiment un impact négatif sur l'équipe et cela ne prend fin que lorsque quelqu'un quitte ou est renvoyé.

Si cette personne a vraiment des connaissances dans le domaine dont vous avez besoin / voulez, demandez-lui de documenter ces connaissances.

Commençons par lui en parler doucement: je ne sais pas à quel point vous êtes expérimenté et à quel point vous êtes compétent pour donner votre avis. Vous pourriez déjà savoir, employer ou même avoir rejeté les éléments suivants, mais c'est le cas de toute façon. Il y a quelques directives pour donner des commentaires lorsque vous voulez changer le comportement de quelqu'un. La structure de conversation à laquelle j'ai été pensé et que j'essaie toujours d'employer dans des situations où je veux donner un retour (parce qu'elles fonctionnent) est la suivante:

1. Décrivez le comportement que vous voyez. Cela doit être un comportement concret. Exemple: "Je vois que vous utilisez beaucoup de variables statiques dans votre code"
2. Décrivez comment cela a un impact sur vous / votre équipe. Exemple: "Je trouve que ce code est difficile à maintenir"
3. Offrez une solution raisonnable . (les solutions possibles sont mentionnées dans d'autres réponses, et je m'attarderai plus tard sur cette réponse.)
4. Donnez-lui l'opportunité de discuter de la solution. Demandez-lui ce qu'il pense de la solution. Prenez sa réponse à sa valeur nominale. Vous lui avez donné votre avis et il est libre de l'accepter ou non. *

Une ressource rapide sur les commentaires peut par exemple être trouvée sur http://managementhelp.org/communicationsskills/feedback.htm (bien qu'il existe une pléthore de ce genre de choses sur le web)

Maintenant, en ce qui concerne la solution, d'après ce que je lis dans votre réponse, je suppose qu'il est très intelligent et qu'il a la bonne mentalité, mais il est juste en retard dans les bonnes pratiques modernes. Ceux-ci nécessitent du temps et des efforts pour les maîtriser, en dehors de leur apprentissage en premier lieu, vous devrez donc lui donner la possibilité de le faire. Cela signifie probablement rassembler des ressources d'apprentissage (web, magazine, livres, etc.) comme point de départ et lui donner du temps libre pour les étudier. Je pourrais imaginer lui donner chaque vendredi après-midi pour élargir ses horizons sur le style de programmation, où il peut faire tout ce qu'il croit pour atteindre ces objectifs. Les gens veulent intrinsèquement s'améliorer. Fournissez le matériel et le temps, et ils en feront bon usage.

Peut-être plus important encore, ne vous attendez pas à un changement du jour au lendemain. Il a fait les choses à sa façon depuis longtemps, et il est probablement devenu très bon dans ce domaine. Il faudra un certain temps pour devenir aussi bon dans une nouvelle façon de faire les choses, et pendant un certain temps, il ne verra probablement pas beaucoup de valeur dans de nouvelles façons, car au début, il n'y en a pas. Son ancienne méthode sera probablement plus efficace pendant un certain temps.

* Remarque: ce qui est amusant avec les conversations, c'est qu'elles sont très difficiles à modéliser. Ils ont leur propre vie, donc même si ça a l'air bien sur le papier, ça a tendance à devenir un peu boueux.

Expliquez comment vous voulez que les choses soient faites et montrez-lui comment cela fonctionne avec les choix de conception et d'architecture que vous avez faits pour le projet au début du projet sur lequel vous allez le faire travailler. Asseyez-vous un à un (et en privé) et expliquez les problèmes que vous avez vus dans son codage précédent et pourquoi ils sont un problème pour ce projet. Demandez-lui ce dont il a besoin pour aller mieux, mais indiquez clairement que ne pas aller mieux n'est pas une option.

Utilisez ensuite la révision de code comme un outil pour l'amener à ajuster ses méthodes de travail. Prévoyez un bon moment pour le premier et expliquez vraiment pourquoi vous préférez cela à cela et laissez-le expliquer son raisonnement. Assurez-vous de bien l'écouter, les gens sont plus disposés à changer lorsqu'ils sentent que leurs préoccupations ont été traitées. Attendez-vous à ce que vous planifiiez (mais ne lui dites pas cela) d'avoir retravaillé la première tâche et ne l'acceptez pas tant qu'elle ne répond pas aux normes de votre équipe. Une fois qu'il sait ce que vous attendez et que vous ne le laisserez pas glisser dans l'intérêt du temps, il reviendra probablement à votre façon de travailler. Mais vous pouvez utiliser la révision de code comme un outil éducatif pour plusieurs itérations. Vous n'avez pas à être méchant de ne pas accepter le travail jusqu'à ce qu'il réponde à vos normes, mais vous devez être ferme et cohérent. Don'

La question de 64 000 $ est de savoir s'il livre ses projets à temps et répond aux exigences de fonctionnalité. Si oui, il le fait bien. Il n'y a pas de bonne ou de mauvaise voie objective dans le développement de logiciels. En fin de compte, il s'agit de résoudre des problèmes. Et si les problèmes sont résolus à la satisfaction du client / client, alors par définition , le développement logiciel se fait correctement.

Cela devient bien sûr une toute autre question si ses projets ne sont pas terminés. À ce stade, les changements doivent être effectués par vos superviseurs, peut-être avec votre contribution. Mais ce n'est pas parce qu'il viole votre sens personnel de l'esthétique du code ou de la sagesse conventionnelle actuelle que ce qu'il fait est «mauvais». Vous n'êtes pas l'arbitre de la définition de «bon code». Il pourrait, après tout, avoir une mauvaise opinion de votre code.

Donc ... à moins qu'il n'y ait réellement un problème avec son travail (ce que vous n'avez pas indiqué), ne faites rien. Le succès d'un développeur consiste en partie à fusionner votre code avec les styles d'autres développeurs.

Il pourrait, après tout, venir ici et poser une question similaire à propos de traiter avec un développeur moins expérimenté qui est plus soucieux de suivre les modes que de terminer les projets. C'est une question de perspective.

En tant que développeur junior parlant à un développeur senior, il est trop risqué pour vous d'essayer de l'approcher avec de meilleures idées que les siennes.

La meilleure façon de résoudre ce problème est d'essayer de convaincre votre / son patron d'une meilleure pratique et de voir s'il en fera un décret selon lequel tout le code doit suivre des normes spécifiques et être appliqué à ces normes par le biais de revues de code par les pairs.

Une partie importante des gens sont (même à un niveau subconscient) vindicatifs, égoïstes et défensifs, même s'ils ignorent complètement leurs propres motivations subconscientes, ils s'offusqueront si vous essayez de les changer ou impliquez qu'ils ont tort dans en tous cas.

La chaîne de commandement est le moyen le plus sûr d'aller car il DOIT écouter son patron, et il n'a pas à l'aimer. Laissez le patron être le méchant, c'est pour ça qu'il est là.

Si vous ne pouvez pas vendre le patron ou qu'il EST le patron, traitez simplement ses bugs mais montrez l'exemple dans VOTRE code.

Tu ne peux pas.

Vous ne pouvez pas inciter les gens à faire des choses qu'ils ne connaissent pas dans le développement de logiciels. Je parle d'expérience car j'ai essayé de le faire souvent dans ma carrière, et chaque fois que le résultat final est que mon propre statut diminue aux yeux de l'entreprise; J'ai même été licencié ou démissionné de frustration après que rien ne se soit produit, simplement pour avoir essayé d'améliorer la culture de développement qui m'entoure aux pratiques modernes.

Si votre collègue n'était pas ignorant, vous pourriez le lui montrer. Comme ils le sont, cependant, vous ne pouvez rien faire car ils ne sont pas capables ou ne se soucient pas suffisamment du logiciel en tant que savoir-faire pour s'efforcer d'adopter de meilleures pratiques de codage. Il y a de fortes chances que si vous essayez, ils l'ignoreront ou se moqueront sans vraiment comprendre, ce qui, d'après les sons, est ce qu'ils font déjà ("Trial and Error Development", c'est-à-dire simplement pirater le code jusqu'à ce que les erreurs s'arrêtent) .