Comment dites-vous si les conseils d'un développeur senior sont mauvais? [fermé]

Récemment, j'ai commencé mon premier emploi en tant que développeur junior et j'ai un développeur plus âgé en charge de me guider dans cette petite entreprise. Cependant, il me donnait souvent des conseils sur des sujets avec lesquels 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 des experts. Les questions que j'ai posées sur certains sites de questions-réponses sont également d'accord. avec moi) et vu 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 et en soulevant un contrepoint basé sur ce que j'avais appris en tant que bonnes pratiques actuelles. Il soulève à nouveau son point d'origine (la plupart du temps, il parlera des meilleures pratiques, il est plus facile à maintenir, mais il ne va pas plus loin), je prends note (puisqu'il n'a pas soulevé un nouveau point pour contrer mon contrepoint), pensez à faire des recherches à la maison, mais n’apportez aucune modification (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 modifié à sa suggestion. C'est la 3ème fois en 2-3 semaines.

En tant que développeur junior, je sais que je devrais le respecter, mais en même temps, je ne peux tout simplement pas être d'accord avec certains de ses conseils. Pourtant, on me presse de faire des changements qui, à mon avis, aggraveront le projet. Bien sûr, en tant que développeur inexpérimenté, je peux me tromper et son chemin pourrait être meilleur, ce pourrait être l'un de ces cas exceptionnels.

Ma question est la suivante: que puis-je faire pour mieux déterminer si les conseils d'un développeur senior sont bons, mauvais ou peut-être bons, mais dépassés dans le contexte actuel? Et si c'est mauvais / obsolète, quelle tactique puis-je utiliser pour ne pas le mettre en œuvre malgré ses "pressions" tout en maintenant le fait que je le respecte en tant que senior?

Premièrement, en tant que développeur senior, je m'attends à ce que les juniors que je dirige sur des projets m'apportent leurs préoccupations de manière directe et directe. S'ils ne sont pas d'accord, cela me convient parfaitement. Dans certains cas, je donnerai suite à leurs préoccupations. Dans la plupart des cas, leurs préoccupations sont mis de côté mis de côté avec une brève explication du raisonnement , non par manque de respect pour le développeur lui / elle - même , mais à cause d'une autre raison, comme:

1. Le junior n'a pas toutes les informations sous la main pour comprendre la décision telle qu'elle a été prise. Dans certains cas, une petite explication peut aider le développeur à surmonter le problème et à faire face à une situation unideal.
2. Le junior a une mauvaise information. N'oubliez pas que vous êtes, en fait, un junior. C'est l'équivalent d'être un adolescent en termes de logiciel. 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, la société, le monde. Ces développeurs sont mieux servis en acquérant de l'humilité.
3. La décision de faire quelque chose d'une manière particulière a été prise au-dessus de la tête du senior. La personne âgée travaille toujours pour quelqu'un d'autre à la fin. Il peut en fait exister un meilleur moyen de faire quelque chose, un moyen plus efficace d’écrire quelque chose ou de meilleurs logiciels / matériels pour vous aider à faire le travail. Cependant, l'entreprise continue à prendre les décisions. Les directeurs d’entreprise, directeurs, vice-présidents, etc. prennent souvent des décisions qui ont une incidence sur le processus de développement. Celles-ci sont indépendantes de la volonté de l'aîné, et lorsque les juniors s'en plaignent, ils ne font qu'ajouter au stress de l'aîné.
4. La personne âgée juste à plat n'a pas le temps de le prendre en compte. Il y a des délais, et parfois changer les habitudes, les pratiques et les comportements en cours de route coûte cher jusqu'à cette date limite. Etant donné que c'est le cou sur le billot, il est souvent plus important de rendre le produit fonctionnel et ponctuel que "parfaitement écrit".

Ce sont juste les choses que je peux penser à la tête de ma tête. Il y a une tonne de raisons pour lesquelles une idée, une pratique, un concept peut être rejetée ou rejetée par une personne plus élevée 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. Il se trouve que son opinion est numériquement supérieure à la vôtre pour le moment.

Gardant ces concepts à l'esprit, vous devriez continuer à faire part de vos préoccupations au développeur principal. Trouvez un autre développeur expérimenté qui pourrait peut-être remplir les blancs. Beaucoup de développeurs expérimentés se trouvent là où ils sont parce qu'ils maîtrisent mieux les logiciels que les utilisateurs. Certains sont à l'endroit où ils se trouvent parce qu'ils savaient à qui s'embrasser lorsqu'ils étaient stagiaires. Trouvez-en un qui comprend réellement ce que cela signifie de conseiller une personne et d'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 en aucun temps monter une insurrection. Même si vous croyez dans votre cœur que votre voie est la bonne, on vous a donné une instruction à suivre et vous devez la suivre (sauf si c'est illégal de toute évidence). Si vous ne parvenez pas à suivre ces instructions, essayez d’expliquer pourquoi parce que vous allez découvrir que ce schéma de comportement est très répandu dans de très nombreuses entreprises qui produisent tout type de logiciel.

