O fundador respondeu que eles estão exagerando e que ele tem uma confiança absoluta nas habilidades do novo líder, com base no seu CV e na entrevista, que é exatamente por isso que ele atribuiu a esta pessoa o papel de um desenvolvedor líder em primeiro lugar.

O líder falou. Não é um governo nem um partido político. Não pode expulsar ninguém ou liderar uma insurreição.

Se não está disposto a lidar com isso, tem realmente uma opção. Podem juntar-se e ameaçar desistir a menos que algo aconteça.

Estou a dizer que podem, não devem. Há uma hipótese extraordinariamente boa de que isto não acabe bem. Basicamente estás a tentar colocar-te à frente do chefe que tomou a sua decisão e os responsáveis não gostam que sejam desafiados.

Suponho que a coisa “correcta” a dizer-te é encontrar técnicas que o encorajem a ver a tua maneira de pensar. Mas eu não vou fazer isso. Eu sou um desenvolvedor sénior de 30 anos e posso dizer-lhe que me tornei, em grande parte, um homem de ideias. Não, não sou um ludita como este tipo e, sim, aceito sugestões. Adopto novas tecnologias e assim por diante. Este tipo está claramente errado em muitas coisas. No entanto, o que vos posso dizer é que, quando estou decidido a fazer algo e estou convencido de que estou a tomar a decisão certa, mantenho-a. Não aceito bem ameaças e a coerção ou manipulação é ainda pior.

O que quero dizer é que ele está convencido de que é o “Programador Jesus” (o que é uma triste atitude infeliz) e que nunca o vai mudar, não nesta fase da sua carreira. Ele está convencido de que tem razão e pensa que a sua experiência o apoia. Infelizmente, o chefe também acha.

Honestamente, provavelmente não vale a pena o stress de si e da sua equipa. Eu sugeria que cada um de vocês começasse a procurar um novo emprego e partisse quando encontrasse um. Quando uma pessoa sai, certifique-se de que ela diz ao chefe porquê. Eventualmente, ele poderá perceber a situação. Mesmo assim, não é garantia.

RUN A sério, não sei porque é que alguém quereria estar lá. Pergunte a si mesmo, há alguma coisa no que nos disse que não soletra uma eventual desgraça para o produto? Tenho a certeza que sabes isso. Questiono a inteligência básica do fundador, já agora. Os desenvolvedores geralmente fazem péssimos gerentes de projetos/programas. É um conjunto de competências separado e eles precisam de se equilibrar uns aos outros. É como dizer “não precisamos de testadores separados, os testes dos desenvolvedores funcionam muito bem”. Ambos são receitas para o desastre. Boa sorte. Estou a falar a sério.

A descrição da situação por parte do PO é provavelmente unilateral. Tudo bem.

Sou um promotor envelhecido (~54 yo) trazido para uma empresa para não governar, mas para proporcionar alguma experiência. (O chefe de TI disse mesmo “cabelo grisalho”, rs.) O pessoal do dev era far mais adepto, no geral, do que qualquer equipa com quem eu tinha trabalhado anteriormente. Ensinaram-me muito, sobretudo sobre humildade! Mas encontrámos lugares onde a sua feitiçaria tecnológica não resolvia os problemas e em alguns casos escondia esses problemas, acabando por piorá-los. Foi aqui que eu pude realmente contribuir.

A sua liderança soa severamente autocrática. Parece que lhe foi dado um mandato pelo proprietário. O proprietário está descontente com o pessoal do Dev e trouxe este tipo “cabeça dura, sem disparates” para melhorar a velocidade de entrega.

Primeiro, olhem para o vosso pessoal. Você tem fracos - desenvolvedores que não “vêem a Matrix”? Se sim, encontre-lhes novas posições dentro da empresa ou dê-lhes uma boa referência para um empregador que precisa das suas capacidades únicas.

Ele odeia IDEs

