Em que ponto a crítica “construtiva” do seu código se torna inútil?

37

Comecei recentemente como desenvolvedor júnior. Além de ser uma das pessoas menos experientes da equipe, também sou uma mulher, que vem com todos os tipos de desafios próprios trabalhando em um ambiente dominado por homens. Eu tenho tido problemas ultimamente porque sinto que estou recebendo muitas críticas pedantes injustificadas no meu trabalho. Deixe-me dar um exemplo do que aconteceu recentemente.

O líder da equipe estava muito ocupado para empurrar alguns galhos que eu fiz, então ele não chegou até o fim de semana. Eu verifiquei meu e-mail, não realmente querendo fazer nenhum trabalho, e descobri que minhas duas ramificações foram rejeitadas com base em nomes de variáveis, tornando as mensagens de erro mais descritivas e movendo alguns valores para o arquivo de configuração.

Eu não sinto que a rejeição do meu ramo nesta base é útil. Muitas pessoas estavam trabalhando no fim de semana, e eu nunca disse que estaria trabalhando. Efetivamente, algumas pessoas provavelmente foram bloqueadas porque eu não tive tempo para fazer as alterações e reenviá-las. Estamos trabalhando em um projeto que é muito sensível ao tempo, e parece-me que não é útil rejeitar completamente o código com base em coisas que são transparentes para o cliente. Eu posso estar errado, mas parece que esses tipos de coisas devem ser tratados em commits de tipo de patch quando eu tiver tempo.

Agora, eu posso ver que em alguns ambientes, isso seria a norma. No entanto, as críticas não parecem igualmente distribuídas, o que leva ao meu próximo problema. A base da maioria desses problemas deveu-se ao fato de que eu estava em uma base de código que alguém havia escrito e estava tentando ser minimamente invasivo. Eu estava imitando os nomes de variáveis usados em outras partes do arquivo. Quando afirmei isso, foi-me dito francamente: "Não imite os outros, apenas faça o que é certo". Esta é talvez a coisa menos útil que eu poderia ter sido dito. Se o código que já está registrado é inaceitável, como devo dizer o que está certo e o que está errado? Se a base da confusão estava vindo do código subjacente, não acho que seja minha responsabilidade gastar horas refatorando um arquivo inteiro que alguém escreveu (e funciona perfeitamente), potencialmente introduzindo novos bugs etc.

Estou me sentindo realmente isolado e frustrado nessa situação. Eu fiquei muito melhor em seguir os padrões esperados, e me sinto frustrado por, por exemplo, quando refatorei um trecho de código para verificar o erro ADD que estava faltando anteriormente, só me disseram que não o fiz. tornar os erros suficientemente verbosos (e o ramo foi rejeitado nessa base). E se eu nunca tivesse adicionado para começar? Como ele entrou no código para começar, se foi tão errado? É por isso que me sinto tão bem apontada: constantemente me deparo com esse código problemático existente, que eu imito ou refatorio. Quando eu imitá-lo, é "errado", e se eu refatorar, eu sou repreendido por não fazer o suficiente (e se eu for até o fim, introduzindo bugs, etc). Novamente, se isso é um problema, não entendo como qualquer código entra na base de código e por que se torna minha responsabilidade quando ele foi escrito por outra pessoa, que aparentemente não teve seu código revisado.

De qualquer forma, como eu lido com isso? Por favor, lembre-se que eu disse no topo que eu sou uma mulher, e tenho certeza que esses caras geralmente não precisam se preocupar com o decoro quando estão revisando o código de outros caras, mas sinceramente isso não funciona para mim e isso está me fazendo ser menos produtivo. Estou preocupado que, se eu falar com meu gerente sobre isso, ele pense que não posso lidar com o meio ambiente, etc.

    
por user15859 06.02.2011 / 03:32
fonte

9 respostas

41

Existe uma chance de você ser escolhido como mulher, mas também é possível que você seja apenas um desenvolvedor júnior e novo no cargo.

Mensagens de verificação de erros e expressivas são importantes. Se você for adicionar algo ao código, verifique se ele está correto e de acordo com os padrões da equipe. Da mesma forma, se você estiver modificando o código de outra pessoa, tente melhorá-la sempre que possível - não se esqueça de reescrever tudo, mas tente deixá-la um pouco mais limpa do que a encontrada.

Existe uma versão escrita dos padrões de codificação que sua equipe segue? Se não, pode ser uma boa ideia escrever tudo. Você pode liderar o esforço escrevendo os erros que você comete e os formando em uma lista de verificação à qual você pode se referir antes de enviar as alterações para revisão. Como efeito colateral, você pode usar esse padrão escrito para apelar a futuras rejeições se elas o contradizerem.