Votre meilleure option est de continuer à faire votre travail de manière éthique et professionnelle. Faites en sorte que le logiciel que vous êtes invité à réaliser complète de manière exemplaire et échappiez à la situation en étant promu. Si les promotions ne viennent pas, vous aurez beaucoup de références et d'expérience pour poursuivre des opportunités dans d'autres départements ou sociétés.

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, alors faites-le.

Cela étant dit, n'hésitez pas à présenter vos préoccupations lorsque vous rencontrez un problème comme celui que vous 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 ratez quelque chose d'important, peut-être qu'il s'ouvrira davantage à vos suggestions, ne le gardez pas dans le noir si vous pensez que ses conseils sont médiocres.

Lorsque cela se produit, vous devez avoir une conversation avec le développeur principal . Peut-être sait-il quelque chose que vous ignorez sur le code ou les exigences techniques / commerciales. Si oui, vous devriez l'apprendre.

Faites-le en privé. Cela pourrait être perçu comme un défi à l'autorité, et il est préférable que ces choses se fassent face à face. Faites preuve de volonté de compromis et de collaboration en reconnaissant et en respectant son ancienneté, mais persistez à obtenir des réponses à vos questions. Abordez la situation dans un cadre collaboratif et non combatif. Vous pourriez envisager de lui demander de vous encadrer.

En fin de compte, vous devez équilibrer vos propres idées (qui, pour être juste, sont relativement nouvelles et non testées) avec les siennes. Vous avez peut-être raison, mais vous devriez faire de votre mieux pour apprendre des personnes plus expérimentées afin de pouvoir prendre une décision plus éclairée. Un bon développeur senior souhaite avoir la possibilité de collaborer, d'encadrer et d'apprendre, même avec des développeurs débutants, et souhaite que leurs idées soient remises en question de manière constructive, car elles savent aussi qu'elles ont parfois tort.

