À quel moment une critique «constructive» de votre code devient inutile?

J'ai récemment commencé en tant que développeur junior. En plus d’être l’une des personnes les moins expérimentées de l’équipe, je suis aussi une femme, qui doit faire face à toutes sortes de défis en travaillant dans un environnement dominé par les hommes. J'ai eu des problèmes ces derniers temps parce que je sens que je reçois trop de critiques pédantes injustifiées sur mon travail. Laissez-moi vous donner un exemple de ce qui s'est passé récemment.

Le chef d’équipe était trop occupé pour pousser dans certaines branches que j’avais faites, il n’a donc pas été contacté avant le week-end. J'ai vérifié mon courrier, ne voulant pas vraiment travailler, et j'ai constaté que mes deux branches avaient été rejetées sur la base de noms de variables, ce qui rendait les messages d'erreur plus descriptifs et transférait certaines valeurs dans le fichier de configuration.

Je ne pense pas que le rejet de ma branche sur cette base soit utile. Beaucoup de gens travaillaient pendant le week-end et je n'avais jamais dit que je travaillerais. Effectivement, certaines personnes ont probablement été bloquées parce que je n'ai pas eu le temps de faire les changements et de soumettre à nouveau. Nous travaillons sur un projet qui nécessite beaucoup de temps et il me semble qu’il n’est pas utile de rejeter du code sur la base de choses transparentes pour le client. Je me trompe peut-être, mais il me semble que ce genre de choses devrait être traité dans des commits de type correctif lorsque j'en ai le temps.

Maintenant, je peux voir que dans certains environnements, ce serait la norme. Cependant, les critiques ne semblent pas également distribuées, ce qui conduit à mon prochain problème. La base de la plupart de ces problèmes était due au fait que je me trouvais dans une base de code écrite par quelqu'un d'autre et que j'essayais d'être minimalement invasive. Je reproduisais les noms de variables utilisés ailleurs dans le fichier. Lorsque j’ai déclaré cela, j’ai été carrément dit: "Ne mime pas les autres, faites ce qui est juste." C'est peut-être la chose la moins utile que l'on aurait pu me dire. Si le code déjà enregistré est inacceptable, comment suis-je censé dire ce qui est juste et ce qui ne va pas? Si la base de la confusion venait du code sous-jacent, je ne pense pas que cela

Je me sens vraiment isolé et frustré dans cette situation. J'ai beaucoup mieux respecté les normes attendues et je me sens frustré de constater que, par exemple, lorsque je refactorise un élément de code permettant de corriger une erreur qui manquait auparavant, on me dit seulement que je ne l'ai pas fait. faire les erreurs assez verbeuses (et la branche a été rejetée sur cette base). Et si je ne l'avais jamais ajouté pour commencer? Comment est-il entré dans le code pour commencer si c'était si faux? C'est pourquoi je me sens tellement distingué: je rencontre constamment ce code problématique existant, que je mime ou que je refacture. Quand je l'imite, c'est "faux", et si je le refactorise, on me reproche de ne pas en faire assez (et si je vais jusqu'au bout, en introduisant des bugs, etc.). Encore une fois, si cela pose un tel problème, je ne comprends pas comment un code pénètre dans la base de code,

Quoi qu'il en soit, comment puis-je gérer cela? S'il vous plaît rappelez-vous que j'ai dit en haut que je suis une femme, et je suis sûr que ces gars-là n'ont généralement pas à s'inquiéter du décorum lorsqu'ils examinent le code des autres gars, mais honnêtement cela ne fonctionne pas pour moi et cela me rend moins productif. Je crains que si j'en parle à mon supérieur hiérarchique, il pensera que je ne peux pas gérer l'environnement, etc.

Il est possible que vous soyez choisie comme femme, mais il est également possible que vous soyez une jeune développeur et que vous débutiez dans l’emploi.

La vérification des erreurs et les messages expressifs sont importants. Si vous souhaitez ajouter quelque chose au code, assurez-vous qu'il est correct et conforme aux normes de l'équipe. De même, si vous modifiez le code de quelqu'un d'autre, essayez de l'améliorer autant que possible - ne vous liez pas à réécrire le tout, mais essayez de le laisser un peu plus propre que vous ne l'avez trouvé.

Existe-t-il une version écrite des normes de codage suivies par votre équipe? Sinon, ce serait peut-être une bonne idée de tout écrire. Vous pouvez diriger l'effort en notant les erreurs que vous faites et en les formant dans une liste de contrôle à laquelle vous pouvez vous référer avant de soumettre vos modifications pour révision. Comme effet secondaire, vous pouvez utiliser cette norme écrite pour faire appel des rejets ultérieurs s'ils le contredisent.