Eu conheço alguns que odeiam. Faz-me revirar os olhos, mas em última análise não me interessa. Se as pessoas produzem usando vi, então tudo bem. Eu adoro os meus IDEs.

Ele não refactoriza o código e não se importa com o estilo (que é inconsistente com o seu próprio código)

Bandeira vermelha na primeira parte. Ele é um copy-paster? Eu também sou culpado por não me importar com o estilo, mas isso é porque uso o meu IDE para tornar instantaneamente o meu código Python PEP8 compatível. Mas ele não usa um IDE…

Como nota lateral, o estilo foi previamente verificado por uma construção nocturna, que começou a falhar desde a chegada do novo chumbo.

Ele rejeita a ideia de uma construção nocturna, bem como testes automatizados. Segundo ele, “qualquer desenvolvedor profissional testa o seu código de qualquer maneira à mão, portanto não há razão para perder tempo escrevendo testes automatizados”. A construção nocturna é também, segundo ele, uma perda de tempo.

Isto também desencadeia uma bandeira vermelha, mas por diferentes razões do que se poderia esperar. Antes deste tipo ser contratado, quantas vezes foi dito ao proprietário que não podia fazer X (dar uma demonstração, usar o sistema, etc.) porque a construção nocturna falhou? E se o dono perceber que a construção nocturna é o problema? O que acha que ele diria ao líder para fazer?

Mas eu tenho preocupações com a atitude do líder; testes automatizados são incríveis. Como antes, o chefe pode não compreender o valor dos testes, mas ele certamente sabe que Y% dos pagamentos do pessoal do Dev estão a ser pagos por eles. Quando cheguei à minha empresa actual, a “máfia de cobertura de 100% dos testes” tinha tomado conta do pessoal do dev e tinha feito um aumento dos custos. Uma maçã má mais tarde e o pessoal do dev estava novamente a ronronar.

Ele pensa que o controlo de versões é praticamente inútil…

Esta é uma bandeira vermelha da mais alta ordem. Ele está tão errado quanto possível. Ele está a ser irresponsável com o dinheiro do dono.

Ele sobrestima a importância da optimização de código.

Na altura, a optimização de código podia fazer a diferença. Agora as máquinas são tão rápidas que é menos importante. Em vez disso, agora precisamos de nos preocupar com a performance da base de dados e com o rendimento da rede. Mas o seu hábito de “optimização de código” é difícil de quebrar, confie em mim. Tenho de não me fazer pré-optimizar. Pelo menos o seu comportamento, neste caso, não é destrutivo, excepto pelo tempo que leva. (Você tem números para o seu “metade do seu tempo” ou esta é uma hiperbole? Se está a criticar o seu supervisor, não pode ser permitida nenhuma hipérbole. Deve ser patologicamente objectivo.)

Ele escreve todos os SQL à mão e rejeita a ideia de um ORM.

Culpado! Não compreendo o medo que as pessoas têm de SQL. Eu não entendo enterrar SQL, que é drop-dead simples, sob camadas de ORM que ofuscam. Não o posso ajudar aqui :-D Mas por favor, deite todo o seu SQL num só sítio - não distribua tudo pelo seu código.

e dois dos cinco programadores nunca usaram SQL antes.

Isso é inaceitável. Isto é 2016. Eles precisam de se aperfeiçoar.

Ele rejeita frameworks e bibliotecas de terceiros, considerando que é muito mais fácil escrever coisas do zero.

Ele não podia estar mais errado. Duvido que a sua empresa seja tão especial que as suas utilidades precisem de ser escritas internamente. Tínhamos alguns programadores que abraçariam ferramentas de terceiros - até que eles fizessem algo de uma forma que o dev não gostasse. Era uma desculpa para deitar fora a ferramenta e escrever as suas próprias. Isto só aumentava a carga sobre o pessoal do dev, atrasando-os ainda mais. Este código inútil é caro para escrever, testar, depurar e manter. Gastamos tanto dinheiro para -zero benefício. Estes programadores já se foram.

