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

266

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?

learnjourney
la source
26
Vous apprenez plus des erreurs que des succès.
StuperUser
45
Pouvez-vous donner un exemple d'une des questions sur lesquelles vous êtes en désaccord? Je sais que la question est plus théorique et que vous voulez probablement éviter les débats techniques, mais il serait intéressant d'entendre le désaccord terminé.
Adam Rackis
140
Je vois un drapeau rouge dans ce post. Vous avez dû être invité à faire quelque chose trois fois. Une fois devrait suffire. Si vous ne voulez pas faire quelque chose, vous devez convaincre votre mentor que ce n'est pas nécessaire. Si vous ne pouvez pas faire cela, alors tenez votre nez et agissez ou trouvez un nouvel emploi.
PeterAllenWebb
6
@peterallenweb, en effet il est mauvais d’être demandé 3 fois quelle que soit la qualité du conseil. Je suppose que, d'après les commentaires ici, j'ai beaucoup à apprendre en termes de travail dans différentes équipes. :)
learnjourney
33
En plus de ce que Peter a dit: Réfléchissez à son point de vue: vous demandez au nouveau type de faire quelque chose, d'avoir une discussion technique, sans plus d'objection, puis - une semaine plus tard, vous découvrez qu'il a simplement ignoré votre demande. Et ce n'est pas la première fois que cela se produit. (Ne vous inquiétez pas trop - vous n'êtes certainement pas la première personne tout droit sortant d'université à tomber dans ce piège. Tant que vous serez au courant de ces problèmes et que vous y travaillerez, tout ira bien.)
Martin,

Réponses:

233

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.