Il semble y avoir un manque de compréhension entre vous et le chef d’équipe. Il pourrait être utile pour vous de demander une rencontre individuelle avec lui et de discuter de ce que vous pouvez faire pour l'améliorer. Vous pouvez commencer avec quelque chose comme "J'ai l'impression qu'il me manque encore beaucoup de nuances de ce que je devrais faire. En tant que développeur junior, je veux grandir et m'améliorer. Pouvez-vous m'aider à y arriver?" et voir ce qui se passe.

On dirait que vous prenez peut-être ces choses un peu trop personnellement. Ne pas Ce genre de chose arrive tout le temps.

Les raisons du rejet de votre enregistrement (désignation des variables, qualité des commentaires, emplacement de la configuration) me paraissent assez classiques.

Le choix du moment a été décidé par votre chef d’équipe, et je ne m'en inquiéterais pas si j'étais vous. Si quelqu'un est bloqué pendant le week-end, le responsable de l'équipe peut choisir d'autoriser l'enregistrement et vous demander de le réparer par la suite. S'il pense qu'il est approprié de le supprimer même s'il risque de bloquer d'autres développeurs, c'est sa responsabilité.

En ce qui concerne le chef d’équipe qui vous dit de ne pas imiter les autres, mais de faire ce qui est juste, il semble vouloir vous donner l’initiative nécessaire pour améliorer la base de code. C'est bon signe. Il vous fait confiance pour utiliser votre jugement, alors allez-y et faites ce que vous savez être juste. Cela ne signifie pas que vous devez modifier le code de tout le monde, mais que vous devez assumer la responsabilité de la qualité du code que vous écrivez.

Un ajout aux autres réponses:

En tant que développeur principal, je suis généralement plus difficile avec les développeurs juniors car ils sont beaucoup plus malléables que ceux qui travaillent depuis quelques années. (Mes compétences personnelles ne sont pas très bonnes ... pour le moment.)

Il est très difficile de changer quelqu'un qui travaille (et gagne un salaire décent) depuis un moment et qui est satisfait de son niveau de code (même si la qualité pourrait être améliorée). Ces gars-là ne se soucient pas si vous essayez de les guider pour devenir de meilleurs / grands programmeurs. Ils sont heureux de travailler dans l'usine de code.

Les nouveaux gars, comme vous, OTOH, aspirent généralement à des conseils et savent ce qui est juste ou pas. En outre, ils sont en mesure d'absorber la rétrocession et de changer leur manière de s'améliorer. Ils ne sont pas définis de manière différente.

Si vous prenez ces conseils à cœur et les intégrez à votre vie de tous les jours, vous constaterez qu’en très peu de temps vous allez écrire un code supérieur à une grande partie de la base de codes existante.

Alors ...

.. il se peut que vous obteniez plus de commentaires simplement parce que vous avez le potentiel pour en tirer quelque chose. :)

Il est tout à fait possible que vous soyez distingué parce que ... vous êtes un développeur junior.

D'après votre description, il semble que vous n'ayez pas suivi la norme telle que perçue par le responsable de l'équipe .

La solution est simple:

• Si c'est la norme, suivez-la.
• Si vous ne comprenez pas la norme, demandez des éclaircissements.
• Si votre interprétation de la norme ou des instructions diffère de celle du chef d’équipe, demandez des éclaircissements.

Ne vous battez pas pour ça; si vous essayez de rendre l'équipe "mauvaise", alors même si vous gagnez, vous perdez. Apprenez la leçon appropriée et continuez à vous développer.

Note de l'auteur

Quelques années plus tard; J'ai édité ceci pour refléter plus précisément ce que je pense de la situation. Je mets plus de nuance dans ma réponse parce que j'en apprends plus sur la nuance dans ces situations. Il est facile de réclamer une réponse «noir ou blanc», mais nous savons tous que ce n'est pas si simple. Ma réponse reflète maintenant cela.

D'après ce que vous avez décrit le comportement que vous rencontrez ne semble pas avoir de lien avec votre sexe. Cela ne veut pas dire que vous ne subissez aucun traitement lié au genre (j'espère que vous ne l'êtes pas), seulement que ce que vous décrivez ne semble pas être lié au genre.

Quand j'étais chef d'équipe, je traitais tout le monde sur un pied d'égalité. La technologie ne permet pas de maltraiter quelqu'un à cause de son sexe. Je ne sais pas comment m'en occuper si cela vous arrive.

Il est important de croire que votre chef d'équipe traite les hommes et les femmes sur un pied d'égalité. S'il existe des preuves qu'il ne le fait pas, le vieil adage s'applique: changez votre environnement ou changez votre environnement.

Par également, je veux dire qu'il traite tout le monde également, sans déférence pour le genre. S'il fait son travail correctement, vous ne devriez pas le voir critiquer quelqu'un d'autre; et ils ne devraient pas le voir vous critiquer. Devant les autres, il est très important que le chef d’équipe fasse preuve de confiance, même s’il vient de passer les cinq dernières minutes avant de corriger son comportement en privé.

