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


24

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.


9
J'ai été dans cette situation et je n'ai jamais vu ça vraiment résolu avec succès. Beaucoup de gens comme vous avez décrit ont cessé de penser à la programmation il y a des années; à ce stade, ils ne sont intéressés que par des solutions pour leur domaine d'activité. Je ne vais pas rejoindre les fanfares de ce site qui condamnent de telles personnes; en effet, je pense qu'ils sont le sel de la terre. S'ils fonctionnent dans votre code, vous devez au moins pousser à faire respecter vos conventions. Je n'ai pas eu de mal à vendre que les gens devraient suivre les conventions existantes s'ils contribuent à un projet.
Jeremy

1
Qu'a dit votre patron lorsque vous lui avez fait part de cette inquiétude?

2
@Aaronaught, puisque son code fonctionne, ce n'est pas un problème technique mais politique, et probablement un problème qui doit être imposé d'en haut si vous voulez changer quoi que ce soit. En d'autres termes de votre patron. Ayez de bons arguments prêts!

2
@Thor: Vous pensez donc qu'il est absolument impossible que son style soit simplement le produit de faibles attentes, pas d'examen par les pairs et d'une vie bien remplie qui ne se prête pas bien à un apprentissage indépendant pendant son propre temps? Ne pas se soucier n'est pas un trait de personnalité câblé, c'est un produit de son environnement, et il peut être changé. Ne pas savoir est encore plus facile à changer, mais il faut encore l'aborder avec un certain niveau de diplomatie.
Aaronaught

1
@Aaronaught, soit vous avez lamentablement échoué à être une inspiration (qui ne peut être exclue), soit il ne veut pas être inspiré. Envisageriez-vous de coder vos tests unitaires en Lisp ou Haskell si un jeune collègue vous disait que c'est beaucoup plus intelligent que ce que vous faites maintenant?

Réponses:


10

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.


Celles-ci semblent être de bonnes stratégies générales. Je dois être clair que c'est juste VB6, pas COBOL. Peut-être 5-7 ans de retard, pas 20-30 ans. Donc pas un geezer / dinosaure.
Aaronaught

1
Je ne demanderais pas "Pourquoi faites-vous de cette façon?" Cela pourrait avoir un effet négatif - le mettant immédiatement sur la défensive. Il se pourrait que le collègue ne le sache tout simplement pas et que vous ne vouliez pas qu'il se sente ignorant. Demandez plutôt "avez-vous envisagé cette méthode?"
IAbstract

@IAbstract S'il aime enseigner, il ne sera pas sur la défensive, il appréciera l'occasion d'enseigner. Le ton et l'attitude feront une grande différence. S'il semble que vous pourriez facilement ajouter "Idiot" à la fin de la question, alors vous ne le faites pas correctement? :-) D'après mon expérience, la plupart des gens sont prêts à répondre à des questions sincères.
jimreed le

@IAbstract: Je suis à peu près sûr si je demandais quelque chose comme "avez-vous envisagé l'injection de dépendance ici?" la réponse serait "hein?" Bien sûr, il y a une chance que je puisse être agréablement surpris, mais je pense que Jim a raison, c'est un meilleur démarreur de conversation pour demander "qu'est-ce qui vous a décidé d'utiliser un Fooobjet de portée mondiale ici?" Je ne prévois pas que cela soit interprété comme une attaque; c'est moi qui essaie de comprendre le design existant.
Aaronaught

@Aaronaught: assez juste;) Bien que la réaction à DI puisse être "hein?", Cela pourrait déclencher une conversation intéressante comme, "bien, j'en ai entendu parler mais ..." ... ma préoccupation est surtout le ton (comme le souligne jimreed) Certes, comme le dit jimreed, vous devez choisir vos batailles - parfois cela signifie porter un gros bâton, parfois cela signifie jouer dans le bac à sable ensemble.
IAbstract

4

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.


4

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.


Cela fait l'hypothèse (incorrecte) que je travaille pour un éditeur de logiciels avec une structure verticale. Moins de 10% des développeurs travaillent pour des éditeurs de logiciels et il n'est pas nécessairement de la responsabilité d'un cadre ou d'un gestionnaire intermédiaire de microgérer les développeurs.
Aaronaught