Ele decidiu abandonar todas as bibliotecas e frameworks JavaScript excepto jQuery, alegando que quando começou a programar em JavaScript há quinze anos atrás, não havia frameworks, e a vida era muito mais fácil.

Este não é um corte tão claro. A razão é que a vida era muito mais fácil há 15 anos atrás é que o pedido da empresa era muito mais simples. Foi daí que surgiu o problema. A web foi inventada como um sistema em lote (preencher um formulário, enviá-lo, obter uma resposta, repetir) e agora estamos a tentar escrever aplicações web que se comportem como aplicações desktop. A sua observação está certa, agora as coisas estão difíceis. Mas ele não percebe porquê. A complexidade da ferramenta é uma resposta a uma pergunta mais complicada de negócios. Assim, ele faz más escolhas.

Estamos a usar o AngularJS e parece ser decente. Como todas as ferramentas poderosas, pode ser usado para o bem ou para o mal.

Ele pensa que os dispositivos móveis (incluindo comprimidos) são apenas um hype, por isso não há razão para perder tempo precioso para garantir a compatibilidade do site com esses dispositivos e para fazer um design responsivo. O produto é uma aplicação web pública que não se espera muito dos dispositivos móveis.

Ele está novamente errado. Eles não são hype. Eles estão aqui para ficar porque são úteis. MAS o negócio não precisa disso. Não desenvolva coisas de que não precisa. É caro.

O design reactivo, no entanto, pode ser muito interessante de ter para esta aplicação,…

É assim tão interessante que você pagaria pessoalmente pelo desenvolvimento? Se isto é uma boa ideia, deve poder vender a ideia ao proprietário. Caso contrário, não gaste um centavo com ela.

Ele pede à equipa para parar de usar a internet (especialmente o StackOverflow) e confiar nos seus cérebros, na documentação offline (eu nem sabia que a Microsoft ainda vendia CDs MSDN!) e nos livros.

Ele está errado. A internet é óptima para isto. Se o pessoal do dev está a copiar do Stackoverflow sem perceber como o código funciona, então também estão errados. Há tempo para formação e melhoria pessoal no calendário de desenvolvimento? É difícil não copiar colar roboticamente quando se está sempre debaixo da arma.

Embora eu tenha informação limitada, há muitos problemas aqui. Parece que o dono não recebeu o código que está a pagar tão rapidamente como esperava. Parece que ele já ouviu muitas desculpas sobre coisas que não lhe interessam; ele está concentrado no resultado. Se estou certo, tem uma ferida auto-infligida, e reabriu-a mais do que uma vez. Este Lead é a solução do proprietário para o problema que o pessoal do dev tem colocado, e dada a sua informação limitada, é compreensível.

Também aposto que está a gerir uma loja não ágil e que tem uma má definição de requisitos que muda à medida que o vento sopra. Não existe uma camada de isolamento entre o pessoal do dev e o proprietário. Excepto para este chumbo.

Agora, o que pode fazer?

1) Treinar o chumbo que a utilização de testes automatizados e gestão de código é o caminho a seguir. Pode levar tempo para ganhar credibilidade com ele - o proprietário provavelmente já lhe disse que o pessoal está com defeito. Veja se consegue evitar que ele faça mandatos de varredura como “apagar toda aquela porcaria inútil de testes e redireccionar o servidor SVN”. Isto dar-lhe-á tempo para mostrar valor.

2) Continue a utilizar a gestão de código a nível pessoal. Pelo menos assim poderá recuperar dos seus próprios erros. Não lhe diga que está a fazer isto, embora também não lhe minta.

3) Continue os testes automáticos (testes unitários, se nada mais) a um nível pessoal. Como antes, não o mencione mas não o esconda.

4) Trabalhe com o Chefe para determinar quais são os problemas realmente detectados. Tenha a mente aberta; aposto que existem problemas reais com o pessoal. Trabalhe com o Chefe de Fila para abordar os problemas, não os sintomas.