Parece que pode haver alguma falta de compreensão entre você e o líder da equipe. Pode ser útil pedir uma reunião pessoal com ele e discutir o que você pode fazer para melhorar. Você pode liderar com algo como "Eu sinto que ainda sinto falta de muitas nuances do que eu deveria estar fazendo. Como um desenvolvedor júnior, eu quero crescer e melhorar. Você pode me ajudar a chegar lá?" e ver o que acontece.

    
por 06.02.2011 / 04:33
fonte
25

Parece que você pode estar levando essas coisas um pouco pessoal demais. Não faça; esse tipo de coisa acontece o tempo todo.

As razões para rejeitar seu check-in (nomeação de variáveis, qualidade de comentários, local de configuração) parecem bastante normais para mim.

O timing foi a decisão do líder da sua equipe, e eu não me preocuparia se fosse você. Se alguém for bloqueado no fim de semana, o líder da equipe pode optar por permitir o check-in e pedir que você o corrija mais tarde. Se ele achar apropriado retroceder, mesmo que isso possa bloquear alguns outros desenvolvedores, essa é sua responsabilidade.

Quanto ao líder da equipe dizendo para você não imitar os outros, mas para fazer o que é certo, parece que ele está tentando dar-lhe alguma iniciativa para melhorar a base de código. Isso é um bom sinal. Ele confia em você para usar o seu julgamento, então vá em frente e faça o que você sabe que é certo. Isso não significa que você tenha que mudar o código de todos os outros, mas significa que você deve assumir a responsabilidade pela qualidade do código que você escreve.

    
por 06.02.2011 / 04:33
fonte
13

É perfeitamente possível que você esteja sendo destacado porque ... você é um desenvolvedor júnior.

A partir da sua descrição, parece que você não seguiu o padrão como o líder da equipe percebe .

A solução é simples:

  • Se esse é o padrão, siga-o.
  • Se você não entender o padrão, peça esclarecimentos.
  • Se a sua interpretação da norma ou das instruções diferir da do líder da equipe, peça esclarecimentos

Não faça uma batalha com isso; se você tentar fazer com que a equipe lidere "errado", então mesmo que você ganhe, você perde. Aprenda a lição apropriada e continue a crescer.

    
por 06.02.2011 / 04:01
fonte
13

Uma adição às outras respostas:

Como desenvolvedor líder, geralmente sou mais exigente com os desenvolvedores juniores, porque eles são muito mais maleáveis do que as pessoas que trabalham há alguns anos. (Minhas habilidades ppl não são tão boas ... ainda.)

É muito difícil mudar alguém que está trabalhando (e ganhando salário decente) por um tempo e está satisfeito com seu nível de código (mesmo que a qualidade possa ser melhorada). Esses caras não se importam se você tentar guiá-los a se tornarem melhores / melhores programadores. Eles estão felizes trabalhando no código de fábrica.

Novos caras, como você, OTOH, geralmente anseiam por orientação e sabem o que é certo e não. Além disso, eles são capazes de absorver o feeback e mudar seus caminhos para melhor. Eles não são definidos em suas formas.

Se você levar esses conselhos para o coração e torná-los parte de sua vida cotidiana, você descobrirá que em pouco tempo você estará escrevendo código que é superior a grande parte da base de código existente.

Então ...

... pode ser que você receba mais feedback só porque tem potencial para fazer algo disso. :)

    
por 06.02.2011 / 12:57
fonte
10

Nota do autor

A few years later; I've edited this to more accurately reflect how I feel about the situation. I'm putting more nuance into my answer because I'm learning more about nuance in these situations. It's easy to claim a 'black or white' answer, but we all know it isn't that simple. My answer now reflects that.

Do que você descreveu; o comportamento que você está experimentando não parece ter nada a ver com seu gênero. Isso não quer dizer que você não esteja experimentando nenhum tratamento relacionado a gênero (espero que não esteja), apenas que o que você descreve não parece estar relacionado a gênero.

Quando eu era um líder de equipe, eu tratava todos igualmente. Não há espaço na tecnologia para tratar alguém mal por causa de seu gênero. Eu não sei como lidar com isso se isso está acontecendo com você.

É importante que você confie que o líder da sua equipe trata igualmente homens e mulheres. Se há provas de que ele não é, então o velho ditado se aplica: Mude seu ambiente ou mude seu ambiente.