2
@Aaronaught Eh bien, c'est la véritable source de votre problème. Si vous n'êtes pas dans une équipe avec une norme de codage et au moins un programmeur chevronné pour diriger et guider les autres, c'est une mauvaise organisation. Tout le monde codera au hasard, pensant être des «artistes», proposant des résultats médiocres, instables et incontrôlables, et n'apprenant pas à s'améliorer.

2

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.


Merci pour la réponse constructive - même si je pense que cela aurait pu se passer du premier paragraphe.
Aaronaught

@aaronaught, désolé, mais c'est en fait assez important.

Non, ce n'est vraiment pas important. Cela répond à une question complètement différente et j'ai déjà fourni plusieurs commentaires et modifications de clarification pour indiquer que ce n'est pas pertinent. L'incapacité des utilisateurs sur ce site (et surtout que ce site) pour séparer la question de la « Devrais - je » de « Comment puis-je » est activement préjudiciable à la qualité et la cohérence du discours ici. Votre mise en garde est valide, mais hors de propos et légèrement offensante. Il y a même une méta-question très votée sur ce sujet précis.
Aaronaught

1
@aaronaught, la seule raison pour laquelle vous déclarez vouloir changer le style de codage de cette personne, c'est parce qu'il est différent du reste de l'équipe, puis vous posez son style en indiquant implicitement que le vôtre est meilleur. D'où mon commentaire. Si vous ne pouvez pas accepter son style de codage actuel dans votre base de code, rendez-vous personnellement avec lui et dites-le, et que vous êtes prêt à faire un gros effort pour l'aider à savoir comment vous avez besoin de son code.

1
@Aaronaught, pour celui qui aurait pu se passer du premier paragraphe, je trouve votre choix de formulation étonnamment choquant. Pensez-vous qu'appeler les autres pathétiques est un exemple à suivre?

1

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.


1
-1 La question indique déjà que le PO n'a pas l'intention d'aborder cette question de manière conflictuelle. Veuillez lire attentivement la question du PO et répondre à cette question spécifique , plutôt que de discuter du sujet en général.
HedgeMage

1

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.


0

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'


-1

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.


2
C'est pour cette raison que j'ai souligné qu'il venait d'un autre secteur de l'entreprise. Il n'a eu aucun problème à répondre à leurs exigences, mais leurs exigences ne sont pas les nôtres . Plus précisément, leurs exigences n'étaient pas beaucoup plus avancées que CRUD. Et oui, il y a un problème avec le code; il peut fonctionner correctement isolément, mais ne réussira pas les tests d'intégration, de performances ou de fiabilité. Je ne crois pas aux méthodologies strictes comme XP ou TDD ou quoi que ce soit, mais ce n'est pas une question d'esthétique ou de sagesse conventionnelle, c'est une question de maintenance.
Aaronaught

3
Je ne vote pas non plus pour les raisons ci-dessus, mais parce que vous faites plusieurs hypothèses injustifiées. (a) je ne suis pas moins expérimenté, (b) aucune des choses dont je parle ne sont à juste titre appelées "manies", et (c) celle-ci est l'hypothèse la plus ridiculement flagrante - il n'est pas le développeur le plus productif sur l'équipe et n'est certainement pas plus productif que moi.
Aaronaught

S'il y a réellement un problème avec ce qu'il produit, alors comme je l'ai dit , c'est un problème pour votre superviseur, ou qui que ce soit votre superviseur mutuel. Mais vous n'avez pas montré qu'il y a un problème avec ce qu'il livre au client / client, juste que vous n'aimez pas ce qu'il vous livre. C'est mon point, il n'écrit pas de logiciel pour vous. Donc, avant de faire du bruit, je ferais en sorte qu'il ne soit pas moins dispensable que vous.
GrandmasterB

En ce qui concerne les modes, traînez dans l'industrie pendant un certain temps et vous vous rendrez compte que oui, les meilleures pratiques d'aujourd'hui sont les mauvaises pratiques de demain de style VB6. En ce qui concerne le vote négatif, bien sûr, n'hésitez pas. Je réponds simplement à la question telle que publiée. Je ne peux pas répondre aux détails que vous n'avez pas fournis.
GrandmasterB

1
Je ne connais pas votre CV et je ne connais pas non plus vos collègues. Je sais seulement ce que vous avez mis dans la question. S'il s'agissait d'informations importantes, vous auriez dû les inclure. Et sur la base de vos réponses à d'autres réponses, vous pourriez considérer que vous avez laissé un peu de côté, nécessitant ainsi beaucoup d'hypothèses de la part des répondeurs. Mais si vous voulez une réponse, en supposant que vous n'ayez pas son superviseur, c'est le problème de votre superviseur ou de votre superviseur mutuel de vous soucier de ne pas faire de bruit. Rejetez simplement le code qui cause un problème lors des tests et signalez le problème à votre collègue.
GrandmasterB