5) Discuta com o Chefe de Fila vários tópicos de desenvolvimento, tais como os benefícios da cascata e a agilidade. Nenhum dos dois é perfeito. Fazer-lhe perguntas como, “Em que circunstâncias valeria a pena fazer testes automatizados”? Se ele der uma resposta duvidosa, pergunte-lhe como empresas como a Google conseguiram prosperar apesar disso.

Então você pode ver que eu sou todo a favor de envolver o Líder e ver onde está a sua cabeça. Construir confiança. Chegue a acordo sobre questões versus sintomas. Isto nem sempre é fácil, especialmente quando se sente que ele é como o Godzilla e está a destruir o seu trabalho.

Há uma hipótese de ele não se comprometer. Ele vai esmagar os testes automáticos. A gestão de códigos é para pessoas descuidadas. My Way ou a auto-estrada.

Se chegou a este ponto, no entanto, será altura de partir. Trabalhar numa loja sem ferramentas, e refiro-me a software e ferramentas de engenharia de software - não constrói o seu currículo. Você vai começar a apodrecer da mesma forma que o Chumbo apodreceu. Nesse caso, siga em frente.

vinte e cinco anos em TI […] mudar a sua atitude

Não vai funcionar, desculpe.

O seu verdadeiro problema não é o desenvolvedor líder incompetente. Esse problema é insignificante em comparação com o problema real que descreve:

O seu fundador confia mais num estranho incompetente* do que nos seus actuais empregados.

Tem de descobrir como é que a equipa perdeu a sua confiança e como a reconquistar. Isto teria sido mais fácil se tivesse sido feito antes de o desconhecido ser contratado. Agora isto é difícil, porque qualquer bom trabalho será atribuído à nova equipa líder, e qualquer mau trabalho será atribuído a todos vocês - por isso não o podem resolver trabalhando mais arduamente.

Há apenas duas coisas em que consigo pensar, para melhorar a situação neste trabalho:

1. Encontrar um mediador. Existem vários fundadores, ou algo parecido com membros da administração?
2. Talvez a questão da confiança seja uma questão de visibilidade. Nesse caso, qualquer coisa que ajude a visibilidade ajuda-o. Por exemplo, faça demonstrações de sprint suficientemente excitantes e interessantes para que o fundador realmente assista e aprenda sobre o estado e progresso da equipa.

\ *Embora a maioria dos pontos levantados pelo PO não torne necessariamente o estranho incompetente, a sua abordagem ao Controlo de Versão e Integração Contínua numa equipa de 5 pessoas certamente que o faz.

Esta resposta pode ser desfavorável e considerada grosseira por alguns mas…

A primeira bandeira vermelha é For a few years, the founder was unhappy about the technical skills of the employees

Os empregados tentaram rectificar a infelicidade?

A segunda bandeira vermelha é two of the five developers never used SQL before

É difícil criar um sistema eficiente se os programadores não estiverem familiarizados com as tecnologias centrais e compreenderem verdadeiramente o que o ORM está a mascarar.

É difícil imaginar que o I worked for twenty-five years in this industry, and you? What have you done? You've been a code monkey for three years. So shut up, you, moron! Nobody cares about your opinion, a ******. foi realmente proferido, mas vou assumir o valor facial e acreditar em si.

No entanto, considerem a primeira bandeira vermelha que mencionei e a “infelicidade” com que o fundador teve de lidar durante anos.

A isto, eu acrescento: vocês sabem da infelicidade do fundador há anos?!

Como é que esta informação vos foi divulgada?

Estou inclinado a pensar que este tipo está a fazer precisamente o que foi contratado para fazer; pôr-vos em forma.

Pôr-vos em forma não se refere à adopção das más práticas do novo tipo, mas envolve expulsar-vos da vossa zona de conforto para aprenderem a um nível mais profundo.

Durante alguns anos, o fundador ficou insatisfeito com as competências técnicas dos colaboradores, tendo recentemente contratado um promotor sénior para o duplo papel de chefe técnico e gestor de projecto. Foi o único a fazer uma entrevista e o único a decidir contratar esta pessoa.

