Como lidar com o comportamento não profissional dos estagiários?

Não me parece que rir disso seja a abordagem correcta. Eles precisam de aprender que já não estão na escola. Dito isto, penso que também não devem ir muito longe.

Recomendaria que fossem firmes com ele e dissessem algo no sentido de:

A razão pela qual falámos de convenções de nomes é porque elas são muito importantes. Este código precisa de poder ser mantido no futuro. Muitas pessoas por aqui trabalharam muito para chegar onde estão, e podem não apreciar este tipo de piadas. Por favor, abstenha-se de usar este tipo de nomes no futuro, pois pode levar as pessoas a questionar o seu profissionalismo.

Em primeiro lugar, isto parece uma piada que foi colocada em código e que eles bem sabem que não será utilizada para nada ou lida nunca mais. Penso que estás a ler demasiado sobre este incidente. O importante é que lhes falou sobre a convenção de nomes e eles não o ignoraram, eles usaram nomes mais longos e descritivos (embora sarcasticamente).

Depois de ver este vídeo ** Consigo ver que os trabalhadores desejam 3 coisas:**

1. Autonomia
2. Domínio
3. Objectivo

O que lhes está a pedir para fazer não é autónomo, é provavelmente de dificuldade trivial para alguns deles, e não serve de nada aos seus olhos.

Arranje a tarefa, e os trabalhadores seguirão.

alguns exemplos:

1. Aqui está este projecto, trabalhem em conjunto e tenham-no feito por ____, avisem-me se ficarem presos.

2. Sei que isto não parece importante, mas para avaliar as tuas capacidades e atribuir-te trabalho que pensamos que te vai ajudar a crescer, precisamos que termines esta tarefa.

TL;DR* : Oponho-me ao nome do método porque ele (na minha opinião!) exprime desdém pelo chefe e/ou pelas “regras” (aqui: orientações de estilo). No local de trabalho, espero que as pessoas cumpram a regra “amar, mudar, ou deixar”. Neste caso, o estagiário, que parece ser da opinião de que a orientação é desnecessária, deve aceitá-la de qualquer forma; ou manter a discussão sobre ela; ou parar para fazer o que faz. Não colocar o equivalente a alguma mancha na sanita. Não teria tido qualquer objecção contra um nome de método verdadeiramente engraçado e criativo. Se você (a OP) achar o nome do método apenas engraçado e não “mau” como eu acho, então ignore esta resposta por favor.

Como pano de fundo, eu supervisionei alguns estagiários altamente inteligentes e (auto)motivados no passado, e nunca houve uma única vez a questão de se eles se comportariam profissionalmente ou não. Trazer a parvoíce do nível escolar para um local de trabalho como um estagiário está tão fora do aceitável, que eu sugeriria que não brincassem. Para o seu próprio bem e especialmente para o bem deles.

Gostaria de saber como lidar correctamente com esta situação.

Antes de mais nada, esqueça as convenções de codificação. A questão não está relacionada com computadores ou programação.

• Não minta. Não minta palavras, não se ria, porque realmente não é motivo de riso.

• Não se torne pessoal. Não é sobre você o PO, nem sobre a sua relação com eles. É pura e estritamente sobre o comportamento deles.

• Explique as coisas como elas são. Pode absolutamente dizer ao agressor que compreende como ele teve a ideia de fazer o que fez, e que não está pessoalmente zangado com ele ou o que quer que seja (mantenha as emoções fora), mas que está a ver o estágio como uma triagem de quem aceitar mais tarde.

Se deseja transmitir alguma emoção sobre isso, afaste-se da raiva. Pode demonstrar uma ligeira tristeza (e francamente, isso seria exactamente o que eu sentiria) e mostrar-lhes que ficou bastante desapontado.

Ainda assim, o seu desempenho durante o estágio irá afectar as suas hipóteses de serem contratados e situações como esta podem desempenhar um papel mais tarde.