Vous dites souvent que vous utilisez une approche fondée sur le bon sens. N'oubliez pas que le développeur principal peut en savoir plus sur le projet, mais peut-être pas sur la bonne façon de faire les choses. Vous devez jauger ce qu'il vous dit de faire - il vous donne un mauvais conseil si ce qu'il dit va à l'encontre de ce que ses meilleurs prétendants (c.-à-d. Des personnes plus âgées que lui; pas nécessairement dans votre entreprise ... je parle de bien connus développeurs "de célébrités" qui postent ou écrivent souvent des livres sur la bonne façon de développer des logiciels, ou du 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'ils ignorent totalement ce qu'est le couplage lâche et pourquoi c'est une bonne chose, et que vous devez écrire tout le code, disons, le code - derrière un fichier ASPX, il est évident que le développeur principal n’a aucune idée de ce qu’il en est et que ses conseils ne doivent pas être écoutés.

Si, en revanche, il vous explique comment fonctionne un module spécifique dans le système, il est souvent préférable d'écouter, à condition que ce qu'il vous dit ne démente pas les principes de développement appropriés.

Voici ma règle de base: un développeur senior dans une entreprise peut simplement être le développeur ayant le plus long mandat; il pourrait ne pas avoir de véritable talent. Dit-il des choses qui vont à l’encontre de certains des développeurs les plus respectés de votre domaine (des personnes beaucoup plus expérimentées que lui et beaucoup plus compétentes et respectées)? Si c'est le cas, il est fort probable que son conseil soit mauvais, à moins de circonstances extrêmement extrêmes.

S'attendant pleinement à des votes négatifs / désaccords pour un point de vue extrêmement biaisé.

Il peut être difficile de comprendre le point de vue du développeur senior, et oui, il peut diriger les choses dans la mauvaise direction, mais pour les 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 constituerait un chaos total. Si les choses sont mal faites, il vaut toujours mieux avoir systématiquement tort que de nombreux types de fautes et certaines choses qui ont été bien faites.

Lorsque vient le temps d’effectuer des opérations de maintenance, d’ajouter des fonctionnalités ou de corriger ce qui est «faux», il est alors beaucoup plus facile de connaître dès le départ les problèmes liés à la conception existante.

Il est bon d’être respectueusement en désaccord, mais à la fin, il vaut mieux que vous vous mettiez dans la ligne. Les membres d'une équipe qui deviennent voyous ne sont pas considérés comme des joueurs d'équipe.

Si l'aîné ne peut pas vous expliquer pourquoi il ignore les meilleures pratiques de l'industrie, ne perdez pas votre temps là-bas. Vous n'allez jamais avancer parce que vous êtes trop menaçant, et de toute façon, voulez-vous passer du temps à conserver une pile de mauvais code?

La plupart des développeurs arrêtent de lire lorsqu'ils quittent le collège. Vous ne l'avez pas encore fait, vous êtes déjà dans le top 10%. Il y a beaucoup de possibilités ces jours-ci. S'il n'y a pas de marché du travail dans votre ville, cherchez une meilleure ville.

Wow, c'est une merveilleuse opportunité pour vous de briller et de montrer vos compétences. Au début de ma carrière, j'avais un superviseur qui était incapable de prendre une décision, aucune décision. J'ai donc profité de cette occasion pour apprendre à faire le travail du niveau supérieur suivant. Cela m'a permis d'être promu. Tu devrais faire pareil.

En tant que développeur senior, ce type de choix agressif passif me rendrait fou et après vous avoir confronté, vous me conduiriez à vous donner une mauvaise critique. La solution parfaite est celle avec laquelle l’équipe peut vivre ensemble.

En ce qui concerne le style, cela devrait être dicté par votre guide de style et les meilleures pratiques déterminées par votre origine. Si vous êtes passionné, argumentez-le, mais une fois qu'une décision est prise, restez en phase avec elle et travaillez avec l'équipe de votre choix.

Vous n'êtes pas dans une si bonne situation, mais, comme HLGEM l'a fait remarquer, vous pouvez transformer ces positions en bénédictions déguisées. Votre question a plusieurs facettes, je vais donc l'aborder par parties.

Je soupçonne, il ne sait pas. En même temps, il essaie de me montrer son arrogance afin que je ne lui pose pas beaucoup de questions.

Cela pourrait très bien être vrai. Il y a une vague de développeurs qui sont dans l'industrie depuis des décennies et qui ne sont pas capables de mener des logiciels - du point de vue du développement ou du mentorat (il y a une différence). L’expérience nous permet de relever de nouveaux défis, d’essayer de nouvelles idées et d’acquérir de nouvelles compétences, mais la majorité des programmeurs passent leur vie dans une branche du siège social, travaillant sur The Payroll Application avec leurs fidèles outils Visual Basic et Java, ne voyant jamais le monde courir. par leur bureau gris et froid.

Il n'y a rien de mal à cela . Pour beaucoup de développeurs, c'est tout ce qu'ils ont toujours voulu et ils sont parfaitement satisfaits de la situation. Ce n'est toutefois pas une situation idéale pour encourager une future génération de programmeurs, sans parler des principaux développeurs.

Bravado et l’arrogance peuvent être un mécanisme de défense qui tente de couvrir les insuffisances. Comment vous y prenez-vous? Ne le confrontez pas de front - si votre leadership est incompétent et que le patron refuse de rectifier la situation, vous devrez vivre avec . Cela ne signifie pas 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 pour le moment (au moins, il aura plus d’expérience et d’être exposé depuis si longtemps dans le secteur), mais encore une fois, cela ne signifie pas plomb efficace. Les directives sont bonnes et bonnes, mais elles sont en second lieu pour la fonction, l'efficacité et l'efficience du code.

Que dois-je faire dans une telle situation?

J'ai informé mon responsable de cette situation et je lui ai demandé de changer d'avis, 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 responsable et fourni des exemples spécifiques à l'appui? 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 que cela "se règle".

Voici quelques suggestions.

1. Ne soyez pas gêné par votre situation - les essais au feu, bien que pas amusants, vous apprennent des techniques de recherche essentielles pour plus tard dans votre carrière.
2. Commencez à pousser votre avance pour être plus impliqué. Faites ceci avec soin et respectueusement . Continuez à pousser et à persister jusqu'à ce qu'il cède (cela fonctionne dans de nombreuses situations de la vie).
3. Si votre responsable ne s'implique pas, voyez s'il y a d'autres personnes qui pourraient vous aider. À moins que vous ne travailliez dans un atelier spécialisé dans les ateliers de sueur qui se préoccupe uniquement des heures de traite, votre entreprise ne se souciera pas des autres développeurs plus expérimentés.
4. Commencez à garder un œil sur un nouvel emploi. Je ne dirais pas que vous êtes dans une situation de "devoir partir" mais cela ne serait pas préjudiciable à votre carrière d'être dans un endroit qui prenne votre développement de programmeur plus au sérieux.

Si vous avez une meilleure façon de le faire résoudre un problème particulier, juste DO IT .

Laissez votre code / solution être votre meilleur argument. Sinon, tenez-vous en à ce que l'on vous a dit.

Cas d'espèce

quand j'étais junior, je me trouvais dans une situation où une section de code particulière n'était pas la meilleure possible. Plutôt que de simplement en débattre, je l’ai tout simplement améliorée PUIS 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 son comportement peut être meilleur; ma question est donc de savoir comment déterminer si un conseil de développeur principal est bon ou mauvais / obsolète.

Vous pouvez devenir un développeur expérimenté. Jusqu'à ce que vous fassiez cela, vous serez mal outillé pour juger si votre intuition en tant que junior avait raison, et à ce moment-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 le mettre en œuvre à sa manière".

Jusqu'à présent, il semble que vous ayez bien agi. Vous étiez humble et avez soulevé un contrepoint. D'après votre question, je ne saurais dire si vous êtes simplement en désaccord avec sa méthode ou si vous êtes en désaccord et avez présenté une alternative. En bout de ligne, offrez toujours 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 toutes les situations, 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 de l'autoroute. Sur un plan plus positif, 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 progressiez. La prochaine fois que vous réalisez un projet de grande envergure, demandez à l'avance votre chance de présenter vos idées avant de commencer. Passez un peu plus de temps et réalisez une démonstration ou un prototype exceptionnel.

Assez choquant, ce que j'ai fait, c'est d'arrêter de demander. Lorsqu'on me donne une autre option, je m'éloigne du sujet et j'y ajoute mon propre talent. Utilisez-le comme une expérience d’apprentissage pour renforcer vos capacités tout en apaisant son besoin de le garder à l’école.

En fin de compte, tous les développeurs principaux ne prêtent pas attention aux nouvelles façons de faire. Ils ont parfois des habitudes de vieil école qui étaient excellentes pour la langue dans laquelle ils avaient débuté il y a 20 ans, mais qui sont considérés comme des hacky, ou "ont une mauvaise odeur" dans le monde d'aujourd'hui.

Cela peut sembler une façon terrible de continuer, et c'est le cas. Mais j'ai aussi beaucoup appris de la façon dont mes aînés font les choses. Mais ce n'est vraiment que mon avis. En fin de compte, vous devez être heureux au 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 seniors en raison de leur ancienneté. Défiez l'autorité aussi souvent que possible. Une autorité compétente devrait pouvoir 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 toute sa vie, cela ne veut pas dire qu'il a raison. Rappelez-vous qu'au Moyen Âge, les gens croyaient que la terre était plate et que certains de ces ânes égoïstes se sentaient même justifiés de tuer les sceptiques. Il s'est avéré que ceux qui doutaient avaient raison. Voilà pour les mauvaises critiques.

Ne craignez jamais une mauvaise critique. Feriez-vous confiance à un aveugle qui juge de la couleur?

Les bonnes réponses ci-dessus, ajouteraient qu’une réponse du type "meilleures pratiques" ou "plus maintenable" est une occasion d’ apprendre quelque chose . Vous dites: "Pouvez-vous me donner un exemple de la meilleure façon pour que je puisse comprendre la différence?" ou "Dans quelles situations cette manière serait-elle plus facile à maintenir qu'une autre façon, afin que je puisse apprendre à planifier de cette manière?"

Si le supérieur a raison, vous donner un exemple sera facile. S'il est un perroquet ... donnez-lui un biscuit pour arrêter le squawkin 'et faites ce que vous pensez être le meilleur. Jusqu'à ce que l'ordre soit donné.

Si le rôle de l'aîné consiste à conseiller, il expliquera pourquoi lorsqu'on le lui demande.

Comme HLGEM et Jarrod l'ont déjà dit, c'est une bénédiction déguisée. Les deux réponses sont excellentes et je voudrais ajouter quelques points.

Comme votre piste n'est pas dans votre domaine, vous devez prendre certaines des décisions importantes pour votre partie de l'application, car votre piste ne connaît pas grand-chose du middleware. Vous avez également des explications avec votre responsable sur la manière dont l’application doit se dérouler, sur ce que les utilisateurs du produit veulent et sur la manière dont votre responsable voudrait s’attaquer à une situation présentée par l’équipe produit. Dites-moi combien de personnes vont obtenir ce genre de connaissances sur une application.

Lorsque vous faites partie d'une grande équipe, vos coéquipiers et / ou votre chef vous aideront, mais vous ne saurez pas comment votre manager ou l'équipe du produit pense, car ce genre de choses est généralement le votre et peut être certains développeurs seniors dans une équipe. Je conviens que les projets à une personne sont un peu difficiles à porter, mais si l’autre côté de la médaille est si formidable, pourquoi rater une occasion? Apprenez ce que vous pouvez apprendre, profitez-en autant que possible et, si cela devient trop difficile, persuadez votre manager, comme le dit Jarrod, ou trouvez un nouvel emploi / projet en fonction de la situation.

Vous allez avoir affaire à des gens comme ça toute votre carrière. Et il y aura beaucoup de personnes avec lesquelles vous ne serez pas d'accord sur la meilleure approche à adopter 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 une question, soyez avec eux à l’avant-garde et dites-leur que vous avez envisagé leur solution parmi les diverses solutions possibles et Vous avez jugé que la meilleure approche était la meilleure dans cette situation.

Maintenant, si vous choisissez contre leur conseil à chaque fois, alors vous pouvez parfois avoir besoin de céder et d'utiliser leur "conseil" de temps en temps juste pour adoucir quelques plumes ébouriffées. Tant qu'ils ne sentent pas que vous refusez leur participation à chaque fois, cela contribuera grandement à maintenir la paix entre vous.

Pensez également qu’il s’agit d’un développeur senior et qu’il travaille dans cet environnement depuis plus longtemps que vous ne l’avez fait. Le codage réel ne correspond souvent pas aux meilleures pratiques ou aux normes acceptées par la communauté. Il y a peut-être une raison pour laquelle ils vous ont recommandé de faire quelque chose d'une certaine manière qu'ils ne sont pas capables de s'exprimer pleinement. Ainsi, même si vous êtes en désaccord avec eux, veillez à ne pas écarter leurs conseils du seul fait que vous estimez que votre solution est meilleure.

Tout est question d'équilibre. Et pas seulement l'équilibre de 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 ne trouvaient pas le moyen de travailler ensemble à l'amiable.

Je voudrais fournir quelques éléments de mon expérience personnelle, qui devraient être considérés comme une réponse complémentaire à celle postée ici par jzd ...

1. Demander à un autre développeur senior,
2. Faites des recherches par vous-même.

Lors d'une nomination professionnelle, j'étais censé être encadré par une personne de rang supérieur. Il connaissait certaines choses, mais honnêtement pas beaucoup, malheureusement, il ne le savait pas. Il était donc extrêmement confiant dans ses réponses. J'ai en quelque sorte senti que ce qu'il avait dit était faux. J'avais des preuves quand il affirmait qu'il s'opposait aux meilleures pratiques mentionnées dans la certification MS que j'ai obtenue :-). Après cela, j'ai commencé à demander à d'autres personnes travaillant dans d'autres sociétés (stackexchange n'était pas encore opérationnel) et j'ai commencé à lire des blogs pour comparer les réponses.

