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


39

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.


18
Je suis un gars, junior (dans cette entreprise) et j’ai ressenti le même double standard. La base de code ressemble souvent à de la merde, et pourtant je suis censée suivre un standard beaucoup plus élevé. Eh bien, il s’est avéré que de la merde est entrée à cause des "marches de la mort" qui avaient été faites dans le passé. De plus, apparemment, j'ai l'air 5 ans plus jeune que moi. Quand mes collègues ont découvert mon âge réel, je suis devenu beaucoup plus intelligent du jour au lendemain. Les humains sont des singes imparfaits. Il est utile de partager le déjeuner avec eux et de rire de leurs blagues, mais n'en faites pas trop. Les gars interprètent TOUT comme un flirt.
Job

4
@Job: Eh bien, si la base de code est de la merde, elle devrait être meilleure. Par conséquent, vos commits doivent avoir un standard plus élevé. Sinon, ça deviendrait encore plus nul, non? :)
Macke

@Marcus, vous avez raison, mais ce qui serait vraiment utile, c'est que les règles soient clairement énoncées et que les mêmes règles s'appliquent à tout le monde. En outre, il y a quelque chose à dire sur le fait de se fondre dans les mêmes normes de code, comme l'a dit le demandeur. J'ai vu un jeune homme se faire renvoyer en tant que bouc émissaire. La direction s'est plaint du fait que les ingénieurs ont produit trop de bugs. Les ingénieurs ne pouvaient pas faire un travail décent car la direction leur donnait des délais fixes. Donc, quand quelque chose ne va pas, il y a toujours un gars junior avec le plus de bêtises à blâmer et à laisser aller. fr.wikipedia.org/wiki/Dedovshchina
Emploi

3
Une chose qui m'a frappé est "Ils sont habitués aux gars, alors ils n'utilisent pas le décorum". Je dirais que vous devez accepter tout cela à moins que ce ne soit clairement un problème de discrimination. Souhaitez-vous aller sur un chantier de construction et s'attendre à être traité différemment du reste des encadreurs? Endurcir. Si vous travaillez dans un environnement dominé par les hommes, vous devez être capable de vous adapter et de vous adapter aux différentes normes sociales. Ne soyez pas si "sensible".
Rig

1
Je sais que c'est plusieurs années trop tard, mais je pense que c'est un sujet important pour les futurs lecteurs. N'excluez pas la possibilité que votre chef d'équipe sache simplement mieux; il est probablement plus âgé et a développé une intuition pour les problèmes de style problématiques - je défie quiconque dans cette situation de le traiter comme une opportunité d'apprendre et de grandir. Demandez respectueusement des éclaircissements sur les problèmes que vous ne comprenez pas et veillez à ne pas mal interpréter la personnalité sèche d'un collègue comme étant malveillante.
weberc2

Réponses:


41

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.


Les réponses d'Anna sont généralement très raisonnables. +1 Je pense que travailler là où tu travailles me rendrait dingue. Votre direction ne se soucie-t-elle pas de respecter les délais? Si le code fonctionne, expédiez-le. Nettoyez-le plus tard. Heck, vous pourriez même le nettoyer lundi et le faire passer dans la prochaine version. Ce comportement de votre responsable n’aurait jamais lieu sur mon lieu de travail et je suis heureux de pouvoir me concentrer sur le respect des délais au lieu de la politique. J'espère que votre situation s'améliore et que vous trouvez une solution. :)
jmort253

11
@ jmort253 Merci. :) Cela dit, "si le code fonctionne, envoyez-le" peut être une attitude dangereuse. Le code de travail n'est pas toujours un bon code (bien qu'il soit certainement meilleur que le code cassé) et la qualité du code est importante à long terme. Un nettoyage plus tard n’est presque jamais arrivé, car d’autres échéances apparaissent et que des problèmes plus pressants se présentent. Il existe un terme pour cela - "dette technique".
Adam Lear

@Anna, convenez de l'importance du code conforme. J'ai lu que du code non conforme suffisait à Linus Thorvalds pour rejeter sur-le-champ un correctif soumis pour Linux (mais je ne parviens pas à le localiser maintenant).

@ Anna / Thorbjorn - Parfois, il suffit de faire ce que le client veut s'il existe un délai. Votre client ne sera pas très compréhensif s’il perdait 15 000 USD de revenus d’entreprise, simplement parce que vous vouliez simplement éliminer les erreurs de capitalisation. Malheureusement, tenter d’éliminer 100% de la dette technique n’est pas toujours possible. Cela équivaudrait à attendre 40 ans pour économiser suffisamment d’argent pour acheter la maison de vos rêves au lieu de contracter un emprunt hypothécaire. Bien sûr, vous seriez libre et clair, mais vous auriez passé toute votre vie à traiter avec des propriétaires louches.
Jmort253

