Comment savoir si les conseils d'un développeur senior sont mauvais?
Récemment, j'ai commencé mon premier emploi en tant que développeur junior et j'ai un développeur plus senior en charge de me conseiller dans cette petite entreprise. Cependant, il y a plusieurs fois où il me donnait des conseils sur des choses avec lesquelles je ne pouvais tout simplement pas être d'accord (cela va à l'encontre de ce que j'ai appris dans plusieurs bons livres sur le sujet écrits par les experts, les questions que j'ai posées sur certains sites de questions et réponses sont également d'accord avec moi) et compte tenu de notre emploi du temps chargé, nous n'avons probablement pas le temps de longs débats.
Jusqu'à présent, j'ai essayé d'éviter le problème en l'écoutant, en soulevant un contrepoint basé sur ce que j'ai appris en tant que bonnes pratiques actuelles. Il soulève à nouveau son point d'origine (la plupart du temps, il dira les meilleures pratiques, plus maintenable mais ne va pas plus loin), je prends une note (puisqu'il n'a pas soulevé de nouveau point pour contrer mon contrepoint), pensez à et la recherche à la maison, mais ne faites aucun changement (je ne suis toujours pas convaincu). Mais récemment, il m'a de nouveau approché, a vu mon code et m'a demandé pourquoi je ne l'avais pas changé en sa suggestion. C'est la 3e fois en 2 à 3 semaines.
En tant que développeur junior, je sais que je dois le respecter, mais en même temps, je ne suis tout simplement pas d'accord avec certains de ses conseils. Pourtant, je subis des pressions pour apporter des changements qui, je pense, aggraveront le projet. Bien sûr, en tant que développeur inexpérimenté, je peux me tromper et sa façon de faire pourrait être meilleure, il peut s'agir de l'un de ces cas d'exception.
Ma question est: que puis-je faire pour mieux juger si les conseils d'un développeur principal sont bons, mauvais ou peut-être bons, mais dépassés dans le contexte actuel? Et s'il est mauvais/dépassé, quelle tactique puis-je utiliser pour ne pas le mettre en œuvre à sa manière malgré ses "pressions" tout en conservant le fait que je le respecte en tant que senior?
Tout d'abord, en tant que développeur senior, je m'attends à ce que les juniors que je dirige sur des projets me fassent part de leurs préoccupations de manière directe et directe. S'ils ne sont pas d'accord, cela me convient parfaitement. Dans certains cas, je répondrai à leurs préoccupations. Dans la plupart des cas, leurs préoccupations sont jeté de côté mis de côté avec une courte explication du raisonnement, pas par manque de respect pour le développeur lui-même mais pour une autre raison telle que:
- Le junior n'a pas toutes les informations en main pour comprendre la décision telle qu'elle a été prise. Dans certains cas, une petite explication peut aider le développeur à dépasser le problème et à faire face à une situation unidéal.
- Le junior a de mauvaises informations. N'oubliez pas que vous êtes, en fait, un junior. C'est l'équivalent d'être un adolescent en termes de logiciels. Je suis sûr que vous avez beaucoup de bonnes idées, mais il est possible que vous ne sachiez pas tout. Je trouve que les développeurs juniors les plus résistants sont ceux qui croient fermement qu'ils savent ce qui est le mieux pour le code, l'entreprise, le monde. Ces développeurs sont mieux servis en acquérant l'humilité.
- La décision de faire quelque chose d'une manière particulière a été prise au-dessus de la tête de l'aîné. L'aîné travaille toujours pour quelqu'un d'autre à la fin. Il peut en fait y avoir une meilleure façon de faire quelque chose, une manière plus efficace d'écrire quelque chose, ou de meilleurs logiciels/matériels pour aider à faire le travail. L'entreprise continue cependant de prendre les décisions. Les chefs d'entreprise, directeurs, VP, etc. prennent souvent des décisions qui ont un impact sur le processus de développement. Tout cela échappe au contrôle du senior, et lorsque les juniors s'en plaignent, ils ne font qu'ajouter au stress du senior.
- L'aîné qui vient de se mettre à plat n'a pas le temps d'en tenir compte. Il y a des délais, et parfois changer les modèles, les pratiques et les comportements en cours de route est coûteux pour ce délai. Puisque c'est son cou sur le bloc de coupe, il est souvent plus important de sortir le produit fonctionnel et à temps que "parfaitement écrit".
Ce ne sont que des choses auxquelles je peux penser du haut de ma tête. Il y a une tonne de raisons pour lesquelles une idée, une pratique, un concept peut être rejeté ou rejeté par quelqu'un de plus haut que vous. Beaucoup d'entre eux sont désagréables, mais ils se résument tous au fait que nous sommes tous humains et que nous avons tous des opinions. Son opinion se trouve juste être numériquement supérieure à la vôtre en ce moment.
Gardant ces concepts à l'esprit, vous devez continuer à faire part de vos préoccupations au développeur principal. Trouvez un autre développeur senior qui pourra peut-être remplir les blancs. De nombreux développeurs seniors sont là où ils en sont parce qu'ils sont meilleurs avec les logiciels qu'avec les gens. Certains sont là où ils en sont parce qu'ils savaient à qui les fesses d'embrasser lorsqu'ils étaient stagiaires. Trouvez-en un qui comprend réellement ce que signifie encadrer quelqu'un et obtenir son opinion honnête. Ils peuvent être en désaccord avec vous et remplir les blancs que vous n'avez pas. Ils peuvent être d'accord avec vous et aider à rallier votre cause ou à améliorer votre situation.
Vous ne devez à aucun moment monter une quelconque insurrection. Même si vous croyez dans votre cœur que votre voie est la bonne, vous avez reçu une instruction à suivre et vous devez la suivre (à moins que ce ne soit évidemment illégal). Si vous avez du mal à suivre ces instructions, vous voudrez peut-être essayer de comprendre pourquoi, car vous allez découvrir que ce modèle de comportement est très répandu dans de nombreuses entreprises qui produisent tout type de logiciel.
Votre meilleure option est de continuer à faire votre travail de manière éthique et professionnelle. Obtenez le logiciel qu'on vous demande de réaliser de manière exemplaire et échappez à la situation en en faisant la promotion. Si les promotions ne viennent pas, vous aurez beaucoup de références et d'expérience pour saisir des opportunités dans d'autres départements ou entreprises.
Respectez le développeur senior. Il est plus en jeu que vous pour la réussite du projet. Puisqu'il a la responsabilité, il obtient également l'autorité. S'il dit changer quelque chose, faites-le.
Cela dit, n'hésitez pas à présenter vos préoccupations, lorsque vous rencontrez un problème comme vous l'avez déjà.
Enfin, asseyez-vous avec lui et expliquez-lui la même question que vous avez posée ici. Peut-être que vous manquez quelque chose de grand, peut-être qu'il s'ouvrira davantage à vos suggestions, de toute façon, ne le gardez pas dans le noir si vous pensez que ses conseils sont mauvais.
Lorsque cela se produit, ce que vous devez faire est avoir une conversation avec le développeur senior. Peut-être qu'il sait quelque chose que vous ignorez sur le code ou les exigences techniques/commerciales. Si oui, vous devriez l'apprendre.
Faites-le en privé. Cela peut être perçu comme un défi à l'autorité, et de telles choses sont mieux faites individuellement. Montrez une volonté de faire des compromis et de collaborer en reconnaissant et en respectant son ancienneté, mais soyez persévérant pour obtenir des réponses à vos questions. Abordez la situation à partir d'un cadre collaboratif et non combatif. Vous pourriez envisager de lui demander de vous encadrer.
À la fin de la journée, vous devez équilibrer vos propres idées (qui, pour être honnêtes, sont relativement nouvelles et non testées) avec les siennes. Vous avez peut-être bien raison, mais vous devriez faire de votre mieux pour apprendre de personnes plus expérimentées afin de pouvoir prendre une décision plus éclairée. Un bon développeur senior se réjouit de l'opportunité de collaborer, d'encadrer et d'apprendre, même avec des développeurs juniors, et se félicite que leurs idées soient contestées de manière constructive, car eux aussi savent qu'ils ont parfois tort.
La façon dont vous le dites souvent passe par une approche de bon sens. Gardez à l'esprit que le développeur senior peut en savoir plus sur le projet, mais peut ne pas en savoir plus sur la bonne façon de faire les choses. Vous devez évaluer ce qu'il vous dit de faire - il vous donne de mauvais conseils si ce qu'il dit va à l'encontre de ce que ses parieurs prétendent (c'est-à-dire des personnes plus âgées que lui; pas nécessairement dans votre entreprise). .. Je parle de développeurs "célèbres" bien connus qui publient ou écrivent souvent des livres sur la bonne façon de faire du développement logiciel, ou à tout le moins sur les meilleures pratiques acceptées par l'industrie).
Voici un exemple de "mauvais conseil" d'un développeur senior (ou de tout développeur): s'il ignore totalement ce qu'est un couplage lâche et pourquoi c'est une bonne chose, et qu'on vous dit d'écrire tout le code, disons, le code - derrière un fichier ASPX, il est évident que le développeur senior n'a aucune idée et ses conseils ne doivent pas être écoutés.
Si, d'autre part, il vous dit comment fonctionne un module spécifique du système, il est souvent préférable d'écouter aussi longtemps, ce qu'il vous dit ne crache pas face aux principes de développement appropriés.
Voici ma règle d'or: un développeur senior dans une entreprise pourrait simplement être le développeur avec le plus long mandat; il pourrait ne pas avoir de véritable compétence. Est-ce qu'il dit des choses qui vont à l'encontre de ce que disent certains des développeurs les plus respectés de votre domaine (des gens avec beaucoup plus d'expérience que lui, et qui sont beaucoup plus compétents et respectés)? S'il l'est, il est probable que ses conseils soient mauvais, sauf en cas de circonstances très extrêmes.
Attendre pleinement les downvotes/désaccords pour un point de vue extrêmement biaisé.
Si la personne âgée ne peut pas vous donner de bonnes raisons pour lesquelles elle ignore les meilleures pratiques de l'industrie, ne perdez pas votre temps là-bas. Vous ne progresserez jamais parce que vous êtes trop menaçant, et de toute façon, voulez-vous passer du temps à maintenir une pile de mauvais code?
La plupart des développeurs arrêtent de lire lorsqu'ils quittent l'université. Vous ne l'avez pas fait, vous êtes donc déjà dans le top 10%. Il y a beaucoup d'opportunités de nos jours. S'il n'y a pas de marché du travail dans votre ville, alors cherchez une meilleure ville.
Wow, c'est une merveilleuse occasion pour vous de briller et de montrer vos compétences. Au début de ma carrière, j'avais quelqu'un qui était mon superviseur qui n'était pas en mesure de prendre une décision, aucune décision, alors j'ai profité de cette occasion pour apprendre à faire le travail du niveau supérieur suivant. Cela m'a fait promouvoir. Tu devrais faire pareil.
Il peut être difficile de comprendre le point de vue du développeur principal, et oui, il peut conduire les choses dans le mauvais sens, mais lorsqu'il s'agit de grands projets, la cohérence est plus importante.
Avoir 50 développeurs qui suivent tous leurs propres styles de codage, normes, méthodologies et modèles de conception serait un chaos total. Si les choses sont mal faites, il est toujours préférable d'avoir toujours tort que de nombreux types de mal et certaines choses qui ont été bien faites.
Quand vient le temps d'effectuer la maintenance, d'ajouter des fonctionnalités ou de corriger ce qui est "incorrect", il est beaucoup plus facile si les problèmes avec la conception existante sont connus dès le départ.
Il est bon d'être en désaccord avec respect, mais au final, il vaut mieux se mettre en ligne. N'importe qui dans une équipe qui fait un voyou n'est pas considéré comme un joueur d'équipe.
En tant que développeur senior, ce type de cueillette passive agressive de nit me rendrait fou et après la confrontation, je me conduisais à vous donner une mauvaise critique. La solution parfaite est celle avec laquelle l'équipe peut vivre ensemble.
Quant au style, il doit être dicté par votre guide de style et les meilleures pratiques déterminées par votre origine. Si vous êtes passionné, défendez-le, mais une fois qu'une décision est prise, vivez avec et travaillez avec les limites de l'équipe avec laquelle vous êtes.
Vous êtes dans une situation pas si bonne, mais, comme l'a souligné HLGEM, vous pouvez transformer ces positions en bénédictions déguisées. Votre question a plusieurs facettes, je vais donc l'aborder en plusieurs parties.
Je soupçonne, il ne sait pas. En même temps, il essaie de me montrer l'arrogance peut-être pour que je ne me tourne pas beaucoup vers lui pour des questions.
Cela pourrait très bien être vrai. Il y a une vague de développeurs qui sont dans l'industrie depuis décennies et qui ne sont pas des leaders logiciels capables - issus d'un développement ou un point de vue de mentorat (il y a une différence). L'expérience vient de relever de nouveaux défis et d'essayer de nouvelles idées et d'apprendre de nouvelles compétences, mais la majorité des programmeurs passent leur vie dans une aile du siège social, travaillant sur l'application de paie avec leur fidèle Visual Basic et = Java outils, ne voyant jamais le monde courir par leur bureau froid et gris.
Il y a rien de mal à cela. Pour de nombreux développeurs, c'est tout ce qu'ils ont toujours voulu et sont parfaitement satisfaits de la situation - ce n'est cependant pas une situation idéale pour favoriser une future génération de programmeurs, et encore moins des développeurs principaux.
La bravade et l'arrogance peuvent être un mécanisme de défense, essayant de couvrir les insuffisances. Comment gérez-vous cela? Ne pas affrontez-le de front - si votre lead est incompétent et que le patron ne veut pas rectifier la situation alors vous devrez vivre avec. Cela ne veut pas dire rouler et mourir, mais vous ne pouvez pas forcer quelqu'un à être un bon leader.
Cependant, il ne fait que réviser mon code, et la plupart de ses commentaires sont liés aux directives de codage
C'est ce qui me fait penser que vous avez raison, car il n'est peut-être pas un bon programmeur. Cela ne veut pas dire qu'il n'est pas un meilleur programmeur que vous en ce moment (à tout le moins, il aura plus d'expérience et d'exposition depuis si longtemps dans l'industrie) mais encore une fois, cela ne se traduit pas par être un plomb efficace. Les lignes directrices sont toutes bonnes et bonnes, mais elles sont en second lieu à la fonction, l'efficacité et l'efficience du code.
Que dois-je faire dans une telle situation?
J'ai informé mon manager de cette situation, et je lui ai demandé de changer mon lead, bien qu'il dise "oui" à chaque fois, mais il ne prend aucune mesure sérieuse.
Avez-vous énuméré tous ces points spécifiques au gestionnaire et avec des exemples spécifiques pour les sauvegarder? Si vous vous êtes simplement adressé à lui et lui avez dit: "J'ai besoin d'une nouvelle piste", il ne vous prendra pas au sérieux et ne la percevra pas comme un "problème interpersonnel" plutôt que comme un problème technique. La réaction de beaucoup de patrons dans cette situation est de l'ignorer dans l'espoir qu'elle "se résoudra".
Voici quelques suggestions.
- Ne vous frottez pas à votre situation - l'épreuve du feu, bien que ce ne soit pas amusant, vous apprend des compétences de recherche essentielles pour plus tard dans votre carrière.
- Commencez à pousser votre avance pour être plus impliqué. Faites cela avec soin et respect. Continuez à pousser et à être persistant jusqu'à ce qu'il cède (cela fonctionne en fait pour beaucoup de situations dans la vie).
- Si votre responsable ne veut pas s'impliquer, voyez s'il y en a d'autres qui pourraient vous aider. À moins que vous ne travailliez dans un atelier sueur qui ne s'occupe que des heures de traite, votre entreprise ne se souciera pas d'un autre développeur avec plus d'expérience vous montrant des cordes et révisant votre code.
- Gardez un œil sur un nouvel emploi. Je ne dirais pas que vous êtes dans une situation de "départ obligatoire", mais cela ne nuirait pas à votre carrière d'être dans un endroit qui prend votre développement en tant que programmeur plus au sérieux.
Si vous avez une meilleure façon de résoudre un problème particulier, il suffit de DO IT.
Laissez votre code/solution être votre meilleur argument. Sinon, restez fidèle à ce qu'on vous a dit.
cas d'espèce
quand j'étais junior, j'ai eu une situation où une section particulière de code n'était pas la meilleure possible. Plutôt que d'en débattre, je l'ai simplement amélioré PUIS a montré les résultats à mon aîné. Il l'a accepté, car le code est toujours roi.
Bien sûr, en tant que développeur inexpérimenté, je peux me tromper et sa voie peut être meilleure, alors ma question est de savoir comment puis-je faire pour mieux juger si un conseil de développeur senior est bon ou mauvais/obsolète.
Vous pouvez devenir un développeur expérimenté. Jusqu'à ce que vous fassiez cela, vous serez mal équipé pour juger si votre intuition en tant que junior avait raison ou non, et d'ici là, cela n'aura plus d'importance.
En attendant, lisez la réponse de Joel Etherton.
Je suggérerais fortement de ne pas essayer de "ne pas l'implémenter à sa façon".
Jusqu'à présent, il semble que vous ayez fait la bonne chose. Vous avez été humble et avez soulevé un contrepoint. Je ne pouvais pas dire à partir de votre question si vous étiez simplement en désaccord avec sa méthode, ou si vous étiez en désaccord et avez présenté une alternative. En fin de compte, toujours offrir une alternative claire et réfléchie lorsque vous essayez d'abattre l'approche de quelqu'un d'autre. Comme il pourrait le voir, vous avez une bonne idée qui pourrait fonctionner, et il a une idée qui fonctionne.
Dans n'importe quelle position, nous sommes obligés de faire des choses sous-optimales tout le temps. Si vous ne l'aimez vraiment pas, vous pouvez faire ce que vous avez fait et en parler. Après cela, c'est le chemin du patron ou l'autoroute. Du côté plus brillant, vous êtes isolé d'une grande partie du risque de mauvaises décisions en tant que junior.
Choisissez vos batailles. Si vous parlez d'une heure de travail, vous devrez parfois changer votre code jusqu'à ce que vous montiez. La prochaine fois que vous obtenez un grand projet, demandez à l'avance une chance de présenter vos idées avant de commencer. Consacrez du temps supplémentaire et créez une démonstration ou un prototype incroyable.
Chose choquante, ce que j'ai fait, c'est de cesser de demander. Lorsqu'on me donne une autre option, je m'éloigne du sujet et le fais à sa façon, mais j'y ajoute mon propre style. Utilisez-le comme une expérience d'apprentissage pour développer vos capacités tout en apaisant son besoin de le garder à l'ancienne.
En fin de compte, tous les développeurs seniors ne prêtent pas attention à de nouvelles façons de faire. Ils ont parfois des méthodes à l'ancienne qui étaient excellentes pour la langue qu'ils ont commencée il y a 20 ans, mais sont considérés comme hacky, ou "ont une mauvaise odeur" dans le monde d'aujourd'hui.
Cela peut sembler une façon horrible de continuer, et c'est le cas. Mais j'ai aussi beaucoup appris de ma façon de faire avec les aînés. Mais ce n'est vraiment que mon avis. En fin de compte, vous devez être heureux dans votre travail et garder les distractions et les tensions à un niveau bas. Et en ne vous opposant pas aux choses, vous verrez le stress diminuer.
Ne faites pas confiance aux personnes âgées en raison de leur ancienneté. Défiez l'autorité aussi souvent que possible. Une autorité compétente devrait être en mesure de répondre de manière convaincante à toute question. C'est ce qui fait de lui une autorité en premier lieu, n'est-ce pas?
Parce que quelqu'un a des croyances superstitieuses pour toute sa vie ne signifie pas qu'il a raison. Rappelez-vous qu'au Moyen Âge, les gens croyaient que la terre était plate et certains de ces ânes pharisaïques se sentaient même justifiés de tuer les sceptiques. Il s'est avéré que les sceptiques avaient raison. Voilà pour les mauvaises critiques.
Ne craignez jamais une mauvaise critique. Feriez-vous confiance à un aveugle qui juge la couleur?
les bonnes réponses ci-dessus, ajouteraient qu'une réponse comme "meilleures pratiques" ou "plus maintenable" est l'occasion de apprendre quelque chose. Vous dites: "Pouvez-vous me donner un exemple des raisons pour lesquelles cette méthode est la meilleure pour que je puisse comprendre la différence?" "ou" Dans quelles situations cette façon de faire serait-elle plus maintenable que d'une autre manière, afin que je puisse apprendre à planifier comme ça? "
Si l'aîné a raison, vous donner un exemple sera facile. S'il est un perroquet ... donnez-lui un cracker pour arrêter le squawkin ', et faites ce que vous pensez être le mieux. Jusqu'à ordre contraire.
Si le rôle de la personne âgée est de mentor, il expliquera pourquoi une fois demandé.
Comme HLGEM et Jarrod l'ont dit auparavant, c'est vraiment une bénédiction déguisée. Leurs deux réponses sont excellentes et je veux ajouter quelques points.
Comme votre prospect ne fait pas partie de votre domaine, vous pouvez prendre certaines des décisions importantes pour votre partie de l'application, car votre responsable ne connaît pas grand-chose au middleware. Vous avez également des discussions avec votre responsable sur la façon dont l'application doit se dérouler, sur ce que les utilisateurs de produits souhaitent et sur la manière dont votre responsable souhaite gérer une situation qui lui est présentée par l'équipe produit. Dites-moi combien de personnes obtiendront ce genre de connaissances sur une application.
Lorsque vous êtes dans une grande équipe, vous aurez certainement l'aide de vos coéquipiers et/ou de votre responsable, mais vous n'aurez pas la connaissance de la façon dont votre manager pense ou de l'équipe produit, car ce genre de chose passe généralement par votre responsable et peut être quelques développeurs seniors dans une équipe. Je suis d'accord pour dire que les projets d'une personne sont un peu difficiles à réaliser, mais si l'autre côté de la médaille est si génial, pourquoi manquer une chance. Apprenez ce que vous pouvez apprendre, profitez pendant que vous le pouvez et si cela devient trop difficile, convaincez votre manager comme l'a dit Jarrod ou trouvez un nouvel emploi/projet en fonction de la situation.
Si vous pensez une seconde que la direction ne comprend pas à quel point vous êtes VRAIMENT capable de faire le travail, vous vous trompez probablement. La direction comprend probablement aussi que votre rôle en ce moment serait complètement inutile s'il vous remplaçait et reprenait votre travail.
Les VRAIES raisons pour lesquelles ils ne vous ont pas déménagé sont parce que malgré tous vos défis que vous leur présentez, vous êtes toujours la meilleure personne pour le travail. Ils apprécient évidemment trop votre travail pour risquer de le confier à quelqu'un d'autre.
Ne sous-estimez pas l'intelligence de la direction ...
Ils sont beaucoup plus intelligents que ce que la plupart des développeurs leur attribuent. Je n'ai pas compris cela jusqu'à ce que je commence à gérer. Ils sont probablement aussi conscients de l'inutilité réelle de votre piste mais ils sont probablement impuissants à résoudre ce problème.
Permettez-moi de vous brosser un tableau, le chef A avec 5 ans d'expérience dans l'entreprise est incompétent. Le manager le sait, recommande à son supérieur hiérarchique de licencier le responsable A. Le supérieur hiérarchique demande pourquoi il n'a pas été traité il y a des années s'il est si incompétent. Le gestionnaire a l'air mauvais maintenant, d'autant plus que le plomb A a un salaire gonflé qui était payé sans aucun avantage ...
Voici un autre scénario potentiel, Lead A est un ami proche avec quelqu'un d'important. Il est trop chaud politiquement pour prendre,
Quoi qu'il en soit, avec une erreur de longue durée comme celle-ci, il est plus facile pour les grandes organisations de balayer des personnes incompétentes sous le tapis, de leur donner un travail occupé et un faux pouvoir approprié à leurs années d '"expérience" où elles ne peuvent pas faire TROP BEAUCOUP de dégâts . Malheureusement, de nombreuses organisations préfèrent le faire alors en fait, elles s'occupent des problèmes.
Bien sûr, la raison en est que le gestionnaire dans ce type d'organisation est toujours mieux à court terme pour faire face aux mauvais talents de cette façon que pour résoudre les problèmes à long terme que ce type de personnes peut apporter à l'organisation.
Donc, bien qu'il soit à courte vue et potentiellement contraire à l'éthique, vous devez admettre qu'il est un peu plus intelligent que de nombreux développeurs ne le reconnaissent réellement.
Il y a un courant sous-jacent à tous ceux qui, je pense, devrait être mis en évidence: ne soyez pas combatif. Préservez votre relation avec lui. C'est génial de suivre son conseil avec un grain de sel et de le valider dans des livres et sur des sites comme ceux-ci, mais ne l'attaquez pas. S'il est développeur senior et a mené de nombreux projets, ce n'est pas un idiot et il y a beaucoup à apprendre de lui. Comme il semble que vous l'ayez déjà fait, exprimez votre désir de comprendre son point de vue. Même si vous êtes sûr qu'il a tort et que vous avez raison, acceptez la possibilité du contraire (il semble que vous compreniez déjà cela). Essayez de montrer clairement que vous vous disputez parce que vous voulez mieux comprendre son point de vue, pas parce que vous essayez de lui prouver le contraire.
S'il ne vous répond pas tout de suite lorsque vous lui posez une question, ou si sa réponse est vague et/ou inutile, ne présumez pas qu'il vous épate. Comme cela a déjà été mentionné ici, il pourrait bien être occupé et/ou stressé.
C'est aussi super d'être patient. Gardez dans votre tête une liste de choses qui, selon vous, devraient être faites différemment et présentez-les au bon moment. Assurez-vous d'avoir une justification de la suggestion en plus de "c'est la meilleure pratique". Et faites attention à bien faire les choses et à ne pas faire d'erreurs, afin d'avoir de la crédibilité lorsque vous ferez vos arguments plus tard.
Jusqu'à présent, j'ai essayé d'éviter le problème en l'écoutant, en soulevant un contre-point, il soulève à nouveau son point d'origine (la plupart du temps, il dira les meilleures pratiques, plus maintenable mais n'est pas allé plus loin), I. .. pensez-y à la maison, mais ... je ne suis toujours pas convaincu. Mais récemment, il ... a vu mon code et m'a demandé pourquoi je ne l'avais pas changé à sa suggestion. C'est la 3e fois en 2 à 3 semaines.
(Légèrement modifié pour les actions.)
Cette partie me concerne. Une façon de voir si vous avez raison ou non est de comprendre ce qu'il dit. Ce que j'ai lu (avec ma propre histoire, d'autres peuvent être différents) est un développeur junior ne comprenant pas ce que dit le mentor et ne demandant pas de clarification. Une façon de le comprendre est de lui demander de clarifier: en quoi est-ce une meilleure pratique que cela? Ou pourquoi est-ce plus maintenable que celui de notre code? Si vous ne connaissez pas ses réponses à cela, vous ne savez vraiment pas s'il donne de bons conseils ou non.
La partie qui m'inquiète vraiment, c'est qu'il vous a demandé de le changer plusieurs fois, et vous ne l'avez pas fait. Voici une façon de voir les choses de son côté: il vous demande de faire le changement, vous demandez pourquoi, il vous donne une raison (valable, selon lui), et vous refusez de faire le changement. Vous ne demandez pas d'éclaircissements, il suppose donc que vous comprenez la raison et que vous êtes trop paresseux ou trop têtu pour le changer - ni l'un ni l'autre n'est une bonne chose pour un développeur senior de penser à vous. Croyez-moi, il vaut mieux poser des questions que d'avoir une réputation de cette façon.
Quelques réflexions:
1/Ça marche? Est-ce que sa façon fonctionne ou non? Est-ce une raison objective pour laquelle sa voie serait inférieure?
Par raison objective, je veux dire quelque chose qui peut être mesuré sans ambiguïté (performances, bugs, longueur de code ...) Si ses solutions fonctionnent et qu'il n'y a pas de métrique objective qui indique que c'est une mauvaise solution, faites-le à sa façon. Sa façon de faire est meilleure ... car elle est probablement plus cohérente avec le reste de la base de code et parce qu'il lui sera plus facile d'utiliser/réutiliser votre travail. Vous ne l'aimerez peut-être pas, mais ce n'est pas de cela qu'il s'agit, n'est-ce pas?
Si cela ne fonctionne pas ou ne donne pas de bons résultats sur des métriques importantes, implémentez-la, comparez sa solution avec la vôtre, puis dites-lui que vous avez fait son chemin, mais vous ne pouvez pas l'amener à bien fonctionner (donnez les métriques) et demandez-lui si vous avez fait une erreur dans votre mise en œuvre ou s'il existe une exigence dont vous n'étiez pas au courant
2/Les programmeurs étoiles disent ... Pourquoi s'en foutre? Vous trouverez des programmeurs célèbres profondément en désaccord les uns avec les autres sur de nombreux sujets fondamentaux tels que la planification, la conception, OOP vs procédural, les tests unitaires, la gestion des exceptions, le contrôle des sources, et ainsi de suite.
Si la seule différence de maniabilité entre 2 solutions est de savoir qui la préfère, sautez-la. Vous pourriez bénéficier de l'entraînement mental requis en travaillant dans un paradigme que vous n'aimez pas
Sur la base de l'idée que vous ne devriez prendre conseil que des personnes que vous voulez devenir, la réponse est que les conseils supérieurs sont bons si vous voulez devenir comme lui.
Vous allez avoir affaire à des gens comme ça toute votre carrière. Et il y en aura beaucoup avec qui vous ne serez pas d'accord sur la meilleure approche pour tout problème de codage. La meilleure chose que je pense qui a fonctionné pour moi au fil des ans est que s'ils continuent à insister sur un problème, soyez franc avec eux et dites-leur que vous avez considéré leur solution parmi les différentes solutions possibles et que vous pensiez que la solution que vous sur lequel vous vous êtes senti était la meilleure approche dans cette situation.
Maintenant, si vous choisissez contre leur conseil à chaque fois, vous devrez peut-être de temps en temps céder et utiliser leurs "conseils" de temps en temps juste pour lisser quelques plumes ébouriffées. Tant qu'ils ne sentent pas que vous rejetez leur contribution à chaque fois, cela contribuera grandement à maintenir la paix entre vous.
Considérez également qu'ils sont un développeur senior et travaillent dans cet environnement depuis plus longtemps que vous. Le codage réel ne correspond souvent pas aux meilleures pratiques ou aux normes acceptées par la communauté. Il peut y avoir une raison pour laquelle ils vous ont recommandé de faire quelque chose d'une certaine manière qu'ils ne sont pas en mesure d'articuler pleinement. Donc, même si vous n'êtes pas d'accord avec eux, assurez-vous de ne pas rejeter leurs conseils d'emblée en vous basant uniquement sur le fait que vous pensez que votre solution est meilleure.
Tout est question d'équilibre. Et pas seulement l'équilibre du codage, mais l'équilibre de l'équipe. Beaucoup de projets ont échoué non pas parce que les développeurs n'étaient pas capables de le faire, mais parce qu'ils n'ont pas pu trouver des moyens de travailler ensemble à l'amiable.
Je voudrais apporter quelques éléments de mon expérience personnelle, qui devraient être considérés comme une réponse supplémentaire à celle publiée ici par jzd ...
- Demandez à un autre développeur senior,
- Faites des recherches par vous-même.
Dans un rendez-vous professionnel, j'étais censé être encadré par une personne âgée. Il connaissait certaines choses mais honnêtement pas beaucoup, malheureusement il ne le savait pas, alors il était ultra confiant dans ses réponses. Je sentais en quelque sorte que ce qu'il avait dit était faux. J'avais des preuves quand des choses qu'il faisait étaient contre les meilleures pratiques mentionnées dans la certification MS que j'ai prise :-). Après cela, j'ai commencé à demander à d'autres personnes travaillant dans d'autres entreprises (stackexchange n'était pas opérationnel à l'époque) et j'ai commencé à lire des blogs pour comparer les réponses.
Ce serait formidable si je me trompais, parce que je changerais simplement mon comportement, mais je ne l'étais pas.
J'ai remarqué quelque chose au cours des dernières années, presque toutes les entreprises dans lesquelles je travaille, presque tous les projets sur lesquels je travaille, presque tous les nouveaux employés (indépendamment du niveau de compétence/d'expérience) veulent faire quelque chose de `` différent ''.
Il peut s'agir des normes de codage ou de l'architecture globale ou du langage ou de la méthodologie. Mais c'est toujours quelque chose. Souvent, cela dit simplement l'évidence: "Tout ne devrait-il pas être mieux documenté, pour nos utilisateurs finaux?
Mon conseil est ne soyez pas ce type.
Un jour, vous serez un gars de haut niveau qui est embauché et payé pour prendre ces décisions. Quand ce jour arrive, allez-y! Jusqu'à ce jour, réalisez quelle est votre position. J'ai un patron, en ce qui me concerne, tout mon travail consiste à rendre mon patron heureux. Il ne s'agit pas de reconsidérer les décisions prises en dehors de ma rémunération. Si vous n'êtes vraiment pas sûr, parlez-en à votre patron/superviseur et découvrez-le.
D'une manière générale cependant, il est bien préférable d'avoir tout le monde à bord avec une approche dépassée que la moitié de l'équipe suivant l'approche obsolète, 1/4ème de l'équipe suivant une nouvelle approche et 1/4ème de l'équipe essayant de développer une technologie de pointe , toute nouvelle approche.
J'ai résolu la plupart de mes problèmes en publiant sur des forums et en obtenant des réponses des autres, et j'ai survécu pendant environ 1 an comme ça.
Que dois-je faire dans une telle situation?
Pour être honnête, voici à quoi ressemblent de nombreux emplois techniques. Vous devez être un entrepreneur autonome qui peut résoudre des problèmes difficiles par vous-même (avec l'aide d'Internet et des habitants) si vous le devez.
Du point de vue des révisions de code et de l'aide pour les conceptions architecturales, même quand j'ai eu de bons gestionnaires, je n'ai jamais eu beaucoup de révision de code au-delà de "les variables statiques devraient être préfixées a s_".
Profitez-en pour apprendre et apprendre à apprendre; ce seront des compétences que vous pourrez utiliser à l'avenir.
J'ai une opinion complètement différente/controversée à ce sujet.
Souvent, les gens perdent de vue l'objectif final qui, pour la plupart des industries, vise à maximiser les profits et à minimiser les pertes. Je sais que cela semble sans cœur (d'où les points négatifs) mais l'expérience et la sagacité importent très peu si vous n'allez pas produire de résultats.
Les gens peuvent se laisser entraîner par des choses extrêmement indirectes et minimes à discuter, qui ont très peu d'impact sur les résultats directs de l'entreprise.
Si vous pensez que vous avez raison sur quelque chose, votre meilleur pari est de montrer comment cela produira de meilleurs résultats mesurables résultats.
[Republier: parce que j'ai en quelque sorte créé un deuxième compte ici]
Mais récemment, il m'a de nouveau approché, a vu mon code et m'a demandé pourquoi je ne l'ai pas changé en son suggestion.
Vous devez savoir clairement s'il s'agit de suggestions ou d'ordres/instructions/directives/quoi que ce soit.
Suggestion = je pense qu'il vaut mieux le faire de cette façon; mais c'est votre choix.
Commande/etc. = Je veux que ce soit fait de cette façon; et c'est MON choix.
Si c'est vraiment une suggestion, faites comme vous le souhaitez et laissez votre code se tenir. Si c'est un ordre (et que ce mentor a autorité sur vous de cette manière) - faites comme ils disent.
ughh ahhh. Cette question me rappelle beaucoup de choses. Tout d'abord, je dirai que je ne pouvais pas m'entendre avec l'un des directeurs de mon dernier lieu de travail. Ce n'était pas un problème de personnalité. C'était un problème de communication. J'ai dit XYZ et ce gestionnaire spécifique interromprait ce que je disais comme ABC. Je ne serais pas en mesure de bien communiquer à moins de travailler avec ce manager pendant plus d'un an.
Le week-end dernier. Un gars s'est disputé/n'était pas d'accord avec moi au sujet des singletons. J'ai dit qu'ils ne sont pas bons et ne doivent JAMAIS être utilisés et absolument aucune raison de les utiliser. Je l'ai lié à http://www.gmannickg.com/?p=24 et au article plus détaillé auquel il renvoie quelques jours après l'argument. Le jour d'un autre programmeur (DudeB) mentionne qu'il n'utilise que des singletons lorsque cela est approprié (que j'ai ajouté avec "jamais"). DudeB n'a rien dit à ce sujet mais DudeB a dit que DudeB était dans un projet qui avait des conflits de mémoire parce que tous les threads accédaient au singleton. Après avoir mentionné cela, montré l'article et mentionné les conflits de mémoire avec lesquels je me suis disputé, nous devons accepter d'être en désaccord, ce que j'ai accepté parce que je n'aime pas parler de singletons (pourtant j'écris ceci d'oh)
Le point est. Parfois, vous pourriez vous tromper comme ce gars (peut-être que quelqu'un sera en désaccord avec moi dans un commentaire). Dans ma situation avec mon manager qui était mon programmeur principal, je viens de faire ce qu'on m'a explicitement demandé de faire et je n'ai plus jamais pris la qualité au sérieux sur ce lieu de travail. J'ai fait ce que je préfère faire quand on me le permet, mais j'ai toujours fait ce qu'on m'a demandé de faire, mais si je n'étais pas d'accord, j'en parlerais au moins une fois.
Au départ, j'essaierais de le faire, à la fin de la journée, la résistance aux seniors sera probablement futile au moins jusqu'à ce que vous gagniez en expérience et en respect. Utilisez-le comme une expérience d'apprentissage et dans 2 ans ou plus si vous ressentez toujours la même chose - passez à une autre entreprise. C'est à ce moment que vous pouvez utiliser une combinaison de vos bonnes idées et celles de vos aînés pour impressionner votre nouvel employeur. Bien sûr, vous pouvez commencer à réaliser certaines des raisons de ce que vous avez perçu comme de mauvaises décisions plus tôt dans votre carrière et à un moment donné, un développeur junior peut travailler pour vous.
Il est normal de remettre en question des choses tout en les faisant exactement comme demandé. Une bonne personne âgée peut ne pas toujours être en mesure de vous convaincre de la justesse de faire les choses avant qu'elles ne le soient, pour des raisons commerciales ou même simplement pour des raisons de dépendance à la tâche; mais devrait prendre le temps de reconnaître votre inquiétude, d'admettre qu'ils n'ont pas répondu et d'y revenir à un autre moment.
Lors de mon dernier emploi, j'ai travaillé aux côtés d'un autre développeur qui n'était là que depuis un mois de plus que moi. Il avait une certaine expérience dans d'autres sociétés travaillant sur des systèmes similaires. Il était très calme et équilibré. Pourtant, il m'a donné l'impression que ce n'était pas un développeur de logiciels natif. Par "natif", je veux dire qu'il est tombé dans une position de développeur progressivement au fil du temps. On pouvait dire qu'il était bien lu dans certains domaines, mais qu'il manquait de bases. Il était clair qu'il se débattait sur des problèmes apparemment simples. Il pouvait faire en sorte que le logiciel fasse ce qu'il voulait, mais il ne l'avait tout simplement pas "compris".
Personnellement, je ne pourrais jamais surmonter la mentalité "ma voie est meilleure parce que je l'ai lu dans un livre", ce que j'ai ouvertement admis lorsque j'y travaillais. À bien des égards, mon expérience antérieure m'a fait un mauvais ajustement pour le poste. Je ne sais pas si c'était parce que j'étais "trop avancé" ou simplement sur un chemin différent.
Lui et moi avons constamment discuté de la façon de faire des tests unitaires. Il croyait en une approche de boîte très blanche, via le patch de singe. Je préfère les tests de boîte noire pris en charge avec les simulations et l'injection de dépendance. Je pensais que son approche avait conduit à des tests fragiles, mais je suis sûr que certaines de mes opinions étaient influencées par mon expérience en C #. Il avait toujours travaillé en Python. Qui avait raison? Nous deux? Ni lui ni moi?
Les entreprises doivent être plus prudentes lors de la promotion de développeurs à un statut supérieur. Il est très difficile d'acquérir suffisamment d'expérience dans un emploi. Un bon développeur senior doit savoir quels outils sont disponibles et comment les autres magasins gèrent des problèmes similaires. Ce n'est que lorsque j'ai quitté mon premier emploi (où j'étais développeur principal) que j'ai appris à créer des sites Web modernes, à faire correctement un déploiement continu, à gérer les branches de contrôle des sources, à créer des services distribués ou à utiliser des bases de données NoSQL. Vous devez apprendre de nouvelles philosophies, technologies et processus pour être vraiment un développeur senior.
En fin de compte, les six mois qu'il avait passé plus de temps que moi lui ont donné l'avantage. Je me suis toujours plié à sa volonté et j'ai testé son chemin. C'est ce que font les professionnels. J'étais là pour apprendre. Pourtant, comme avec la plupart des développeurs pas tout à fait, il s'est frayé un chemin vers un poste de gestion. En moins de 3 semaines, nous avons eu une réunion et je suis sorti avec une boîte en carton. Maintenant, je suis content d'avoir été viré parce que cet endroit m'ennuyait aux larmes.
Ce n'était pas un environnement d'auto-amélioration. Malheureusement, les politiques destinées à aider commencent à nuire à la productivité lorsqu'elles sont suivies de manière trop stricte. Je restais assis là pendant des heures à attendre que d'autres examinent mon code, seulement pour obtenir des commentaires sur l'espacement des lignes et les conventions de dénomination. Quand j'ai commencé à faire des suggestions contraires à la politique ... Je suis soudainement devenu un rebelle, un opposant et un instigateur.
Si je comprends bien, votre responsable du développement est en fait juste là pour vous surveiller "car laisser un développeur entièrement seul serait irresponsable". Mais il ne sait pas comment juger réellement votre travail.
Tu lui en as parlé? Peut-être qu'il est fatigué de devoir faire ça aussi.
Si vous avez besoin de conseils et d'aide, ne serait-ce pas une solution meilleure et plus productive que de faire travailler un coéquipier avec vous sur votre projet?