Passons maintenant aux questions que vous avez soulevées:

Vous avez enregistré un code qui ne respectait pas la norme qu'il avait définie. Il a donc rejeté votre succursale. Si j'avais été à sa place, je n'aurais pas fait la même chose de la même manière, mais je ferais en sorte que mes subordonnés (mot étrange; parce que je ne pense pas à un leader comme étant «supérieur» à ceux qu'ils conduire, mais il décrit avec précision (pas correctement) la situation) savoir ce qui est la bonne chose à faire. S'ils ne savent pas quelles sont les normes, c'est de ma faute en tant que leader. C'est à moi de le corriger. Dans ce cas, vous avez peut-être commis une erreur, mais le simple fait que cela se soit produit signifie que vous avez été soit 1) pas informé de ce que la bonne chose à faire était, soit 2) n’aviez pas été correctement encadré. Ni est de votre faute.

L'un des aspects les plus importants du métier de programmeur est de réaliser que la base de code sur laquelle vous travaillez doit pouvoir être maintenue par de nombreuses personnes différentes. Les messages variables ou autres éléments empêchant de lire le code ne sont pas transparents pour le client , car il faut plus de temps pour résoudre les problèmes de code plus difficile à lire.

Si votre équipe a rédigé des directives de codage, suivez-les. Si ce n'est pas le cas, il devrait y avoir une sorte de convention de communauté pour votre langage (pour .NET et C #, Microsoft a une norme qui est suivie par de nombreuses entreprises).

Demandez au chef d’équipe où se trouvent les directives de codage afin de vous assurer de les suivre. Effectuez deux check-ins à vos réunions lorsque deux autres développeurs ne respectent pas systématiquement les directives. Ainsi, lorsqu'il dit qu'il n'y en a pas, vous pouvez indiquer que d'autres semblent également avoir des problèmes, et que tout le monde gagnerait à le faire. ces lignes directrices.

S'il vous traite équitablement, il le verra et cela devrait figurer en haut de sa liste de choses à faire. S'il ne vous traite pas équitablement, alors vous avez des munitions si cela continue.

Dire "j'y reviendrai plus tard" est mauvais. Plus tard n'arrive jamais. Prenez le temps de bien faire les choses. Il n'y a pas plus tard dans la programmation.

C'est difficile quand vous êtes développeur junior. Vous vous sentez obligé (e) de jouer et beaucoup de gens vous regardent, et chaque erreur que vous faites est liée à votre nom dans le contrôle de source à jamais.

Vous ne mentionnez nulle part dans votre message la manière dont les autres personnes sont traitées. Vous répétez sans cesse que vous "sentez" que vous êtes "distingué" parce que vous êtes "une femme".

Je pense que vous êtes traité comme un programmeur débutant, quel que soit votre sexe, et vous devriez en être reconnaissant, car c’est ce que signifie l’égalité. J'ai également le sentiment que vous faites tout un tas de choses sur des modifications esthétiques de code mineures de 5 minutes que l'on vous demande de faire maintenant au lieu de les inscrire sur une liste de tâches à faire et de ne jamais les contourner.

Vous n'avez mentionné nulle part dans votre message que vous aviez reçu l'ordre de faire ces choses la fin de semaine. Il pourrait être parfaitement correct de vérifier les correctifs lundi matin.

Votre chef d'équipe est peut-être un peu pédant à mon goût, mais d'après votre message, je ne vois rien qui cloche dans ses demandes.

S'il vous plaît, arrêtez de jouer la carte de genre pour rien . J’estime que cela n’est pas digne et mine le concept d’égalité des sexes.

Je ne pense pas que le rejet de ma branche sur cette base soit utile. Beaucoup de gens travaillaient pendant le week-end et je n'avais jamais dit que je travaillerais. Effectivement, certaines personnes ont probablement été bloquées parce que je n'ai pas eu le temps de faire les changements et de soumettre à nouveau. Nous travaillons sur un projet qui nécessite beaucoup de temps et il me semble qu’il n’est pas utile de rejeter du code sur la base de choses transparentes pour le client. Je me trompe peut-être, mais il me semble que ce genre de choses devrait être traité dans des commits de type correctif lorsque j'en ai le temps.

Il est difficile de dire quoi que ce soit d’utile en tant que personne qui n’a pas vu votre code et qui ne connaît rien du calendrier de vos projets. Mais, si votre lead se comporte de manière responsable et fait du bon travail, il sait que d’autres ne sont pas vraiment bloqués et que le sprint ne sera pas en retard. Alors, ne vous inquiétez pas pour ça. Peut-être surestimez - vous l'impact sur votre commit. Autrement: si votre projet est critique et qu'il passe tous les tests avec succès, il serait trop difficile de rejeter le code, qui pourrait être corrigé après la publication en un clin d'œil.