Absolutamente! Não se preocupe com o “pode desempenhar um papel mais tarde”. Comportamentos como este podem, devem e farão com que a sua oportunidade de receber uma oferta após o estágio seja zero. Pode dizer isso da forma que normalmente fala com eles, clara e inequivocamente.

Tente encontrar a causa raiz. Se você descobrir que…

• …eles estão aqui contra a sua livre vontade (talvez os seus pais, ou a sua escola, ou o que quer que seja, os fizeram escolher algum estágio e por acaso escolheram a sua empresa)…
• …eles não estão nada interessados no desenvolvimento de software ao estilo “business”…

…então oferecer-se para abortar o estágio não seria o pior que você poderia fazer. O problema não é que o seu tempo é desperdiçado (de qualquer forma, o tempo que lhe foi atribuído para os supervisionar não piorou as coisas para si), o problema é que o seu tempo é desperdiçado.

Ou devo dizer-lhes algo neste sentido para que se sintam mais motivados a aprender realmente alguma coisa?

Eu diria “todos os humanos podem aprender, mas nenhum humano pode ser ensinado”. Acho que vai achar muito difícil motivar essa pessoa a aprender sobre a utilidade das convenções de codificação, uma vez que eles já demonstraram que não têm qualquer interesse nessas convenções. Pode ensinar aqueles que estão interessados no que tem a dizer; mas se alguém está desinteressado, não há nada que você possa fazer, realmente.

Se você realmente quer ajudar essa pessoa a “ver a luz”, então peça-lhes para tentarem brincar para o seu próprio bem, talvez eles aprendam a apreciar o que você pode oferecer, mais tarde. Os estágios são uma troca de quaisquer serviços limitados que possam oferecer, contra a experiência de trabalhar num local de trabalho real. Se não estão interessados em assimilar a experiência, então não vale a pena. Presumivelmente, a sua empresa não está dependente de ter o seu “poder humano” para algum projecto real.

Todos odiamos fazê-lo, mas, por vezes, só temos de resolver os problemas usando a autoridade. Convocar os estagiários para uma reunião e exigir saber por que razão as convenções de nomeação não foram seguidas.

Expliquei as convenções de nomeação a serem seguidas na nossa reunião anterior. Encontrei vários casos em que as convenções de nomeação não foram seguidas. Por exemplo, convertToMillilitersBecauseIAmUsingSuchCleanCode. Poderia explicar porque é que este nome foi escolhido?

A sua “resposta” é irrelevante, isto deve servir como um “primeiro aviso” suficiente de que ir contra as instruções do seu supervisor (o que presumo que seja) e fazer piadas à sua custa não é aceitável num ambiente profissional. Isso até se enquadra bem num objectivo de estágio, que é mostrar aos alunos como trabalhar num ambiente profissional.

Se continuarem com o seu comportamento infantil, então bem, penso que chegaram à conclusão:

Alguns dos estagiários serão contratados na empresa no futuro, com base no seu desempenho.

Oh, um monte de parafusos, eh?

Pegue algum código de trabalho e faça algo para quebrá-lo deliberadamente. Depois passe-o por um obfuscador que altera todos os nomes de classes, variáveis e métodos para coisas como “a__1318798_” e “xy23_7a963”; ou pior, nomes de variáveis com muitas letras O, letra I, número 0, e caracteres número 1 nelas. Faça a sua atribuição para documentar o que o código está a fazer, e fixe-o.

Isto irá curar essa brincadeira.

Sei que provavelmente não é assim tão importante, mas é a minha primeira vez que ajudo os estagiários e gostaria de saber como lidar adequadamente com esta situação. Mesmo assim, o desempenho deles durante o estágio vai afectar as suas hipóteses de serem contratados e situações como esta podem ter um papel a desempenhar mais tarde. Ou devo dizer-lhes algo nesse sentido para que se sintam mais motivados a aprender alguma coisa…

Quando se depararem com tais tolices durante as revisões de código, riam-se, parem a revisão de código e digam-lhes para voltarem assim que retirarem o humor.