Joel Etherton
la source
47
@Joel Bonne réponse, mais méfiez-vous des préoccupations qui sont "rejetées de côté". Les préoccupations doivent toujours être reconnues même si elles sont invalides, même si la meilleure réponse que vous avez est "Je comprends votre préoccupation, mais pour le moment nous devons faire X à cause de Y". Le rejet superficiel d'idées sérieuses tue le moral et peut éventuellement détruire les cultures les plus saines.
Rein Henrichs
42
@Joel: Beaucoup de bons points, mais c'est un peu condescendant: "C'est l'équivalent d'être un adolescent en termes de logiciel." Le respect que mérite un développeur senior de la part des développeurs débutants est obtenu en prenant systématiquement les bonnes décisions, et non pas simplement en raison de son âge ou de son ancienneté.
Neil G
26
Il est difficile de savoir comment savoir si un développeur senior est "bon" ou non. La réponse, telle qu'énoncée ici, semble être "peu importe, faites ce qu'il dit". Je ne dis pas que c'est un mauvais conseil; Je dis simplement que cela ne répond pas à la question. Pour ce que ça vaut, je pense que la seule bonne réponse est de savoir s’il est bon dans 5 ans, quand vous serez senior.
Kevin
2
@ Kevin: Je ne peux pas discuter de ce commentaire et je ne peux certainement pas recommander à un développeur débutant une méthode pour déterminer le moyen de répondre à cette question spécifique. Souvent, les aînés ne peuvent pas répondre avec précision les uns aux autres. Ma réponse était honnêtement axée sur certains des autres aspects de la question des PO qui me paraissaient plus pertinents que la manière de repérer un développeur senior de mauvaise qualité.
Joel Etherton
11
Il semble que la réponse manque de l’humilité dont vous parlez. Les jeunes pensent souvent tout savoir, mais les seniors ne partagent-ils pas le même vice? Cela est exagéré dans notre secteur - une grande partie de nos connaissances sera moins pertinente dans quelques années. (Exemple concret - j'ai un mentor dans un projet de taille moyenne qui a dit que nous devrions "fabriquer des boutons et écrire du code SQL dessus, pour gagner du temps". Il a été très impressionné lorsque je lui ai montré LINQ to Entity et asp.net page sans code )
Kobi
35

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.

jzd
la source
29
OP - vous êtes tous deux des professionnels, même si vous avez moins d'expérience, discutez-en avec lui de manière professionnelle sur les questions que vous interrogez. S'il ne veut pas parler du pourquoi de ses instructions, il n'est pas vraiment un mentor.
DaveE
10
+1 pour "Il est plus que le sien pour la réussite du projet". Comme c'est vrai. Je sais que vous, développeurs juniors, n'appréciez pas la chance que vous avez de ne pas avoir ce genre de stress sur vous car je ne l'avais certainement pas quand j'étais développeur junior. Maintenant sortez de ma pelouse!
maple_shaft
1
Je suggérerais également que si / lorsque vous suivez ses suggestions, conservez un document de vos préoccupations concernant le changement - si cela se produit plus tard, vous pourrez peut-être indiquer cela pour montrer que vous avez prédit l'erreur.
Daenyth
4
@DaveE: On dirait qu'ils ont déjà eu la discussion et que le PO ne disposait pas de suffisamment de contexte pour comprendre actuellement la sagesse de l'aîné. Parfois, vous ne pouvez expliquer que trop, le reste devra provenir de l’expérience.
Martin York
2
@ Niphra: Possible. Mais sans informations plus précises, je suis plus enclin à croire qu'il ne s'agit que d'un apprenant naïf qui en sait moins qu'il ne le pense. La plupart des personnes âgées savent réellement ce qu’elles font (vous ne devenez pas ingénieur en chef si vous êtes stupide, vous entrez dans la gestion).
Martin York
24

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.

Rein Henrichs
la source
4
+1 pour avoir une conversation. Le développeur principal est peut-être mieux à même (et responsable) d’équilibrer différentes préoccupations, mais il devrait pouvoir expliquer ses raisons. S'expliquer auprès des juniors, afin qu'ils puissent apprendre, est une grande partie d'être un senior. Et si, en tant que junior, vous n’avez pas l’impression d’apprendre, il est peut-être temps de changer de travail.
Jaap
+1 pour le meilleur en tête-à-tête. Le temps du désaccord est derrière des portes closes. Lorsque la porte s'ouvre et que la discussion est finie, il ne devrait y avoir aucune dispute, aucun affaiblissement, aucune plainte. N'ouvrez pas la porte avant d'arriver à ce point. Si vous êtes toujours en désaccord, dites à la personne âgée que vous avez l’intention de la confier à son supérieur hiérarchique.
Michael Riley - Alias ​​Gunny,
18

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

Wayne Molina
la source
Je dois admettre que je suis en fait choqué par le fait que j'ai sept votes positifs (à ce jour) et aucun vote négatif. J'aurais pensé que mon attitude / mon point de vue pessimiste / mon ton ranty ne m'aurait pas plu avec les gens :)
Wayne Molina
Sur Slashdot, l'annonce que vous vous attendiez à être modifié était une technique éprouvée dans le karma-whoring.
Carson63000
Je devrai essayer plus souvent j / k :)
Wayne Molina
11

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.

arbre_érable
la source
11

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.

Kevin Cline
la source
9
Dire aveuglément que «nous devons appliquer les meilleures pratiques de l’industrie» n’est peut-être pas le meilleur moyen d’ouvrir une discussion. Il pourrait y avoir une très bonne raison de faire autre chose que la plupart des autres.
7
Je pense que c'est la plus proche encore d'une réponse réelle. Un développeur expérimenté devrait être en mesure de fournir des raisons convaincantes pour justifier le bien-fondé des méthodes qu’il préconise. Vous ne pourrez pas vous améliorer sous le mentorat de quelqu'un qui ne le peut pas. Maintenant, si vous vous retrouvez dans votre troisième société et que tous les développeurs seniors étaient des idiots à votre avis, il serait peut-être temps de regarder de plus près dans le miroir.
PeterAllenWebb
2
@PeterAllenWebb, "devrait être capable", oui, mais vous ne voulez pas nécessairement argumenter heure après heure en expliquant en détail pourquoi vous avez trouvé qu'une pratique donnée était mauvaise pour vous. Parfois, "pourquoi?" Peut être répondu avec "Parce que!"
@ Thorbjørn Ravn Andersen: Je suis d'accord tant que c'est occasionnel.
PeterAllenWebb
11

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.

