Recuperando a confiança do programador sênior [fechado]

Meu chefe descobriu que eu não sou tão inteligente quanto ele pensava.

Um exemplo da minha experiência:

Sou programador júnior e trabalho em uma equipe de dois, meu chefe (programador sênior) e eu.

Fui encarregado de desenvolver um aplicativo Web interno para a empresa em que trabalhamos. Escrevi o back-end para o front-end (o design do banco de dados já estava em vigor e a tecnologia do servidor havia sido escolhida). Ele verificava periodicamente meu progresso observando o aplicativo da Web em ação e estava feliz com o fato de estar chegando. Quando terminei o aplicativo da Web, ele ficou satisfeito com o desempenho do produto final.

Alguns dias atrás, ele ficou interessado no código, então eu disse a ele que tecnologias eu usava (para o front-end), e foi para lá que foi para o sul. Para o front-end do aplicativo da web, usei uma estrutura Javascript (Backbone.js). Quando perguntado por que eu faria uma coisa dessas. Minha resposta foi porque senti que a estrutura se encaixava muito bem nesse aplicativo e me ajudaria a estruturar o código melhor do que se eu o escrevesse do zero ... "Bem, isso é desanimador" foi a resposta dele.

Portanto, dado este exemplo, minha pergunta é:

Se você é um programador sênior e perdeu a confiança na capacidade do seu programador júnior, o que você gostaria de ver do seu júnior para recuperar a confiança?

EDIT : Obrigado a todos pelas ótimas respostas e feedback de suporte!

Se ele gostou do produto que você criou, mas está preso ao uso do Backbone, os dois precisam ter uma conversa sobre a pilha de tecnologia desejada.

Como desenvolvedores, devemos usar ferramentas prontamente disponíveis e, consequentemente, mover suavemente nosso fluxo de trabalho. Se ele esperava que você construísse o front-end do zero, ele deveria ter sido explícito e ter boas razões.

O fato de ele ter gostado do produto é prova suficiente de que você se saiu bem e é "inteligente" o suficiente.

Você fez bem. Converse com seu sénior e veja o que ele espera de você.

Ele não me parece muito "sênior" para fazer um julgamento rápido assim. Eu sempre tendem a usar uma estrutura adequada em vez do anti-padrão "Reinventar a roda quadrada". Se ele fosse verdadeiramente sênior, entenderia e conheceria o valor de uma boa estrutura. Na melhor das hipóteses, eu esperaria que ele questionasse a escolha do Backbone.js em relação a outra estrutura JavaScript do MVC e muito antes no processo. Ele falhou em orientar adequadamente e verificar você como um júnior e ajudá-lo no caminho de desenvolvimento adequado (em sua mente).

Parece que você fez a escolha certa no desenvolvimento do projeto, dada a falta de orientação da parte dele (suposição) e está trabalhando para ser um desenvolvedor mais competente. Eu pensaria que poderia ter valor em explicar a ele sua escolha de estrutura, por que você sentiu que uma estrutura era apropriada e apontar que o projeto foi concluído e para sua satisfação em parte por causa do uso de estrutura bem documentada e suportada. Se você não pode progredir, talvez não haja valor em parecer melhor aos olhos dele. Só você pode responder isso.

A maioria das respostas e comentários tem a ideia certa de que você e o idoso precisam ter algum tipo de discussão e que pode ser importante intensificar e defender suas decisões, mesmo que o idoso não concorde com suas escolhas .

Para responder sua pergunta sobre o que eu gostaria de ver como sênior:

Eu gostaria de ver se meus desenvolvedores juniores podem se levantar e defender suas decisões, mesmo que desapontado. Se eu estivesse feliz com o produto, mas não com a implementação, esperaria que os juniores apontassem que eu deveria ter sido mais específico nas minhas especificações ao fornecer o produto. Eu gostaria que eles pudessem se manter firmes, mas também admitir que eles podem não ter feito a escolha certa, se for esse o caso.

PS: Devo mencionar que sou um idoso que adora provar que está errado em nível profissional, pois isso me dá a oportunidade de aprender algo novo. E eu gosto de estar ciente de como os outros membros da minha equipe fazem as coisas para que não haja / menos surpresas no final de uma tarefa / sprint.

Antes de tudo, acho que isso precisa ser visto como uma oportunidade, não um fracasso. Obviamente, há uma incompatibilidade de expectativas e não está claro de onde isso vem, o que precisa acontecer para colocar tudo de volta nos trilhos e coisas do gênero.

Em segundo lugar, se você considera isso uma falha atual ou não é tão inteligente quanto pensa que estabelece relacionamentos de poder que você não deseja. Portanto, se você tomou decisões que acredita serem defensáveis, precisa estar disposto a defendê-las até certo ponto.