Presumo que não sejam estúpidos e já saibam que o nome demasiado longo é inapropriado, mesmo que se riam. Se não, explique porquê uma vez.

Esperemos que esteja a acompanhar o seu desempenho e que consiga perceber a frequência com que isto acontece.

Eu teria um coração a coração com cada um deles, em privado, num tom franco e sério mas não severo, algo como isto:

“Interno, eu vi o nome do seu método de piada. Compreendo porque o fizeste, mas eu próprio não achei que fosse assim tão engraçado. Por isso ocorre-me perguntar-te, o que estás aqui a fazer? O que gostaria de fazer?”

Se os estagiários dizem que ele só está lá para brincar, então fale com a gerência para terminar o seu estágio. Está a perder o seu tempo.

Se ele diz que está lá para aprender, então diga algo como isto:

“Eu percebo que pode ser difícil levar a sério algo que você sabe que não será usado na produção. Mas por favor, perceba que não está apenas a levar o seu tempo, está também a levar o meu tempo. O estágio que lhe foi proporcionado pela empresa é, na sua essência, uma espécie de entrevista. A única coisa que nos impede de ser uma verdadeira caridade é a esperança de encontrar bons candidatos. Por isso vale o meu tempo, mas só se estiveres a falar a sério”

“Se não consegues levar isto a sério e trabalhar como se estivesses a escrever um código de produção importante, como é que te podemos avaliar devidamente e decidir se te vamos oferecer um emprego? E mesmo que não lhe ofereçamos um emprego, se mesmo assim não o leva a sério, de que outra forma irá adquirir estas competências e ser capaz de praticar sob a direcção valiosa de alguém com mais experiência do que você?”

“Se eu fosse a si, faria o meu melhor para seguir o exemplo das pessoas que o orientam, que estão, de alguma forma caridosamente, a tirar tempo não rentável do seu trabalho para investir em si. Considere que irá beneficiar deste estágio, quer o contratemos ou não! Pessoalmente, agradecia que levasse isto um pouco mais a sério. Faça-o por si! Se não o queres fazer por ti, fá-lo por respeito, ou apenas por gratidão, pelo tempo que tirei do meu trabalho produtivo normal para investir em ti e no teu futuro”

É provavelmente apropriado abordar um pouco directamente o comportamento em si, e porque é que estás a fazer disto um grande negócio. Pode considerar algo como isto:

“Pelo que vale, este tipo de acção é considerado desrespeito, ou mesmo zombaria, no mundo empresarial. Tenho a certeza que não foi isso que quis dizer [mesmo que não acredite nisto, diga], mas por favor, siga as minhas indicações no futuro sem colocar coisas maliciosas no código”

Dar o “fora” do estagiário dizendo “oh, sim, não quis desrespeitar” deixa-o salvar a face e reparar a relação da forma mais indolor possível. Não há necessidade de extrair uma confissão de que ele o fez com desrespeito ou para obter um enorme pedido de desculpas. A questão aqui não é o power-over mas sim o estágio de sucesso.

Se depois de tudo isto, o comportamento negativo continuar, pode abordá-lo de forma mais frontal. Não há razão para não poder dar um objectivo de desempenho a um estagiário, tal como faria a um funcionário problemático, ou usar qualquer outra estratégia que usaria com um funcionário normal. Mas lembre-se que os estagiários NÃO são experientes no mundo do trabalho e que lhes deve ser dada uma ou duas pausas enquanto você os acostumar gentilmente, mas com firmeza, aos padrões do mundo do trabalho profissional.

Os estagiários em questão estão a desperdiçar o seu tempo e paciência. O seu tempo e paciência são caros e os recursos limitados para a empresa e os estagiários que lucram com o investimento da empresa neles, um investimento que é limitado pelos recursos da empresa.

A sua vontade de desperdiçar os recursos da empresa é uma parte relevante da sua avaliação de desempenho e pode levar ao término prematuro do seu estágio, a fim de gastar os recursos da empresa apenas com os estagiários realmente interessados em aprender a ser uma parte valiosa, responsável e fiável do local de trabalho a quem podem ser confiadas tanto as tarefas como as instruções.