HLGEM
la source
J'apprécie votre réflexion, mais j'ai peur de l'avenir et de la spéculation car il peut y avoir des situations plus difficiles, dans lesquelles poster sur des forums pourrait ne pas aider. Que dois-je faire alors?
developer123
4
Creusez dans les livres et apprenez en profondeur. Internet n'est pas le seul moyen d'apprendre. Rejoignez un groupe de développeurs locaux et établissez des contacts avec des personnes plus expérimentées que vous pouvez contacter.
HLGEM
c'en est une bonne.
developer123
9

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.

rediffusion
la source
6
En tant que développeur junior, ce type de dictature me rendrait folle. J'ai voté à la baisse, désolé.
kizzx2
9

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.
Jarrod Nettles
la source
Merci beaucoup, vos points sont vraiment gentils et réfléchis. Upvote pour vous.
developer123
Merci, j'ai choisi votre réponse, car elle combine le meilleur.
developer123
7

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.

Nuit noire
la source
11
@maple_shaft: quel genre d’équipe êtes-vous si le code (et tous les utilisateurs qui le gèrent) doivent souffrir pour protéger les sentiments des développeurs seniors?
Jaap
1
@Jaap, Tout d'abord, je parle de responsable technique ou de projet, cela ne doit pas nécessairement être un développeur expérimenté. Deuxièmement, il ne s'agit pas de leurs sentiments, il s'agit de progresser vers un objectif commun en tant que groupe. Le responsable devrait avoir un semblant de contrôle sur son groupe, qu’il se trompe ou non. Le responsable est celui qui assume la responsabilité du code de buggy mis en place, des fonctionnalités incomplètes et des délais non respectés, donc s’il est fou, il en souffrira. Si l'entreprise ne reconnaît pas qu'il est un imbécile, elle en souffrira.
maple_shaft
2
S'il a déjà reçu l'ordre de le changer, la révision du code a échoué. Essayer simplement de soumettre à nouveau cela signifie qu'il se fera dire que cela a déjà échoué.
Martin York
2
@darknight, en supposant qu'il ne s'agisse pas d'un problème minime, le changement de paradigmes sur une base de code existante pourrait entraîner de sérieuses représailles. Ce qui me vient à l’esprit lorsque je pense à ce type de débat est la structure de la base de données. Des changements comme ceux-là ne seront certainement pas appréciés.
Morgan Herlocker
1
Ceci ne s'applique qu'aux très petites unités de travail. Supposons que vous travailliez pendant deux semaines et que le code soit rejeté. Comment allez-vous obtenir un financement pour ces deux semaines?
7

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.

Blrfl
la source
7

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.

Morgan Herlocker
la source
6

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.

Jim Crandall
la source
4

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.

Tim Meers
la source
3

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?

ThomasW
la source
5
La plupart des gestionnaires n'auront pas beaucoup de patience pour un jeune développeur qui conteste tout. Si c'est le cas, va sacrifier une poule en l'honneur de Cthulhu, parce que tu as trouvé un grand patron! Sinon, préparez-vous à magasiner beaucoup jusqu'à ce que vous en trouviez un.
2

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.

Steven A. Lowe
la source
2

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.

Amar Jarubula
la source
Merci à vous, HLGEM et Jarrod pour avoir souligné les aspects positifs.
developer123
1

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.

BBlake
la source
1

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.