Les projets open source sont différents des projets à but lucratif. De nombreux projets open source peuvent se permettre d'avoir des normes plus strictes car il n'y a pas toujours de profit à gagner / à perdre. Les projets propriétaires ont des objectifs différents, qui sont parfois prioritaires. Je ne dis pas que le code ne doit pas être conforme, mais que parfois, il vous suffit de faire ce que vous avez à faire et de faire preuve de discipline pour revenir et résoudre le problème après le déploiement.
Jmort253

25

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.


2
+1 Vous vous concentrez sur les relations et les émotions. Les programmeurs avec lesquels vous travaillez ont un son très sec, mais ils se concentrent uniquement sur les problèmes de code. C’est assez courant dans les environnements de programmation dans lesquels j’ai travaillé. J’ai vu cela indépendamment du sexe.
Michael Durrant

14

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


Cela soulève beaucoup de bons points.
Sevenseacat

13

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.


1
Essayer de suivre un "standard" avec le "T" quand on a affaire à des conneries comme elle le décrit ne fera pas grand bien. Ce sera un argument sans fin sur les définitions et la sémantique.
MrDatabase

4
@MrDatabase Cela ne me ressemble pas beaucoup. Un peu difficile, peut-être, mais le diable est souvent dans les détails et une fois que vous commencez à glisser vos standards, votre application entière peut aller rapidement en descente.
Adam Lear

3
Il est vrai que les normes doivent être respectées. Cependant, elle démontre clairement que ce n'est pas vraiment une norme (les développeurs précédents n'y avaient pas adhéré). Par conséquent, ses collègues lui imposant le "standard" (sans dire quelque chose comme "hé, regarde ... nous savons que cela semble incohérent, mais nous essayons vraiment d'améliorer notre base de code") est hypocrite et inutile. Lorsque vos collègues agissent de la sorte, vous devez adopter une approche différente et plus intelligente.
MrDatabase

@ user15859: si vous vous référez à ma réponse, ce n'était pas du tout mon intention. Je crois avoir dit exactement la même chose qu'Anna dans sa réponse. Aucune infraction n'était destinée. Les violations des normes que vous avez mentionnées sont importantes pour la maintenance à long terme, et toute ambiguïté dans le champ d'application des normes doit être résolue avec votre chef d'équipe. Si vous étiez paresseux, vous n’auriez pas posté ici. Si vous étiez incompétent, vous ne vous en soucieriez pas beaucoup. Je ne crois pas que vous soyez l'un ou l'autre.
Steven A. Lowe

1
Je pense qu'elle se réfère à ce que Woot4Moot a dit lorsqu'il a utilisé "la paresse et l'incompétent" comme une phrase dans son commentaire. Je pense que votre réponse est correcte car cela donne au PO un recours et une marge de manœuvre pour agir en fonction de son interprétation de ce qui se passe réellement.
Jmort253

10

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.


1
J'appuie le commentaire sur "j'y reviendrai plus tard". Si j'en avais un centime à chaque fois que j'entendais ça, eh bien, je ne serais pas là à taper ce commentaire. :-)
Eric King

Pour .Net, il y a le style flic. Activez-le pour que le code ne soit pas généré tant que StyleCop n’est pas satisfait. Cela élimine la subjectivité humaine est l'intimidation de la force de travail. Vous voyez, la technologie peut vous aider à décider si Michael Phelps était n ° 1 ou n ° 2. En patinage artistique, cependant ... figureskating.about.com/od/famousskaters/tp/scandals.htm Etre chef d’équipe ne devrait pas être synonyme de puissance. Il ne devrait pas y avoir de [dis-] favoris dans une équipe. Il faut faire attention à ce que cette impression ne se forme pas. Une bonne façon de le faire est d'activer des règles permettant de vérifier le code et de vous donner une réponse impartiale.
Job le

3

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.


1

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.


0

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!


1
Trouver le travail avant d'arrêter, beaucoup de gestionnaires d'embauche n'intervieweront même pas si vous n'avez pas d'emploi.
Woot4Moo

-2

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.


2
Cela ne semble pas "draconien"; la cohérence est un élément important de la maintenabilité, celle-ci est essentielle à la qualité, et un logiciel de qualité a beaucoup plus de chances d'être expédié à temps et à un coût inférieur à celui d'un "code de compromis". Il peut être encourageant de constater qu'environ 80% des éditeurs de logiciels souhaitent compromettre la qualité et en subir les conséquences. Il ne semble donc pas y avoir de pénurie de possibilités d'emploi "non draconiennes". :)
weberc2

1
Je ne voudrais pas travailler dans un environnement où les conventions de base ne sont pas appliquées. Si un projet renonce à défendre ses directives de codage, il est condamné à devenir incontrôlable à long terme. Nommer les variables en particulier n’est pas une mince affaire: quel que soit le code existant appelé une certaine matrice A, je n’accepterais jamais un commit qui appelle une autre matrice à des Bfins de cohérence. Bien sûr, je ne sais pas ce que le PO entendait par "imiter des noms [...] utilisés ailleurs" avec précision, cependant, vu la qualité du code que j'ai vu, il pourrait aller dans ce sens.
cmaster
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.