Make It Work Faire les choses bien Faire les choses rapidement

Donc, si votre responsable a pris la décision de rejeter votre engagement, en tant que professionnel, il devrait savoir ce qu’il faisait.

Maintenant, je peux voir que dans certains environnements, ce serait la norme. Cependant, les critiques ne semblent pas également distribuées, ce qui conduit à mon prochain problème. La base de la plupart de ces problèmes était due au fait que je me trouvais dans une base de code écrite par quelqu'un d'autre et que j'essayais d'être minimalement invasive. Je reproduisais les noms de variables utilisés ailleurs dans le fichier. Lorsque j’ai déclaré cela, j’ai été carrément prévenu: "Ne mime pas les autres, mais fais ce qui est juste."

En tant que Junior, il est difficile de trouver son chemin dans une base de code d’une entreprise.

Le mieux: il existe des normes de codage documentées - et vous espérez apprendre à les maîtriser.

Habituellement: il existe des normes de codage non documentées - et vous devez apprendre par essais et erreurs ou devrais-je dire commit et _reject? C'est souvent douloureux (comme dans votre cas). Cela est parfois dangereux en termes de qualité du code et peut conduire à une programmation culte du fret , dans laquelle on imite non seulement la dénomination des variables, mais on copie et colle les structures et les motifs de la base de code de bonne foi, il faut le faire comme cela. Ne faites pas cela! Ne même pas imiter le nom des variables existantes.

S'en tenir au code propre . C'est une bonne pratique et vous donne une position facile à défendre. S'il s'agit d'un code lisible, testable et maintenable, vous avez généralement gagné la discussion.

Et ceci mène à un autre (dernier) conseil: suivez la règle du scoutisme !

Laissez toujours la base de code dans un meilleur état qu’elle ne l’était. Même si le code environnant avec lequel vous travaillez est méchant, nettoyez-le - et si vous avez le temps de réparer les environs.

Prenez un peu de temps pour apprendre les différentes nuances de la personnalité de vos collègues. D'après mon expérience, vous pouvez éviter les critiques irrationnelles, inutiles, incohérentes ou tout simplement dénuées de sens si vous travaillez avec vos bizarreries de collègues de travail.

Par exemple, certains collègues peuvent avoir la gueule de bois le lundi. Ils peuvent être très irritables et trop impatients de rejeter certaines branches de code ou commits. Si vous devez travailler avec quelqu'un comme cela, essayez d'éviter de commettre du code le lundi.

D'autre part, un collègue affamé peut être trop blasé pour se soucier de la verbosité des messages d'erreur ... Le lundi matin peut donc être le moment idéal pour valider votre code :-p

Les bizarreries de personnalité au bureau ou sur le lieu de travail sont littéralement infinies. J'espère que vous pourrez apprendre qui éviter et quand les éviter. Ne soyez pas trop dur envers vous-même :-) Vous pouvez toujours quitter et trouver un autre emploi!

Je n'ai jamais travaillé dans un environnement où le code est rejeté car certaines conventions ne sont pas suivies. Si j'étais à votre place, je serais tenté de chercher un emploi dans un endroit où je suis plus en mesure de prendre les bonnes décisions et où le client est l'objectif principal, pas le code.

Je ne dis pas que le code propre et les normes ne sont pas importants, mais le client et la chronologie du produit ne devraient pas en pâtir à cause d'une faute d'orthographe dans quelque chose qu'aucune personne non technique, client ou dirigeant ne verra jamais.

Cela dit, il semble que vous travailliez dans un environnement où les attentes ne sont pas claires ou que vous ne comprenez pas parfaitement les exigences, pour une raison quelconque.

Quelle que soit la situation, c'est à vous de prendre le contrôle et de poser des questions de clarification. Soyez proactif si vous ne l'êtes pas déjà. Les membres de votre équipe et le chef d’équipe vous respecteront probablement davantage lorsque vous posez des questions afin de clarifier les règles d’enregistrement. Vous pouvez également demander une «analyse après action» au cours de laquelle vous, votre chef d’équipe, discutez de ce que vous auriez dû faire et de la peut faire la différence dans la mesure où quand prendre certaines actions et quand ne pas le faire.

Je suggère de donner du temps, puisque vous êtes nouveau, pour voir si vous pouvez surmonter les obstacles et résoudre ces problèmes avec l'expérience, la communication et l'apprentissage des normes. Toutefois, si après plusieurs mois, la situation n’a pas changé et que l’ambiguïté règne toujours sur l’environnement, il serait peut-être temps de chercher du travail dans une autre entreprise.

Toutes les organisations ne sont pas aussi draconiennes et vous pouvez trouver d'autres environnements de travail plus adaptés à votre personnalité, à votre style et à vos besoins en matière de communication.