Dimitrios Mistriotis
la source
5
Il n'y a presque jamais de raison valable d'ignorer les meilleures pratiques de l'industrie, hormis l'ignorance et / ou le refus de le faire correctement. Ce sont des "meilleures" pratiques pour une raison et les personnes qui les ont proposées sont dix fois plus intelligentes et même plus expérimentées que le développeur principal qui les ignore ou n'en a pas conscience.
Wayne Molina
@Wayne M: Bien dit.
Jim G.
6
@Wayne, vous devez toujours comprendre pourquoi ce sont des pratiques exemplaires. Si vous dites aveuglément "c'est une pratique exemplaire, nous devons le faire!" sans savoir pourquoi, vous n'êtes pas meilleur vous-même.
Je dirais que Wayne a laissé assez de place dans sa réponse à la réfutation d'Andersen.
C Johnson
@ Thorbjørn Ravn Andersen, @learnjourney - De tous les commentaires et réponses, le commentaire de Thorbjørn est probablement le conseil le plus critique et le plus pertinent. Vous devez comprendre les problèmes qu'une pratique exemplaire essayait d'empêcher ou de résoudre, sans quoi vous ne saurez jamais si ces problèmes s'appliquent toujours. En bref, vous devez comprendre pourquoi il s’agit d’une pratique exemplaire. C'est ainsi que vous suggérez des alternatives: en éclairant les problèmes résolus par la meilleure pratique. Comme le mérovingien de la matrice a dit: "Sans" Pourquoi "vous n'avez rien".
Thomas
1

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.

Rob P.
la source
17
-1: 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. : Tu ne travailleras jamais pour moi. Je n'engage pas 'Yes Men'. Je souhaite que mes rapports directs offrent des critiques constructives lorsque je suis sur le point de prendre une décision sous-optimale. Si je n'avais pas apprécié leurs opinions, je ne les aurais pas embauchées.
Jim G.
7
Je suis en désaccord avec ce sentiment. Premièrement, si vous souhaitez être promu, vous devez montrer que vous êtes capable et disposé à assumer les responsabilités d'un poste de direction. Par conséquent, garder la tête basse n'est pas une bonne chose pour votre carrière à long terme. Deuxièmement, je ne crois pas en l'approche «au-dessus de mon salaire». Tout le monde est là pour assurer le succès de l'entreprise (si ce n'est pas le cas, vous n'avez plus de travail), donc si vous voyez une meilleure façon de faire quelque chose, au-dessus de votre salaire, vous devriez le signaler. Parfois, un nouvel employé peut faire de bonnes suggestions car il a une perspective nouvelle.
Cercerilla
6
Je suis d'accord avec @Jim G. Avoir l'attitude d'être un "Smithers" est la pire chose que vous puissiez faire; Penser que votre responsable a toujours raison est une chose terrible car souvent, il a tort. Également d'accord avec @CodeninjaTim - une nouvelle recrue a souvent de meilleures suggestions car elle n'a pas le même point de vue que les gars à long terme, elle est donc moins susceptible de simplement suivre le "statu quo"
Wayne Molina,
4
@ Jim G: Il semble que le PO ait déjà exprimé sa préoccupation "C'est la 3ème fois en 2 ou 3 semaines." - Je ne peux pas imaginer que vous voudriez employer quelqu'un qui, après avoir exprimé son opinion et expliqué que A est meilleur que B (même s'il n'est pas d'accord), il refuse d'effectuer le changement. À ce stade, il ne travaille pas vraiment pour vous.
Rob P.
3
@Wayne M - Je ne préconise pas que nous croyions que nos gestionnaires ont toujours raison. J'ai suggéré d'exprimer ses préoccupations de manière appropriée. Mais après avoir reçu l'ordre de faire quelque chose 3 fois en quelques semaines, OP ne le gère pas correctement. Certainement, exprimez vos préoccupations, mais réalisez que vous êtes EMPLOYÉ (à moins que vous ne le soyez - alors ignorez cela). Vous avez accepté de travailler pour quelqu'un d'autre en échange d'un certain niveau de compensation. Le fait que vous ayez un patron implique de vous attendre à faire ce que l'on vous dit, dans des limites raisonnables. Vrai ou faux, c'est ce que vous avez choisi en tant qu'employé
Rob P.
1

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.

M. Jefferson
la source
1

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.