Parece que o fundador não confia em vocês.

A equipa, no entanto, ficou muito menos agradecida com o seu perfil ao longo de dois meses. Tive a oportunidade de falar com três dos cinco membros desta equipa e todos eles destacaram três questões:

• Segundo eles, o tipo é um idiota e não tem respeito pelos outros membros da equipa. Uma citação recente dele falando com um programador júnior em frente à equipa é muito ilustrativa: “Trabalhei durante vinte e cinco anos nesta indústria, e tu? O que é que você fez? És um macaco de código há três anos. Então cala-te, idiota! Ninguém quer saber da tua opinião.”

Parece que só estás a ter um lado da história. Posso imaginar algumas situações em que eu próprio possa ter de esbofetear um jovem sabichão, e já o fiz. apenas a fazer de advogado do diabo aqui, mas parece que ele foi provocado. Qual foi a provocação?

• No passado, as decisões eram tomadas por todos os membros da equipa. Quando os membros não concordavam, discutiam tudo em conjunto e chegavam a um acordo, ou pelo menos explicavam o raciocínio aos que não concordavam.

• Aparentemente, as práticas passadas não geravam os resultados que o fundador queria.

• Agora, todas as decisões importantes são tomadas exclusivamente pelo desenvolvedor líder. Essas decisões não podem ser questionadas ou discutidas, mesmo que os cinco membros da equipa considerem que uma decisão não faz sentido.

Mais uma vez, soa como um voto de desconfiança do fundador. Ele trouxe este tipo de pessoa por uma razão. Parece que a razão foi para dar forma ao resto da equipa.

1. Ele odeia IDEs, auto-completação e funcionalidades que se destinam a ajudar os programadores a escrever código mais rapidamente, e afirma que a equipa deve usar o Notepad++ para ser produtiva. Embora faça sentido em circunstâncias diferentes, é difícil imaginar os programadores C# a abandonar subitamente o Visual Studio para o Notepad++.

IDEs podem atrasá-lo se for um programador rápido. O Notepadd ++ é superior a alguns para uma codificação rápida. A ideia é que você escreva o seu código, depois largue-o na IDE para correcção rápida em vez de interrupções constantes.

1. Ele não refactoriza o código, e não se preocupa com o estilo (que é inconsistente com o seu próprio código), sendo a razão de que “ele só se preocupa com coisas que realmente importam”. Como nota lateral, o estilo foi previamente verificado por uma construção nocturna, que começou a falhar desde a chegada da nova pista.

Shop standards são algo a discutir com o fundador, especialmente porque o estás a fazer através da construção nocturna. Mas mais uma vez, lendo nas entrelinhas, parece que o fundador não confia em si.

1. Ele rejeita a ideia de uma construção nocturna, bem como testes automatizados. Segundo ele, “qualquer desenvolvedor profissional testa o seu código de qualquer maneira à mão, por isso não há razão para perder tempo a escrever testes automatizados”. A construção nocturna é também uma perda de tempo, de acordo com ele.

Os testes automatizados não são, de acordo com ele, responsáveis pela genialidade de um idiota que faz algo que nunca teve a intenção de fazer. Eu pessoalmente quebrei vários programas que passaram por testes automatizados.

1. Ele acha que o controlo de versões é na sua maioria inútil, e parece entender mal como usar um. Isto leva a situações em que ele desenvolve uma funcionalidade sozinho durante três a cinco dias, e quando ele finalmente comete as suas alterações, ele “leva a minha” para todos os conflitos. Se outros membros da equipa se queixam de que o seu código foi apagado, ele convida-os a reescrevê-lo. Em várias ocasiões, outros membros fizeram o mesmo, apagando o código do programador principal. Ele pareceu surpreendido (parece que não sabe usar o svn log ou diffs), e fez as suas alterações novamente, queixando-se de que “estavam misteriosamente perdidos” e culpando a SVN por estragar tudo.