Por igual, quero dizer que ele trata todos igualmente, sem deferência ao gênero. Se ele está fazendo seu trabalho corretamente, você não deve vê-lo criticar ninguém; e eles não devem vê-lo criticando você. Na frente dos outros, é muito importante para o líder da equipe mostrar confiança, mesmo que ele tenha passado os últimos cinco minutos antes de corrigir o comportamento em particular.

Agora, para os problemas que você levantou:

Você verificou o código que não atendia ao padrão estabelecido por ele, então ele rejeitou sua ramificação. Se eu estivesse no lugar dele, eu não teria feito a mesma coisa da mesma maneira, mas eu me certificaria de que meus subordinados (palavra estranha; porque eu não penso em um líder como 'superior' para as pessoas que eles chumbo, mas com precisão (não adequadamente) descreve a situação) sabe o que é a coisa certa a fazer. Se eles não sabem quais são os padrões, a culpa é minha como líder. Cabe a mim corrigir isso. Nesse caso, você pode ter cometido um erro, mas o simples fato de que isso aconteceu significa que você estava 1) sem saber o que era a coisa certa a fazer ou 2) não foi devidamente orientado. Nem é sua culpa.

Uma das partes mais importantes de ser um programador é perceber que a base de código em que você trabalha deve ser mantida por muitas pessoas diferentes. Quaisquer confusões de variáveis ou outras coisas que diminuam a capacidade de ler o código não são transparentes para o cliente , porque demora mais para corrigir problemas no código que é mais difícil de ler.

Se sua equipe tiver escrito diretrizes de codificação, siga-as. Se não, então deve haver algum tipo de convenção da comunidade para o seu idioma (para .NET e C #, A Microsoft tem um padrão que muitas empresas seguem.

Pergunte ao seu líder de equipe onde as diretrizes de codificação são para que você possa ter certeza de segui-las. Leve dois checkins para suas reuniões, onde dois outros desenvolvedores não seguiram as diretrizes de forma consistente, de modo que, quando ele disser que não há, você pode apontar que outros parecem estar tendo problemas com isso também, e todos se beneficiariam de ter essas diretrizes.

Se ele está te tratando de forma justa, então ele vai ver isso e isso deve estar no topo de sua lista de coisas para fazer. Se ele não está te tratando de forma justa, então você tem munição se continuar acontecendo.

Dizer "eu vou chegar depois" é ruim. Mais tarde nunca acontece. Aproveite o tempo para fazer isso direito. Não há mais tarde na programação.

É difícil quando você é um desenvolvedor júnior. Você se sente pressionado a se apresentar e há muitas pessoas olhando para você, e cada erro cometido está vinculado ao seu nome no controle de origem para sempre.

    
por 06.02.2011 / 04:33
fonte
3

Em nenhum lugar do seu post você menciona como os outros usuários são tratados. Você continua repetindo que "sente" que está sendo "escolhido" porque é "uma mulher".

Eu acho que você está sendo tratado como um programador júnior, independentemente do seu gênero, e você deve ser grato por isso, porque é isso que significa igualdade. Eu também sinto que você está fazendo uma grande confusão sobre pequenas alterações estéticas de código de 5 minutos que você está sendo solicitado a fazer agora, em vez de colocá-las em uma lista de tarefas e nunca se aproximar delas.

Em nenhum lugar do seu post você mencionou que recebeu ordens para fazer essas coisas no fim de semana. Pode ser perfeitamente bom verificar as correções na manhã de segunda-feira.

Seu líder de equipe pode ser um pouco pedante para o meu gosto, mas no seu post não vejo nada de errado com os pedidos dele.

Por favor, pare de jogar o cartão de gênero por nada . Eu sinto que isso é indigno e mina o conceito de igualdade de gênero.

    
por 21.03.2015 / 12:57
fonte
1

I don't feel that rejecting my branch on this basis is useful. Lots of people were working over the weekend, and I had never said that I would be working. Effectively, some people were probably blocked because I didn't have time to make the changes and resubmit. We are working on a project that is very time-sensitive, and it seems to me that it's not helpful to outright reject code based on things that are transparent to the client. I may be wrong, but it seems like these kinds of things should be handled in patch type commits when I have time.

É difícil dizer algo útil como alguém que não viu seu código nem sabe algo sobre o cronograma de seus projetos. Mas, se o seu líder se comportar de forma responsável e fizer um bom trabalho, ele sabe que os outros não foram realmente bloqueados e o sprint não chegará atrasado. Então, não se preocupe com isso. Talvez você superestime o impacto no seu commit. Caso contrário: se o seu projeto é crítico no tempo e passa em todos os testes, seria muito exigente rejeitar o código, que poderia ser corrigido após o lançamento em um piscar de olhos.

Faça o trabalho acertar Faça-o rapidamente

Então, se o seu líder tomou a decisão de rejeitar o seu commit, como um profissional ele deve saber o que ele estava fazendo.

Now, I can see that in some environments, this would be the norm. However, the criticism doesn't seem equally distributed, which is what leads to my next problem. The basis of most of these problems was due to the fact that I was in a codebase that someone else had written and was trying to be minimally invasive. I was mimicking the variable names used elsewhere in the file. When I stated this, I was bluntly told, "Don't mimic others, just do what's right."

Como Junior, é difícil encontrar um caminho para uma base de código de empresas.

Melhor: existem padrões de codificação documentados - e esperamos que você aprenda a lidar com eles.

Normalmente: há padrões de codificação não documentados - e você precisa aprender por meio de tentativa e erro ou devo dizer commit e _rejeitar? Isso é muitas vezes doloroso (como no seu caso). Às vezes isso é perigoso em termos de qualidade de código e pode levar a programação de culto de carga , onde um não só imita a nomeação de variáveis, mas copia e cola estruturas e padrões da base de código de boa fé, tem que ser feito assim. Não faça isso! Não imite a nomenclatura de variável existente.

Siga o código limpo . É uma boa prática e lhe dá uma posição fácil de defender. Se for um código legível, testável e passível de manutenção, você, em sua maioria, ganhou qualquer discussão.

E isso leva a outro (o último) conselho: siga a regra de escoteiros !

Sempre deixe a base de código em um estado melhor do que era. Mesmo que o código em volta com o qual você está trabalhando seja desagradável, faça o seu limpo - e se você tiver tempo, conserte o ambiente.

    
por 21.03.2015 / 09:34
fonte
0

Tome um pouco de tempo para aprender as várias nuances das personalidades de seus colegas de trabalho. Na minha experiência, você pode evitar críticas irracionais, desnecessárias, inconsistentes ou simplesmente inúteis se você contornar as peculiaridades de seus colegas de trabalho.

Por exemplo, alguns colegas de trabalho podem estar de ressaca às segundas-feiras. Eles podem ser muito irritáveis e excessivamente ansiosos para rejeitar certos códigos ou commits. Se você tiver que trabalhar com alguém assim, tente evitar cometer código às segundas-feiras.

Por outro lado, um colega de trabalho de ressaca pode ser muito indiferente para se preocupar com a verbosidade das mensagens de erro ... então a manhã de segunda-feira pode ser a hora perfeita para enviar seu código :-p

As peculiaridades da personalidade no escritório ou no local de trabalho são literalmente infinitas. Espero que você possa aprender quem evitar e quando evitá-los. Também não seja muito duro consigo mesmo :-) Você sempre pode desistir e encontrar outro emprego!

    
por 06.02.2011 / 04:11
fonte
-2