Eu diria isto a todos os estagiários, mostrando algum código de exemplo, não mencionando o seu autor, não gastando mais de 2 minutos com ele e, se o código for posteriormente fixado e incidentes similares não se repetirem, não o mencione novamente.

Se o tiro de aviso não for dado, o passo seguinte é uma conversa em aberto apenas com o estagiário em questão e possivelmente com um superior seu (certifique-se de que ele está no seu barco no entanto). Depois tem de decidir se deve aos outros estagiários remover aquele que está a sabotar as suas hipóteses de um estágio de sucesso.

Parece que há aqui duas questões principais: 1) Estão a ser irreverentes e 2) O nome da função ainda é uma porcaria, embora agora seja mais longo.

Reprimindo-os por brincadeira provavelmente não os vai fazer respeitar mais a sua autoridade, por isso eu concentraria-me na questão como se fosse qualquer outra função mal nomeada. Eu não me faria necessariamente de parvo e fingir que não percebo que é uma piada, mas questionava-os sobre o porquê de terem escolhido o nome que escolheram:

“Parece que há algumas palavras supérfluas neste nome de função que não ajudam a explicar o que a função faz”

Dessa forma, é uma oportunidade de aprendizagem para eles sobre o que faz um bom nome de função e não os estás a confrontar directamente. Como bónus adicional, eles podem confessar que estavam apenas a brincar e podem sentir alguma vergonha por desperdiçar o tempo de todos.

Se tiver de lembrar às pessoas que é o responsável, então nunca foi.

Seria melhor conduzir um passeio pelo código onde o programador tem de explicar o seu código aos responsáveis.

1. Isto instila a responsabilidade pessoal pelo resultado do projecto
2. Fornece um feedback profissional imediato
3. Dá ao programador um sentido de urgência para completar o projecto

Utilize a sua liderança como parte da equipa para manter os padrões da sua organização. Depois, ajude os funcionários mais jovens a cumprir esses padrões e evite o constrangimento de apresentar um trabalho abaixo dos padrões.

Basta dizer ao agressor (pessoalmente ou via e-mail) que o estágio não é um lugar apropriado para tais brincadeiras e que ele tem que levar a sério se quiser iniciar uma carreira.

Peça-lhes para corrigir o código, ou (se quiser mostrar alguma autoridade) apenas reverter as suas alterações no controle de versões.

Obviamente, é preciso fazê-los parar, mas simplesmente dizer-lhes para não demonstrarem porquê.

Eu sei que a directriz de 80 caracteres por linha não é uma regra difícil e rápida, de forma alguma, mas tentar mantê-la é uma boa prática, por isso ter um nome de variável de 48 caracteres é bastante estúpido.

Eu sugeria dizer-lhes para tentarem seguir esta directriz a partir de agora, mas também não lhes permitir alterar os nomes de variáveis que escolheram. É uma espécie de “você fez a sua cama, agora deite-se nela”.

Você vai tentar martelar uma nova prática na cabeça deles (assumindo que eles ainda não estão mantendo linhas curtas), estagiários que não entendem porque nomes longos de variáveis são ruins estão prestes a descobrir, e os estagiários “espertos” vão descobrir logo que não estão sendo tão espertos quanto eles pensavam.

É óbvio para os estagiários mais experientes porque convertToMillilitersBecauseIAmUsingSuchCleanCode é particularmente mau, mas em vez de lhes dizer “isso é mau”, forçá-los a descobrir o porquê. Aposto que vão encontrar muito menos nomes verbosos e, com sorte, menos tentativas futuras de serem snarky também.

Isto não tem de ser “One Size Fits All”. ** All Sizes Fit Some:**

Cada uma das abordagens propostas pode funcionar muito bem, e pode ser a melhor abordagem, dependendo das circunstâncias. Aqui está a minha resposta a cada uma das abordagens perguntadas sobre:

Devo reagir por

• rir (“Yeah, it’s funny but please remove it”)

Esta é uma óptima ideia quando: Você tem uma excelente relação com estes colegas de trabalho, que se tornaram bons amigos de

• apenas pedindo educadamente para o remover

Esta é uma óptima ideia quando: Quer ser directo para que não haja mal-entendidos

• dizer que não gosto quando alguém me faz perder tempo e deve levar a revisão do código mais a sério

Esta é uma óptima ideia quando: Deseja comunicar o incómodo e manter uma abordagem autoritária.

(estou inclinado a pensar que pode conseguir combinar todas essas abordagens de uma forma não ofensiva, educada e engraçada que comunique um pouco de incómodo real. “Este tipo de coisa tem de parar, porque só me faz ir [mock-scream] ” pode ser apenas uma forma humorística de o conseguir.)

Pessoalmente, gosto do método amigável. Sou um crente nessa forma de fazer as coisas. No entanto, admito que há alturas em que tais abordagens são menos eficazes.

** Mas o que é melhor?** A sua pergunta básica é: “Como devo reagir a isto?”

Basicamente, o que se resume a esta pergunta é o mesmo que dizer: “Eu preciso de ir a algum lado. Devo usar um uniciclo, um pogostick, uma bicicleta ou um autocarro?”

Qualquer uma destas abordagens de transporte pode ser a melhor. Da mesma forma, para responder à questão de como deve reagir: a sua melhor reacção pode não ser a minha melhor reacção.

Esta é uma razão fundamental pela qual, embora as diferentes respostas pareçam concordar que o comportamento dos estagiários não é adequado aos resultados da produção, as diferentes respostas parecem favorecer abordagens diferentes. Como referido, podemos não ter uma única abordagem “tamanho único” que funcione universalmente melhor para todos.

Estamos a lidar com pessoas aqui, por isso o que funciona melhor em alguns cenários pode não funcionar tão bem noutros cenários. Um dos factores chave é você. Consegues ser austero sem queimar pontes? Consegue ser amigo deles, sendo leve, mas assegurando a conformidade e inspiração suficientes para obter os resultados desejados? O que funciona melhor para mim pode funcionar de forma atroz e terrível para si. Em última análise, você precisa fazer uma chamada de julgamento sobre qual dessas abordagens deve tomar.

** Ensino flexível:** Não se comprometa com apenas uma abordagem.

Basta escolher o método com o qual você se sente mais confortável. Certifique-se de que não exagera (mau humor/ofensivo, ou criar um ambiente desconfortavelmente ameaçador num esforço para ser rigoroso).

Não importa qual das suas excelentes sugestões decide avançar, fique atento aos resultados.

É muito possível que faça uma chamada de julgamento que não funcione como esperado. Desde que não tenha causado problemas de maior, isto pode ser muito recuperável, se for tratado de forma positiva e rápida. Essa é uma das razões pelas quais não deve preocupar-se muito em tentar tomar a decisão mais perfeita. Se as coisas não correrem bem, a sua situação pode resolver-se bem. As pessoas são diferentes, e a aprendizagem pode ser imprevisível, e não é preciso vergonha nenhuma numa primeira abordagem que precise de ser modificada. Desde que se recupere rapidamente, isto pode não ser um problema.

A chave é fazer mudanças assim que começar a encontrar resultados indesejáveis. Espere precisar de adaptar rapidamente. Quando alguma abordagem não estiver a funcionar, esteja muito preparado para modificar rapidamente a abordagem, ou mesmo atirá-la pela janela fora. Se o que está a fazer não está a funcionar, determine se é provável que esteja à beira de uma ruptura, ou se precisa de tentar algo diferente. (Obter feedback irá ajudar nesta determinação.) Se precisar de tentar outra coisa, então tente. Continue a fazer isso até obter resultados de trabalho.