Ce serait formidable si j'avais tort, car je changerais simplement de comportement, mais ce n'était pas le cas.

J'ai remarqué quelque chose ces dernières années, presque toutes les entreprises où je suis, avec presque tous les projets sur lesquels je travaille, et presque chaque nouvel employé (quel que soit son niveau de compétence / d'expérience) veut faire quelque chose de «différent».

Il peut s'agir des normes de codage ou de l'architecture globale, du langage ou de la méthodologie. Mais c'est toujours quelque chose. Bien souvent, il est évident que: «Tout ne devrait-il pas être mieux documenté, pour nos utilisateurs finaux?

Je vous conseille de ne pas être ce mec .

Un jour, vous serez un type haut placé qui est embauché et payé pour prendre ces décisions. Quand ce jour viendra, allez-y! En attendant, sachez quelle est votre position. J'ai un chef. En ce qui me concerne, tout mon travail consiste à rendre mon chef heureux. Il ne s'agit pas de remettre en cause des décisions prises en dehors de mon niveau de rémunération. Si vous n’êtes vraiment pas sûr, parlez-en à votre patron / superviseur.

En règle générale, cependant, il est de loin préférable de mettre tout le monde à bord avec une approche obsolète que la moitié de l'équipe suivant l'approche dépassée, un quart de l'équipe suivant une nouvelle approche et un quart de l'équipe essayant de développer une technologie de pointe. , nouvelle approche.