Todos estão em falta aqui. Será que ninguém faz backup? Se ele está a ter problemas com o controlo de versões, é da responsabilidade da equipa trabalhar em equipa e não só lhe dar trabalho.

1. Ele sobrestima a importância da optimização do código. A sua abordagem é correcta, ou seja, corre um profiler, determina um estrangulamento e corrige-o; o problema é que não existem requisitos não funcionais de performance, e não existem elementos que indiquem que os utilizadores possam considerar a aplicação como sendo lenta (e alojada em VMs de desenvolvimento de baixo nível, a aplicação sente-se muito responsiva). Ele, por outro lado, gasta praticamente metade do tempo a optimizar o código.

Não há forma de sobrestimar a importância da optimização do código. O objectivo da optimização do código não é ter a certeza de que o código está a funcionar correctamente ** actualmente**, o objectivo é optimizá-lo de forma a que não está a resolver algum problema três anos depois, o que poderia ter sido evitado com a optimização do código.

Se apenas se preocupa com o facto de os utilizadores serem felizes hoje, amanhã vai tê-los a bater à sua porta.

1. Ele escreve todo o SQL à mão e rejeita a ideia de um ORM. Deve-se notar que o produto actual é baseado na Entidade ORM da Microsoft, e dois dos cinco programadores nunca usaram SQL antes.

Dois dos cinco programadores devem ser demitidos então. Se estiver a contar com um ORM, nunca conseguirá passar por baixo do capô e reparar as coisas manualmente. Estou a começar a ver porque é que ele chamou a alguém “macaco de código” em frustração. ORMs são boas e boas, mas você precisa entender o SQL se você vai alguma vez ultrapassar as limitações de um ORM.

1. Ele rejeita frameworks e bibliotecas de terceiros, considerando que é muito mais fácil escrever coisas a partir do zero. Ele decidiu abandonar todas as bibliotecas e frameworks JavaScript excepto jQuery, alegando que quando ele começou a programar em JavaScript há quinze anos atrás, não havia frameworks e a vida era muito mais fácil.

Ele tem razão. Frameworks e bibliotecas de terceiros têm limitações, e se você não entende o suficiente para entrar e consertá-lo você mesmo, você não entende o código. Uma discussão pode ser feita de qualquer maneira. Se, no entanto, ninguém na equipa consegue codificar sem usar as frameworks, então tem uma equipa muito fraca.

1. Ele pensa que os dispositivos móveis (incluindo as tablets) são apenas um hype, por isso não há razão para perder tempo precioso para assegurar a compatibilidade do site com esses dispositivos e para fazer um design responsivo. O produto é uma aplicação web pública que não se espera que seja muito utilizada a partir de dispositivos móveis. O design reactivo, contudo, pode ser muito interessante de ter para esta aplicação, uma vez que mesmo em desktops, será apresentado tanto em monitores de 19 polegadas como em grandes monitores de alta resolução.

De tudo o que afirmou, parece que foi trazido para a casa limpa. Se os dispositivos móveis não são um jogador importante para a(s) aplicação(ões), gastar demasiado tempo é um desperdício. Embora possa ser um “nice to have” num desktop, um “nice to have” não é uma necessidade para o lançamento.

1. Ele pede à equipa para parar de usar a internet (especialmente o StackOverflow) e confiar nos seus cérebros, na documentação offline (eu nem sabia que a Microsoft ainda vendia CDs MSDN!) e nos livros.

Bom para ele. Parece que ele quer saber quem pode fazer os seus próprios trabalhos de casa e quem tem feito batota.

Membros da equipa queixaram-se ao fundador da empresa sobre a sua nova pista sobre estas três questões. O fundador respondeu que eles estão a exagerar e que ele tem uma confiança absoluta nas capacidades do novo líder, com base no seu CV e na entrevista, razão pela qual ele atribuiu a esta pessoa o papel de líder de desenvolvimento.