Desde que aja rapidamente (antes que sentimentos de longo prazo como o amargo comecem a tomar conta), pequenas imperfeições podem ser facilmente eliminadas como insignificantes em comparação com os resultados positivos que obtém no geral. (Certifique-se apenas que se as coisas correrem imperfeitas, os problemas são menores. Os erros maiores podem ser um pouco mais difíceis de esquecer. Por exemplo, a tentativa de humor pode ser perigosa)

Por exemplo, se você achar que eles começam a odiá-lo, temendo o ambiente, etc., certifique-se de esclarecer qualquer mal-entendido. Assegura-os de que estás do lado deles. Encoraje o comportamento desejado, etc.

Há dois anos atrás, eu estava numa posição semelhante à dos estagiários da vossa empresa. Posso imaginar um cenário em que eu teria feito algo semelhante. Penso que alguns estagiários têm um problema com a sua autoridade; ser pedante e não profissional. Isto deve-se principalmente a uma falta de respeito da minha geração para com os mais velhos e os que ocupam posições mais elevadas. Eu tentaria os seguintes métodos para resolver a situação.

• Ganhar o respeito dos estagiários, superando o “líder”, “alfa”.

• Usar o nome da função pedante como lição para todos, comprimento ideal do nome da função: zona do goldilock.

• Aponte uma falha na função “convertToMillilitersBecauseIAmUsingSuchCleanCode” e sugira uma renomeação para algo apropriado(/demeaning)

• Não note, ignore o nome da função; concentre o seu tempo nos indivíduos que querem aprender.

Eu notaria os nomes dos estagiários não profissionais como precaução.

Devo reagir por

• a rir (“Sim, é engraçado mas por favor remova-o”)
• apenas pedindo educadamente para remover
• dizendo que não gosto quando alguém perde o meu tempo e que deve levar a revisão do código mais a sério

E que tal “ *Entendendo porque fizeram isto? *

Sempre que alguém faz algo que você não espera ou deseja que faça, você pode ou reagir a isso para que ele faça o que você quer ou pode tentar entender porque ele fez exatamente isso.

Pode ser útil entender o porquê. Se eles são brincalhões por natureza, mas não estão a conseguir transmitir as suas frustrações sobre algo, é assim que alguém pode canalizá-lo. Todos podemos concordar que esta não é uma forma positiva de canalizar.

** Uma abordagem alternativa**

Então o que é uma forma positiva de canalizar a frustração e a ludicidade? Já trabalhei em empresas onde as pessoas por vezes faziam projectos 10% do tempo, como programar um microcontrolador para levar uma fotografia com um dslr. Não só tiveram a liberdade de o fazer, como também lhes foi dada a responsabilidade de transformar isso num produto que pode ser enviado. Passou de uma hackathon de um dia para exemplos de código que agora são publicados no site da empresa. As pessoas podem pegar nesse exemplo e transformá-lo num controlo remoto para câmaras de alto mar que podem ser ligadas com um clique de um botão.

O meu ponto de vista é que partidas como esta _ podem ser_ indicação de potencial não explorado. Se você quer estagiários que estejam de acordo com o padrão que você tem na sua empresa, esse potencial não é para você e, nesse caso, considere deixá-los ir. No entanto, se você vê o valor de agitar as coisas, faça com que esses estagiários criem algo útil com suas brincadeiras. Em última análise, a decisão é sua. Quem queres que sejam estes estagiários?

Como profissional há quase 30 anos, eu diria que as respostas de alto nível têm, na sua maioria, razão.

No entanto, como profissional desenvolvedor de software há quase 30 anos, direi que as directrizes de codificação são quase sempre sobre-prescritivas*. Pior ainda, muitas vezes isto é apreendido por pessoas mais preocupadas com o seu Authoritah do que com a produção de código legível. Este tipo de comportamento passivo-agressivo dos engenheiros juniores é exactamente o que normalmente se vê quando isso acontece.