Embora eu concorde com o fato de que você deseja ter uma conversa, isso não é suficiente. Você precisa estar preparado para entrar, discutir suas idéias de design, explicar por que você fez o que fez e defender o raciocínio. Você também precisa aceitar que não há apenas uma resposta certa e que o programador sênior pode ter razões válidas para preferir um design diferente e, portanto, deseja estar disposto a ouvir essas razões sem admitir que suas decisões foram mal baseadas sobre o que você sabia (a menos que você decida que deveria saber melhor, e isso é outra questão).

Lembre-se de que o design geralmente é uma questão de compensações. Você deseja discutir o que são as trocas e ver o que vocês dois podem fazer para garantir que possam discutir trocas de design no futuro. Talvez vocês dois estejam apenas esperando que estejam mais na mesma página do que estão? Talvez seu chefe seja um idiota (às vezes pode acontecer)? Talvez você realmente tenha tomado uma decisão errada, considerando o que sabia sobre os requisitos? Entre com uma mente aberta e com confiança, no entanto, e esteja realmente disposto a falar sobre isso.

Edit: Eu quero adicionar algo sobre ser inteligente. As pessoas mais inteligentes que conheço são as que pensam que têm algo a aprender com todos. As pessoas que estão fechadas e acreditam que existe apenas um caminho certo não acabam tomando decisões imaginativamente boas em áreas como design e não conseguem conectar as coisas da mesma maneira que as pessoas que estão dispostas a aprender com todos podem. Entrar e estar disposto a compartilhar e até trocar idéias é um sinal de ser inteligente e confiante. As diferenças no design não se tornam necessariamente questões de um ser melhor que o outro. Assumindo designers competentes, projetos diferentes serão otimizados de maneira diferente.

Estou com a opinião geral aqui de que você não fez nada de errado. Como desenvolvedor sênior, ele deveria ter interesse em saber como você estava desenvolvendo o aplicativo e também nos resultados. Entrar após a conclusão de um projeto e dizer que ele não gosta de como foi feito não é muito profissional da parte dele.

Mas, para responder à sua pergunta principal: como você recupera a opinião de um idoso depois que ela pode ter sido perdida? Antes de tudo, pergunte como eles acham que você deveria ter feito isso. Faça perguntas se você não entender e faça anotações. Mostre que você quer aprender.

Segundo, na sua próxima tarefa, se houver algo que foi deixado de fora da descrição, crie suas idéias e execute-as pelo desenvolvedor sênior. Não pergunte como fazê-lo, pois isso não ajudará na opinião deles. Mas, se você tiver suas próprias idéias e suas próprias soluções, pergunte se está no caminho certo, isso mostrará que você está tentando e que possui as habilidades necessárias para realizar o trabalho. Isso pode ser tão simples quanto um e-mail rápido dizendo "Ei, estou pensando em usar x ao fazer y . Alguma idéia?"

Terceiro, quando eles aparecerem para ver como você está, não os deixe sair sem olhar para o seu código.

Basicamente, abra as linhas de comunicação. Seu desenvolvedor sênior não parece ser do tipo que você ou seu código, portanto, você precisa intensificar e ser a pessoa a se comunicar. É melhor que todos os envolvidos descubram que algo não é exatamente originalmente pensado mais cedo ou mais tarde.

Uma coisa que você precisa descobrir logo de cara é se ele está desanimado porque você não pode dar uma defesa abrangente de sua escolha de estrutura, ou se é porque você usou uma estrutura.

No primeiro caso, é importante que você aprenda como avaliar e selecionar código de terceiros para inclusão em um projeto e que saiba articular essa decisão com seus superiores e esteja preparado para apoiá-la com justificativa. Essa é uma habilidade complicada de aprender, mas vem com a experiência. Também é uma boa habilidade para aprender, porque assim que você inclui uma biblioteca de terceiros em um projeto, você introduz um componente que pode não ser totalmente compreendido pelos outros desenvolvedores, que eles não têm controle total e podem conter bugs, falhas de segurança e outras coisas que eles precisam estar cientes.

Se ele está decepcionado porque você não escreveu do zero, isso é uma questão completamente diferente. Pode ser que ele tenha boas razões para desencorajar o uso de estruturas (como as que descrevi acima), ou talvez exista uma política da empresa contra elas ou que limite a escolha de estruturas que você pode fazer. De qualquer maneira, ele deveria ter comunicado isso a você e o fato de não indicar uma falha da parte dele. Por outro lado, ele pode ter apenas um caso de preconceito de estrutura, porque, apesar dos problemas que as estruturas podem levar, eles também trazem grandes benefícios, como eu tenho certeza que você sabe. Ele pode apenas pensar que você deve fazer tudo sozinho, mesmo que isso signifique refazer o trabalho que já foi feito e disponibilizado ao público devido à "síndrome do não inventado aqui".