-1

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.


1
Cela répond à une question complètement différente de celle que j'ai posée. (a) Je ne suis pas un développeur junior, (b) mon patron me délègue déjà la plupart des décisions importantes de conception et de code, (c) son code n'est pas connu pour être bogué, mais pas bien structuré pour la POO de C # / paradigme mixte fonctionnel, et (d) l'essence de ma question était de savoir comment aborder le sujet de manière à ne pas s'en offusquer.
Aaronaught

1
@Aaronaught, a) "Ce programmeur est un peu plus âgé que moi", je suppose à partir de cette déclaration que vous êtes son "junior". b) On dirait que vous êtes le responsable technique alors, vous auriez dû mettre cette information dans votre question, cela change considérablement les choses. c) S'il ne suit pas les meilleures pratiques et que son code n'est pas bogué, alors quel est le problème? Pourquoi l'approcher de quoi que ce soit? Ne réparez pas ce qui n'est pas cassé. d) Encore une fois, ne vous approchez pas de lui s'il ne cause pas de bogues avec un code de mauvaise qualité. Le vrai problème est que vous n'avez pas de normes de codage et de développement que tout le monde doit respecter.
maple_shaft

Je pensais que c'était assez clairement sous-entendu par ma référence à (ne pas) "entrer avec des armes à feu flamboyantes et instituer des revues de code rip-it-to-shreds et des politiques strictement appliquées" - pourquoi devrais-je même mentionner que si j'étais un junior ? Et qui a dit que nous n'avions pas de normes? Il n'a jamais travaillé avec notre équipe auparavant et j'essaie d'introduire les normes sans en être un con .
Aaronaught

-1 N'a pas répondu à la question posée.
HedgeMage

-1

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) .


4
J'apprécie la réponse, cependant, je trouve cela difficile à croire, principalement parce que j'étais exactement ce type de programmeur "il suffit de le faire" il y a plusieurs années. Personne ne m'a montré - j'ai dû tout découvrir moi-même - mais je suis sûr qu'un leader suffisamment persuasif (s'il en avait existé) aurait pu opérer le même changement. Le fait que certaines personnes apprennent tout cela indépendamment ne signifie pas nécessairement que tout le monde est une cause perdue.
Aaronaught

2
C'est vrai, mais d'après mon expérience, si les gens veulent s'améliorer, ils ont besoin de peu de motivation pour être inspirés parce que le désir est déjà là - ils pourraient avoir besoin d'un coup de pouce ou de conseils, mais ils comprennent et veulent s'améliorer, ils ont juste besoin de conseils. J'étais de la même manière; J'ai appris de mauvaises façons de faire et j'ai pensé "Il doit y avoir une meilleure façon" et j'ai commencé des recherches. Ce que j'ai vu cependant, c'est que les personnes qui ne s'améliorent pas ou qui ne souhaitent pas s'améliorer sont des causes perdues parce qu'elles ne veulent pas s'améliorer. Cela dit, bonne chance pour me prouver le contraire :)
Wayne Molina

1
Je pense que c'est le genre de déclarations qui doivent être étayées. Je serais certainement intéressé à entendre (et plus disposé à voter) des expériences du monde réel, en ce qui concerne ce que vous avez essayé sans succès (et pourquoi il a échoué).
Aaronaught

1
Cela est parfois vrai, par exemple " vieux chien, nouveaux trucs " - essayez d'expliquer à quelqu'un comment les techniques ont augmenté l'efficacité de récupération des données de 800% et le collègue haussa simplement les épaules.
IAbstract

2
Le fait est que vous pouvez le faire et que les gens vous suivront, mais vous devrez vous classer plus haut dans la hiérarchie. Vous ne pouvez pas le faire en tant que simple développeur dans la plupart des équipes. De nombreux collègues ne peuvent que demander conseil à quelqu'un de plus haut placé dans la hiérarchie. Si vous êtes au même niveau, ils se sentiront blessés et attaqués. N'oubliez pas que le respect est gagné. Si vous les traitez bien et le communiquez gentiment et agréablement, cela peut fonctionner, si vous êtes au même niveau aussi.
Falcon
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.