Colocar coisas parvas nos comentários de código, ou mesmo na atribuição de nomes identificadores, é realmente uma tradição consagrada entre os programadores de software. Aqui está um exemplo de nomes de protesto induzidos por padrões de meus próprios dias de júnior (que tiveram 48 votos contra).

Se há um problema aqui, deve ser que há problemas de legibilidade/manutenibilidade com seu código fonte no seu ambiente. Não estou a dizer que as principais respostas aqui estão erradas. Não estão. Mas quando vê este tipo de comportamento de vários engenheiros juniores, então depois de limpar os corpos deve realmente verificar se pode haver uma razão subjacente para os seus canários continuarem a morrer.

O objectivo final tem de ser a qualidade do código. As directrizes de codificação devem ser apenas a sua ferramenta para os ajudar a chegar lá, construídas por programadores para programadores, e não algum tipo de programa autoritário sobre como escrever programas.

Parece que você tem um bom exemplo para lhes mostrar porque é que a utilização deste tipo de convenção de codificação é inadequada, mesmo para pequenos projectos como este.

** Você** viu.

Mesmo que o seu projecto não esteja a ser utilizado directamente pela empresa, destina-se a actuar como uma avaliação das suas competências e, em parte, como uma experiência de aprendizagem para estes estagiários que procuram entrar na sua empresa.

Eu não seria muito duro com eles - afinal, isto é apenas um teste para eles - mas gostaria de salientar que, no futuro, tais práticas de codificação podem colocá-los em problemas, especialmente se o seu próximo chefe não for tão paciente com eles como você.

Primeiro que tudo, não acho que isto seja mau. Eles colocam uma piada no código sobre um tópico (convenções de nomes) que provavelmente não compreendem completamente. Colocar algumas piadas internas no código não é algo novo. Também podem considerar o código uma “folha interna”.

Eu também discordo da opinião de que eles desperdiçam o seu tempo com isto. Se se comprometem apenas a renomear um método, então sim, estão a desperdiçar o seu tempo, e a alteração deve ser rejeitada. Mas se precisassem de um novo método e escolhessem um nome pobre, o tempo a rever seria semelhante com qualquer um dos nomes. Não sei se está a rever pré-compromisso ou pós-compromisso, mas quando alguém quer ter o código aprovado/mergido, o que está a fazer é, na verdade, trabalhar contra si próprio, uma vez que está simplesmente a adicionar viagens de ida e volta para que o código seja efectivamente aceite.

Também é trivial para si classificar negativamente com nomes errados, sem realmente olhar para o que o código faz. A questão é que se sente aborrecido com esses nomes.

Agora, pegando na pergunta real sobre o que fazer, recomendo que levantem alguns problemas com as convenções de nomes e lhes peça para reverem o trabalho da semana passada para verem se têm usado nomes próprios e pensarem se o compreenderiam facilmente dentro de alguns anos / se viessem de novo a esse projecto. Peça-lhes que preparem um breve relatório sobre as funções que acrescentaram nessa semana e em breve o justifiquem.

Idealmente, isso seria sobre uma linha por função, por exemplo,

convertGalToml: Converte galões em mililitros. O caso Camel não foi usado na abreviatura milliliters para evitar ser confundido com megaliters.

Espera-se que ao rever o código, eles possam notar novos problemas ou pensar num nome melhor, por exemplo, renomear convertGalToml para convertGal2ml.

Suspeito que o seu palhaço vai perceber o ponto e silenciosamente renomeá-lo.

O ponto é, nomes de funções são documentação. Embora seja um público mais técnico do que, por exemplo, o manual do utilizador, eles devem estar à vontade para justificar a sua escolha em frente dos seus pares.

Começando por assumir a boa fé, o meu instinto diz-me que os estagiários fizeram isto porque realmente não conseguem ver nenhum problema com nomes como convert. Aposto uma pequena soma de dinheiro que os nomes sarcásticos não vêm do desejo de serem rebeldes, mas da frustração de não saberem inventar um nome melhor, apenas um nome mais longo. E esse tipo de nome é o que lhes disseste, certo? Curto mau, longo bom.