Il y a un courant sous-jacent à tous ceux qui, à mon avis, devrait être clairement mis en évidence: ne soyez pas combatif . Préservez votre relation avec lui. C'est bien de prendre 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 traversé de nombreux projets, il n'est pas idiot, et il a beaucoup à apprendre de lui. Si vous en avez déjà l'impression, 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 (vous semblez déjà comprendre cela). Essayez de préciser 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 supposez pas qu'il vous bluffe. Comme cela a déjà été mentionné ici, il est peut-être occupé et / ou stressé.

C'est aussi génial 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 moment opportun. Assurez-vous que la suggestion est bien fondée, à part "c'est la meilleure pratique". Et veillez à bien faire les choses et à ne pas commettre d’erreur, afin d’avoir de la crédibilité lorsque vous exposerez vos arguments plus tard.

Jusqu'ici, j'ai essayé d'éviter le problème en l'écoutant, en soulevant un contre-point, il soulève à nouveau son point initial (la plupart du temps, il dira la meilleure pratique, plus maintenable mais ne va tout simplement pas 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 modifié pour tenir compte de sa suggestion. C'est la 3ème fois en 2-3 semaines.

(Légèrement édité 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 je lis (avec ma propre histoire, les autres peuvent être différents) est un développeur débutant qui ne comprend pas ce que dit le mentor et ne demande pas de clarification. Une façon de le comprendre est de lui demander de préciser: en quoi est-ce une meilleure pratique? Ou pourquoi cela est-il plus facile à gérer que cela pour notre code? Si vous ne connaissez pas ses réponses à cette question, vous ne savez vraiment pas s'il donne de bons conseils ou non.

Ce 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 dont cela pourrait paraître de son côté: il vous demande d'effectuer le changement, vous demandez pourquoi, il vous donne une raison (valable, à son esprit) et vous refusez d'effectuer le changement. Vous ne demandez pas de clarification, il suppose donc que vous comprenez la raison et que vous êtes trop paresseux ou trop têtu pour la changer - ce n'est pas non plus une bonne chose pour un développeur senior de penser à vous. Croyez-moi, il vaut bien mieux poser des questions que d’avoir une réputation de cette façon.

Quelques réflexions:

1 / ça marche? Est-ce que son chemin fonctionne ou pas? Est-ce que la raison objective pour laquelle son chemin serait inférieur?

Par raison objective, j'entends quelque chose qui peut être mesuré sans ambiguïté (performances, bugs, longueur de code, etc.) Si ses solutions fonctionnent et qu'il n'existe pas de métrique objective indiquant qu'il s'agit d'une mauvaise solution, faites-le à votre façon. Son chemin est meilleur ... parce qu'il est probablement plus compatible avec le reste de la base de code et qu'il lui sera plus facile d'utiliser / de réutiliser votre travail. Cela ne vous plaira peut-être pas, mais ce n’est pas ce dont il s’agit, n’est-ce pas?

Si cela ne fonctionne pas, ou sous-performez des métriques importantes, mettez-la en œuvre, comparez sa solution avec votre solution, puis dites-lui que vous avez essayé, mais que vous ne pouvez pas obtenir de bonnes performances (donnez les métriques) et demandez-lui si vous avez commis une erreur dans votre mise en œuvre ou s'il y a une exigence dont vous n'étiez pas au courant

2 / Les programmeurs étoiles disent ... Pourquoi s'en foutent? Vous rencontrerez des programmeurs renommés profondément en désaccord sur de nombreux sujets fondamentaux tels que la planification, la conception, la POO vs procédure, les tests unitaires, la gestion des exceptions, le contrôle de source, etc.

Si la seule différence d'ouvrabilité entre 2 solutions est de savoir qui la favorise, ignorez-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 de personnes que vous voulez ressembler, la réponse est que les conseils aux personnes âgées sont utiles si vous souhaitez devenir comme lui.

La plupart de mes problèmes ont été triés en postant sur des forums et en obtenant des réponses d'autres personnes. Je vis depuis environ un an comme celui-ci.

Que dois-je faire dans une telle situation?

Pour être honnête, voici à quoi ressemblent beaucoup d’emplois techniques. Vous devez être autonome et pouvoir résoudre vous-même des problèmes difficiles (avec l'aide si Internet et ses habitants) si vous devez le faire.

Pour obtenir des critiques de code et obtenir de l’aide pour les conceptions architecturales, même si j’avais de bons gestionnaires, je n’ai jamais eu beaucoup de révision de code au-delà de "les variables statiques doivent être précédées du préfixe s_".

Profitez de l'occasion d'apprendre et d'apprendre à apprendre; ce seront des compétences que vous pourrez utiliser dans le futur.

Si vous pensez une seconde que la direction ne comprend pas à quel point vous êtes VRAIMENT capable de faire le travail, alors vous avez probablement tort. La direction comprend probablement aussi que votre rôle actuel serait totalement inutile s'il vous remplaçait et prenait en charge votre travail.

Les VRAIES raisons pour lesquelles ils ne vous ont pas déplacé vous sont, car malgré tous les défis que vous leur présentez, vous êtes toujours la meilleure personne pour le poste. De toute évidence, ils apprécient trop votre travail pour risquer de le transmettre à quelqu'un d'autre.

Ne sous-estimez pas l'intelligence de la direction ...

Ils sont bien plus intelligents que ce que la plupart des développeurs leur accordent. Je n'ai pas compris cela avant de commencer à gérer. Ils sont probablement également conscients de l’inefficacité de votre avance, mais ils sont probablement impuissants à faire face à ce problème.

Laissez-moi vous brosser un tableau. Lead A, 5 ans d’expérience au sein de la société, est incompétent. Le responsable le sait, recommande à son supérieur hiérarchique de mettre à pied le responsable A. Le supérieur supérieur demande pourquoi il n’a pas été traité il ya des années s’il est aussi incompétent. Le manager a mauvaise mine, d’autant plus que le principal A a un salaire exagéré qui n’était pas rémunéré…

Voici un autre scénario potentiel, le responsable A est un ami proche d’une personne importante. Il est trop chaud politiquement pour prendre,

Quoi qu’il en soit, avec une longue erreur comme celle-ci, il est plus facile pour les grandes entreprises de dissimuler des personnes incompétentes, de leur donner un travail occupé et de leur donner un pouvoir factice qui convient à leurs années «d’expérience» où elles ne peuvent pas causer trop de dégâts. . Malheureusement, de nombreuses organisations préfèrent le faire plutôt que de traiter réellement les problèmes.

Bien entendu, la raison en est que, dans ce type d’organisation, le responsable est toujours mieux placé à court terme pour traiter les mauvais talents de cette manière que pour résoudre les problèmes à long terme que ce type de personnes peut apporter à l’organisation.

Donc, bien que ce soit une vision à court terme et potentiellement contraire à l’éthique, vous devez admettre que c’est un peu plus intelligent que beaucoup de développeurs le reconnaissent.

ughh ahhh. Cette question me rappelle beaucoup de choses. Tout d'abord, je dirais que je ne pouvais pas m'entendre avec l'un des responsables 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 responsable spécifique interromprait ce que je disais en tant qu'ABC. Je ne serais pas en mesure de bien communiquer si je ne travaillais pas avec ce responsable pendant plus d'un an.

Le weekend dernier. Un gars a discuté / a été en désaccord avec moi au sujet des singletons. J'ai dit qu'ils ne sont pas bons et ne devraient JAMAIS être utilisés et absolument aucune raison de les utiliser. Je l'ai lié à http://www.gmannickg.com/?p=24 et à un article plus détaillé qui est lié àquelques jours après la dispute. Le jour d’un autre programmeur (DudeB) mentionne qu’il n’utilise que des singletons lorsque c’est approprié (ce que j’ai ajouté avec «jamais»). DudeB n'a rien dit à ce sujet mais DudeB a précisé 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, en montrant l'article et en évoquant des conflits de mémoire, le type avec qui j'ai discuté a dit qu'il faudrait accepter de ne pas être d'accord, ce que j'ai accepté parce que je n'aime pas parler de singletons (et pourtant j'écris ceci).

Le point est. Parfois, vous pourriez vous tromper, comme ce gars-là (peut-être que quelqu'un ne sera pas d'accord avec moi à propos de singletons dans un commentaire). Dans ma situation avec mon responsable qui était mon programmeur principal, je viens de faire ce qui m'était explicitement demandé et je ne prenais plus la qualité au sérieux sur ce lieu de travail. J'ai fait ce que je préfère 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, je le ferais au moins une fois.

J'ai un avis complètement différent / controversé à ce sujet.

Souvent, les gens perdent la trace de l'objectif final qui, pour la plupart des industries, consiste à 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 retrouver avec des choses extrêmement indirectes, très minimes, qui ont très peu d'impact sur les résultats directs de l'entreprise.

Si vous pensez avoir raison à propos de quelque chose, votre meilleur pari est de montrer comment cela produira de meilleurs résultats mesurables .

Dans un premier temps, j'essayerais de tenir le coup. En fin de compte, la résistance au senior serait probablement vaine 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 vous sentez toujours pareil - passez à une autre entreprise. C’est à ce moment-là que vous pourrez utiliser une combinaison de vos bonnes idées et de celles de vos aînés pour impressionner votre nouvel employeur. Bien sûr, vous pouvez commencer à comprendre 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é, vous pouvez avoir un développeur junior qui travaille pour vous.

[Repost: 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'avais pas modifié à sa suggestion .

Vous devez indiquer clairement s'il s'agit de suggestions ou d'ordonnances / d'instructions / de directives / autres.

Suggestion = Je pense qu'il est préférable de le faire de cette façon; mais c'est votre choix.

Commande / etc. = Je veux le faire de cette façon; et c'est mon choix.

Si c'est vraiment une suggestion, faites ce que vous voulez et laissez votre code tenir. Si c'est un ordre (et que ce mentor a autorité sur vous de cette manière) - faites comme on dit.