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.