Caleb Huitt - cjhuitt
la source
J'ai demandé des éclaircissements, mais la réponse que j'ai toujours reçue est "c'est une meilleure pratique" ou quelque chose du genre avant qu'il ne revienne faire ses propres choses. À mon avis, c’est une chose de dire que c’est une bonne ou une meilleure pratique, mais ce que je voulais savoir, c’est «pourquoi», c’est mieux, ce qu’il n’a pas été capable de m’expliquer, mais insister, c’est mieux et comme il est un senior , Je devrais lui faire confiance. Malgré tout, il est mauvais de ma part de ne pas changer malgré le fait qu'on me l'ait demandé trois fois
learnjourney
@ Learnjourney: Je conviens qu'il y a probablement un problème si vous demandez pourquoi et si vous n'obtenez pas de réponses. Je recommanderais toujours que vous restiez au courant de ce à quoi cela pourrait ressembler de l’autre côté, mais si ce développeur senior ne peut vous aider, trouvez-en un autre et mettez le problème devant eux, avec juste le principe de base ", dit-il <raison>, pouvez-vous expliquer comment cela s’applique ici? ", et pas de récrimination. Si cela ne fonctionne pas, je regarderais quelques-unes des autres réponses qui disent quand même d'effectuer le changement, mais gardez votre version et vos raisons à portée de main. Assurez-vous d'apprendre de l'une ou l'autre manière.
Caleb Huitt - lundi
1

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

Sylverdrag
la source
1

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.

Alexandre
la source
1

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.


la source
Oui, c'est la seule chose optimiste que je vois dans ma situation.
developer123
1

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.

arbre_érable
la source
Merci pour la réponse et pour apporter le côté gestion de la pensée et leurs points de vue. Upvote pour vous.
developer123
0

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.

utilisateur2528
la source
1
Re: "peut-être que quelqu'un ne sera pas d'accord avec moi dans un commentaire sur les singletons" - je ne suis pas d'accord avec vous; o) Mais
acceptons d'
0

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 .

Adam Gent
la source
-1: Si ridicule. // L'essentiel de votre opinion "controversée" repose sur le fait que le PO est pris au piège dans des détails ou une trivialité. Tu ne le sais pas! Prenez la question à la lettre.
Jim G.
La plupart des programmes sont de la petite Jim G. Et d’expérience (je suis un développeur senior), il existe de nombreux autres BS impliqués dans le fait d’avoir raison . Il y a presque toujours une image plus grande. Et les gens plus haut réagissent à la vue d'ensemble (voir sa mise à jour), pas à "mais mon design est plus découplé". Comme le PO ne donnait pas d'exemple, je devais prendre des libertés.
Adam Gent
0

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.

Matt Wilko
la source
5
-1: Pourquoi perdre plus de 2 ans à travailler pour un n00b senior?
Jim G.
@ Jim - le fait de changer d'emploi après 6 mois ne convient pas à votre CV. Si vous déménagez ailleurs et que l'aîné est encore pire, l'effet sur votre CV est exponentiellement néfaste! Vous pourriez aussi apprendre à réaliser que tout ce qu'ils ont dit n'était pas incorrect ou qu'il y avait au moins une raison de le faire de cette façon.
Matt Wilko
1
@ Jim - Même si je suis d'accord dans la pratique, Matt a raison. les gens sont stupides et le travail constant d'essayer de trouver un environnement approprié peut vous blesser (je peux parler d'expérience à ce sujet). Cela dépend de la nature exacte des conseils, s’ils ne sont pas optimaux (par exemple, nous ne pouvons pas utiliser TDD ou utiliser un conteneur IoC) ou carrément faux (par exemple, je ne sais pas ce qu’est une interface ou pourquoi vous en utiliseriez un dans programmation). Le premier est bien "collé", le dernier est l'endroit où vous fuyez en hurlant parce que le senior est un idiot (j'espère que j'ai bien compris ces termes ... ils me confondent toujours)
Wayne Molina,
0

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

BIBD
la source