Eu nunca trabalhei em um ambiente onde o código é rejeitado com base no fato de que certas convenções não são seguidas. Se eu estivesse no seu lugar, ficaria tentado a procurar emprego em um lugar onde tenho mais poder para tomar as decisões certas e onde o cliente é o foco principal, não o código.

Não estou dizendo que códigos e padrões limpos não são importantes, mas o cliente e o cronograma do produto não devem sofrer por causa de um erro de ortografia em algo que nenhuma pessoa, cliente ou executivo não técnico jamais fará. veja.

Com isso dito, parece que você pode estar trabalhando em um ambiente em que as expectativas não são claras ou você não entende totalmente os requisitos, por qualquer motivo.

Independentemente da situação, cabe a você assumir o controle e fazer perguntas esclarecedoras. Seja proativo, se você ainda não estiver. Os membros da sua equipe e o líder da equipe provavelmente irão respeitá-lo mais por fazer perguntas para esclarecer as regras para o check-in. Você também pode solicitar uma "revisão pós-ação" na qual você e sua equipe discutem o que você deveria fazer e como pode dizer a diferença, tanto quanto quando tomar certas ações e quando não.

Sugiro dar tempo, já que você é novo, para ver se consegue superar quaisquer obstáculos e resolver esses problemas com experiência, comunicação e aprendizado dos padrões. No entanto, se depois de vários meses a situação não mudou e o ambiente ainda está atormentado pela ambiguidade, pode ser hora de procurar emprego em outra empresa.

Nem toda organização é tão draconiana, e você pode encontrar outros ambientes de trabalho mais adequados aos seus requisitos de personalidade, estilo e comunicação.

    
por 06.02.2011 / 07:02
fonte