Se quiser que estes indivíduos melhorem, basta discutir, na reunião diária, exactamente porque convert é um nome pobre e convertInchesToCentimeters é um nome melhor. Se tiver um exemplo da sua experiência de má escolha de nomes que cause problemas, isso irá ajudá-los. Esse “porquê” permitir-lhes-á escolher bons nomes a partir de agora - quer esses bons nomes sejam longos ou curtos.

Diga-lhes também que não há problema em pedir ajuda a si ou aos seus pares ou consultá-los dentro do razoável, que este não é um teste em que todos têm de trabalhar sozinhos, é uma colaboração. (Espero que isto seja verdade!) Talvez isso lhes permita fazer perguntas e falar uns com os outros, e resolver as frustrações mais cedo, em vez de esperar que coisas passivas-agressivas como esta apareçam na revisão do código.

Só se esse comportamento continuar é que eu acharia necessário explicar, sim, isto não é uma aplicação real, mas este exercício e as orientações de estilo devem ser levados a sério por múltiplas razões:

• Vale a pena gastar o meu tempo convosco neste esforço, quando eu poderia estar a trabalhar em candidaturas “reais”, por isso façam o vosso melhor esforço também
• Este exercício prepara-vos para trabalhar num projecto real que é sério e no qual devem seguir directrizes de estilo
• Este exercício permite-nos decidir qual de vós, se é que existe algum, deve estender as ofertas de emprego para depois de concluído o vosso estágio

Embora não esteja exactamente errado, penso que acusá-los de desrespeito, etc. neste momento, é provável que silencia o comportamento, mas também não os ajudará a compreender porque precisam de nomes melhores ou como inventar nomes melhores. Se enveredar por este caminho, poderá encontrá-los apenas a inventar nomes maus mais longos e a evitar o seu olhar de aço.

Você não é o gerente deles, nem sequer importa se os entrevista ou não. Você é um engenheiro como eu,

Então você sabe o que fazer, Fale com o seu gerente e depois sugira uma revisão de código. Depois aconselhe-os a não escreverem códigos desse tipo através de um sistema como o de um colaborador de códigos. Nem sequer precisa de lhes enviar um e-mail ou interagir com eles ou levar estas coisas a peito. Introduza um sistema de classificação com base nessa revisão de código. Não tente controlá-los, nem ser o seu gestor, nem tentar a gestão de pessoas. Isso não é da sua conta.

Fale com o seu gestor e mantenha esse privilégio de rejeitar ou aprovar compromissos após uma revisão para si. Suponha que cada estagiário tem uma pontuação inicial de 10 pontos, e deve ganhar 100 pontos através da sua classificação, e se quiser realmente juntar-se à sua equipa, estará motivado a pontuar. Não perder nenhum ponto.

Se eu fosse um estagiário e trabalhasse sob a tua direcção e fosses apenas um engenheiro sénior, até eu detesto que faças a minha gestão de pessoal. NÃO é o teu trabalho.

Parece-me que foste longe demais e que estás fora de controlo. Aprenda essa lição como engenheiro. Você é um engenheiro, não o seu gerente para as pessoas que as gerem.

Embora o comportamento dos estagiários possa ser pouco profissional, é também pouco profissional que a direcção não considere que eles possam estar errados. É evidente que convert pode ser demasiado ambíguo em muitos contextos, mas convertGallonsToMilliliters é _ de longe demasiado longo_ para um nome identificador. Em vez de impor requisitos de verbosidade de nomes arbitrários em todos os contextos, deve desafiar os seus estagiários a justificar quando um nome que eles escolhem é realmente ambíguo (o que eles não serão capazes de fazer) e a apresentar algo razoável que melhore a legibilidade do programa em vez de o impedir.

Isto parece-me realmente um caso em que o padrão comum de “porque é que os meus subordinados não me respeitam?” é realmente uma questão de “e a minha própria atitude está a fazer com que as pessoas não respeitem a minha posição?