O fato de ele não ter explicado por que está decepcionado com você por usar uma estrutura é certamente um fracasso da parte dele em se comunicar de maneira eficaz. Ele deixou você se perguntando o que você fez de errado, quando a resposta poderia muito bem ser "nada". Ele também fez você se questionar, e isso o deixará menos inclinado a usar sua própria iniciativa no futuro. Se há uma característica que um bom programador não pode se dar ao luxo de ter, é uma falta de iniciativa. E, embora eu tenha certeza de que não é intencional, a atitude dele é prejudicial ao moral, pois ele repentinamente retira elogios por um trabalho bem feito com um pequeno detalhe de como você realizou a tarefa.

Só porque ele é o programador sênior não o torna infalível.

O seu comentário de acompanhamento que disse que o chefe está chateado, ele tem que aprender algo novo ....

A menos que haja mais do que você não tenha mencionado, eu ficaria irritado com ele.

Aprender novas tecnologias é uma grande parte do nosso trabalho e cada equipe deve adotar o aprendizado e o auto-aperfeiçoamento.

MAS, a gerência tem outras coisas com que se preocupar. Eles têm prazos a cumprir, têm orçamentos de treinamento limitados ou inexistentes.

Do ponto de vista da gestão de pessoas, pode ser alguém trabalhando na fase 2 do seu projeto, em vez de você. Seu chefe pode ter alguém marcado para fazer esse trabalho, e ele sabe que essa pessoa agora tem uma curva de aprendizado para algo novo.

E agora um MAS no anterior MAS ....... isso é culpa de seus chefes. Se você é novo e júnior, ele deveria ter fornecido pelo menos alguma orientação. Em menor grau, você também pode ter solicitado orientações sobre a tecnologia a ser usada.

Se você é um programador sênior e perdeu a confiança na capacidade do seu programador júnior, o que você gostaria de ver do seu júnior para recuperar a confiança?

Dado que você disse que ele não queria aprender a usar a estrutura usada, acho que a pergunta deveria ser: " Se você é um programador sênior e perdeu a capacidade de aprender com o seu programador júnior, o que você deve fazer para se resolver? "

Como desenvolvedor profissional, você não para de aprender. Sempre. Se fizer isso, você vai estagnar. E isso pode ser bom em algumas áreas. O setor bancário possui muitos sistemas legados em operação que precisam ser mantidos, para que o conhecimento dos sistemas antigos que se movem muito lentamente seja bom. Um amigo meu estava editando o COBOL para um banco para descobrir que o código-fonte que ele estava consertando não era tocado há cerca de 30 anos (e o autor original era nosso professor de COBOL na universidade) ... Dito isso, ele ainda precisa aprender coisas novas, pois sistemas antigos precisam ser integrados a novos sistemas.

Voltar ao seu desenvolvedor sênior. Você disse que " ele estava chateado por ter que aprender algo novo " e, na minha opinião, isso soa como um alarme bastante alto.

Eu estou sempre aprendendo. Embora eu realmente queira que meu empregador receba minha conta de educação todos os anos, é raro que eles gastem algo próximo do que eu realmente preciso, mas sei que devo permanecer empregável, por isso gasto em algum lugar na região de £ 2000 GBP (aproximadamente US $ 3000) na minha própria educação todos os anos.

Se o seu idoso não estiver aprendendo coisas novas, ele começará a tomar más decisões (talvez já o sejam) e a qualidade do código com o qual você está lidando diminuirá porque está presa em um barranco e não sente a necessidade de obter fora dessa rotina.

Um dos melhores desenvolvedores com quem já trabalhei foi um desenvolvedor júnior que conhecia todo tipo de coisa que eu nunca tive a chance de ver. Ele trouxe tanto para a mesa que muitas vezes fiquei impressionado. Mas apreciei seus esforços e nunca fiquei "desanimado" com nada disso. Fiquei satisfeito por ele ter aproveitado o tempo para apreciar todas as possibilidades e apresentá-las à equipe. Ele agora lidera uma equipe e continua me falando sobre desenvolvedores que trazem coisas para a mesa e o que ele está aprendendo com eles.

Seu desenvolvedor sênior precisa aprender coisas. Eles precisam aprender a não usar palavras emotivas (como "desanimadoras") para esconder suas próprias inadequações, porque isso irá derrubar a confiança dos outros. Eles precisam aprender novas estruturas (mesmo que não consigam aprender tudo, aprender o que faz e como resolve um problema, e se precisarem no futuro, poderão investir tempo aprendendo mais profundamente). E eles precisam aprender que estão em um emprego em que terão que continuar aprendendo o tempo todo.