O que deve a equipa fazer a:

• Ou expulsar o líder da equipa ou da empresa,

• Ou forçá-lo a mudar a sua atitude em relação à equipa?

• Que tal trabalhar com ele e não sabotar todos os seus movimentos?

Com toda a honestidade, parece que ele foi trazido para a casa limpa, dado o que postou, parece mais do que justificado.

O proprietário NÃO está satisfeito com o seu desempenho. Seria bom que aceitasse o conselho deste colega pelo que ele vale. Nós relíquias temos um pouco de experiência e sabemos o que os livros nunca lhe vão ensinar. No entanto, em vez de ver isto como uma oportunidade para aprender e crescer, a sua equipa está a ter um grande encaixe.

Por isso, não sei até que ponto os membros da sua equipa se queixaram ao seu patrão sobre o principal dev. Mas já teve uma boa conversa à mesa com eles? Explique ao seu chefe os problemas que está a ter com o chefe e deixe-o ter a sua versão da história.

Desistir deve ser um último recurso.

O proprietário precisa de contratar um gerente de pessoal

Outras respostas têm insinuado isto, mas o elefante na sala é que o proprietário (compreensivelmente) parece estar a ter dificuldade em desempenhar com sucesso funções de pessoal como contratação, formação, despedimento, etc. Caso em questão: o dono da sala tem uma equipa de subdesenvolvimento, suporta-os durante anos, depois contrata um veterano de 25 anos para arranjar as coisas, depois contrata um consultor quando o veterano de 25 anos não consegue arranjar as coisas. O proprietário parece não saber como gerir o lado pessoal da empresa. Tudo bem, há pessoas que fazem isso para viver, e é por isso que a maioria das organizações tem gestores de pessoas. O proprietário precisa de contratar um estatuto. Isto vai libertar o proprietário para se concentrar no lado estratégico do negócio, por isso é uma vitória._

Talvez a OP possa ajudar na entrevista (afinal, o proprietário parece precisar de ajuda a este respeito)?

Uma “ruga” que eu ainda não vi aqui. É bastante comum que pessoas com muita experiência fiquem na defensiva por não estarem a par dos desenvolvimentos actuais. Eu costumava ficar da mesma maneira com as pessoas a falar de como o VB6 era horrível em relação ao maravilhoso .Net, quando essas pessoas estavam apenas a repetir coisas que tinham ouvido sobre o VB6 e não sabiam muito sobre ele.

Como vocês dizem, muitas coisas que o líder diz estão no ponto. Mas isso não significa que todas elas estejam, como diz. Talvez o Sr. 25 anos possa abrir a sua mente e sintetizar a sua abordagem com o melhor do status quo, mas não se ele tiver medo de ser menos do que perfeito e em negação de ter medo. No que me diz respeito, esse é o verdadeiro problema aqui. Pode haver outros problemas com os juniores (defensivos sobre a sua falta de conhecimentos, por exemplo), mas parece ser essa a questão subjacente aqui.

Se todos se juntarem e abordarem os seus medos de uma forma aberta e honesta, então devem começar a avançar numa direcção mais positiva. Não posso dizer que pareça uma grande probabilidade, mas é o que tem de ser feito.

1. Toda a equipa falou com este programador e tentou explicar os benefícios de coisas como o controlo de versões e IDEs? Uma discussão franca em massa pode ajudar

2. Concordo que insultar outros programadores não é profissional e isto deve ser-lhe explicado à força. Pergunte-lhe se está satisfeito se outros adoptarem o mesmo tom

3. Pergunte-lhe se está a sofrer algum stress doméstico ou se tem um problema de saúde como a Diabetes que o está a irritar

4. Pergunte-lhe se está feliz por estar a ficar velho e um velho rabugento com a mente a atrofiar, pois não aprende nada de novo.

5. Se tudo o resto falhar diga que todos os seus erros serão documentados para salvar a sua própria pele e as conversas com ele podem ser gravadas