Como os gerentes sabem se uma pessoa é um programador bom ou ruim?

Na maioria das empresas que fazem equipes e divisões de programação, consistem em programadores que projetam e escrevem código e gerentes que ... bem, fazem as coisas de gerenciamento. Além de não escrever código, os gerentes geralmente nem olham para o código desenvolvido pela equipe e podem até não ter um IDE adequado instalado em suas máquinas de trabalho.

Ainda assim, os gerentes devem julgar se uma pessoa funciona bem, se ela deve ser encarregada de algo ou se um desenvolvedor em particular deve ser designado para uma tarefa da maior importância e responsabilidade. E por último, mas não menos importante: os gerentes costumam atribuir os bônus trimestrais!

Para fazer isso de maneira eficaz, o gerente deve saber se uma pessoa é um bom programador - entre outras características, é claro. A questão é: como eles fazem isso? Eles nem olham para o código que as pessoas escrevem, não podem avaliar diretamente a qualidade dos componentes que os programadores desenvolvem ... mas suas estimativas de quem é um bom codificador e quem não é tão bom são, no entanto, corretas em na maioria dos casos!

Qual é o segredo?

Normalmente, um gerente analisará

• O programador faz as coisas?
• O que seus colegas pensam deles? O código que eles escrevem?
• O programador se comunica claramente com o gerente?
• O programador gosta de aprender coisas novas? Eles orientam bem os outros?
• Eles precisam de muita atenção da gerência para fazer as coisas?
• O programador parece se divertir com seu trabalho?

É verdade que eles geralmente não veem (ou costumam entender) o código dos funcionários, mas o acima exposto serve como um proxy razoável para medir o quão bem um funcionário se encaixa na função de programação que lhes é imposta pelo empregador. Se alguém não está fazendo as coisas, obtém notas baixas de seus colegas, não consegue se comunicar bem, fica frustrado com a tecnologia diferente, então está acostumado, sempre precisa de supervisão e está sempre infeliz, é uma boa indicação de que não está ' t combinando bem com este trabalho. *

* Pode ser, no entanto, que em um contexto e ambiente diferentes, eles ficariam muito felizes e entusiasmados. Talvez seja apenas o tipo de programador a que eles se opõem, e eles podem fazer muito bem a programação em um contexto diferente. "Programador" pode significar trabalhos muito diferentes em lugares diferentes. Mas o gerente se preocupa principalmente com o papel de "programador" e com o desempenho de um funcionário.

Não concordo com a afirmação de que os gerentes não olham para o código. Quando gerenciei equipes, observei algumas das saídas de todos os engenheiros - e uma grande delas é o código. Mas não o único - e-mails, documentos de design, documentos técnicos - tudo isso leva em consideração.

Mas esse definitivamente não é o único fator. Se um cara está sentado em um canto e escrevendo um código brilhante , mas é um animal com quem conversar, não responde perguntas, não compartilha status e não se compromete quando surgem problemas de desenvolvimento - não tenho tanta certeza de que ele seja um ativo para a equipe. Especialmente comparado a um cara que escreve código moderadamente decente, mas pode fazer tudo o que precede.

Aqui estão algumas coisas que olho quando estou em posição de dar recompensas, mas com a enorme ressalva de que é absolutamente uma reação intestinal, porque nada disso pode ser quantificado:

• Status - é claro, preciso e oportuno? Quando discutida, a pessoa está no topo do status ou está um pouco embaçada nas questões atuais? A pessoa tem o julgamento certo para levantar uma bandeira vermelha quando algo pegar fogo?
• Solução de problemas - perguntar e responder é importante. A pessoa sabe quando pedir ajuda ou onde está girando suas rodas indefinidamente? Melhor ainda, quando outros têm problemas, a pessoa ajuda a encontrar a solução ou se torna parte do problema? Mesmo tendo o bom senso de recuar quando o problema não está na sua área de especialização, vale alguns pontos. Também há pontos para sair do grupo ou da empresa e acessar sites como esse ou outras respostas da Internet.
• Atenção ao processo - geralmente isso é bastante óbvio - mesmo em uma empresa sem retenção anal, se alguém está impedindo o sistema, isso é visto no caos que eles deixam para trás. Se outras pessoas estiverem limpando os recursos de outras pessoas porque não aderiram às orientações ou à arquitetura, temos um problema. Os pontos de bônus vão para aqueles que descobrem maneiras de tornar a consistência e a qualidade mais fáceis .
• Taxas de conclusão vs. bugs versus complexidade - faça as coisas, mas faça as coisas da maneira certa. Todo mundo tem alguns bugs, mas se o cara faz coisas rapidamente e com bugs, temos um problema. Em geral, acho que isso não é algo que você possa avaliar no sentido diário - deve ser uma retrospectiva, uma fase ou um trimestre fiscal.

E a contribuição de outras pessoas. Frequentemente, estive em uma posição em que vários engenheiros estavam encarregados de várias partes do projeto. Às vezes, a equipe lidera e, às vezes, apenas os proprietários de uma parte específica da produção (como "o cara da construção"). As pessoas gostam de falar sobre os extremos - os atos de heroísmo ou a frustração das crianças problemáticas. Geralmente, no ato de acompanhar essas questões, eu descubro muito sobre as duas partes.

Também há um fator no gerenciamento de humanos . Nenhum engenheiro é exatamente como qualquer outro. Para que nem todos brilhem na mesma luz. Um escreve código brilhante sem erros, mas outro ajuda a resolver problemas transversais que quebram o código de todos. Um é ótimo pessoalmente, um é melhor por escrito. Um é incoerente às 9:00 da manhã, um sai daqui às 15:00. Há uma certa necessidade de dar um passo atrás, descobrir o que é mais benéfico para a equipe e o que pode ser um fator de viés pessoal (como o desejo de matar aquele cara picador às 4:00 da manhã, só porque eu não posso funcionar até as 11: 00:00).

Isso varia bastante, dependendo da experiência técnica do gerente.

• Na maioria das vezes, eles provavelmente estão te julgando sobre como você se comunica . Como você se comunica com o gerente e como é visto se comunicando com seus colegas.
• Se você tiver sorte de ter um desenvolvedor líder que está mais próximo do gerente, ele poderá buscar informações do desenvolvedor líder.
• Lembre-se de que a principal responsabilidade do gerente é fazer as coisas . Ele precisa ver a produção de vários resultados e metas para cumprir o plano de negócios. Portanto, se você for capaz de parecer que está influenciando diretamente o resultado , isso será um bom presságio para você.

Geralmente, eles não.

É por isso que a programação é um "mercado para limões". http://en.wikipedia.org/wiki/The_Market_for_Lemons

O código é estragado, e geralmente não é de 2 a 3 anos antes que você perceba. Os programadores geralmente ficam 18 meses, para que você nunca veja os culpados pela falha.

Os gerentes precisam ter sua palavra de que, por exemplo, um release leva quatro meses e cem iterações. Talvez você esteja editando muitos arquivos de implantação manualmente e lendo arquivos de log em busca de erros misturados ao status? Eles não sabem que isso poderia ser feito melhor.

Portanto, seja honesto e profissional e tente melhorar. Com a experiência, um gerente começará a ver padrões de bom e mau comportamento.

Como os gerentes sabem se uma pessoa é um programador bom ou ruim?

Começarei com uma generalização generalizada: a maioria dos gerentes não consegue distinguir um programa "bom" de um programa "ruim".

Com isso fora do caminho, o que a maioria dos gerentes (que conheci ou trabalhei) considera "bom" em um programador não é o mesmo conjunto de habilidades que outro programador consideraria "bom".

Como eles fazem isso?

Um gerente orientado a resultados vai procurar coisas como "inteligente" e "faz as coisas". Eles não vão se importar se você aparecer trabalhando em calças de moletom, desde que faça as coisas dentro do prazo e do orçamento.

Um gerente orientado a processos está mais preocupado com "como as coisas são feitas". Isso significa chegar ao trabalho a tempo, usar a roupa certa e você tem a capa certa no relatório do TPS.

pessoa funciona bem, se ele ou ela deve ser encarregado de algo

Estar "no comando" requer habilidades diferentes do que escrever código. Se uma pessoa possui as habilidades necessárias para liderar uma equipe, essa pessoa deve ser convidada a fazê-lo. Se você promover pessoas com base nos principais elementos do trabalho que eles estão realizando atualmente, eles chegarão a um nível em que agora são incompetentes. Isso é chamado de princípio de Peter .

Obviamente, sempre ajuda ter um gerente especializado em programação que possa realmente ler o código e, ainda mais importante, se aprofundar no sistema de rastreamento de bugs e entender o que está acontecendo, saiba que nem todos os bugs são criados da mesma forma e apenas fornecer código incorreto no prazo não conta. para muito.

Mas esse é um caso ideal. Para um gerente obter a medida de um programador de uma perspectiva não técnica, tenho algumas sugestões.

• Eles destacam prontamente / regularmente / de forma consistente onde há problemas em fazer as coisas para atender aos requisitos especificados atualmente ... e são completamente irritantes por causa disso (afinal, isso é desenvolvimento de software, se não for suficientemente complexo para ter esses problemas, não é um projeto de desenvolvimento real).
• Se eles não têm certeza de alguma coisa, dizem imediatamente - apenas um programador confiante em sua própria capacidade faria isso (e eles sabem que, se você não gostar, podem facilmente conseguir outro emprego). Por outro lado, alguém que sabe que está seriamente fora de profundidade tende a se esconder e a procurar cobertura.
• O que outros programadores da equipe dizem / implicam sobre os outros programadores? Se você é um gerente meio decente, está nas trincheiras com sua equipe de programação - especialmente durante o tempo de teste de integração / correção de erros. Portanto, se você não está recebendo esse tipo de feedback, alguém deve fazer seu trabalho.
• E o meu favorito: o que eu chamo de programador 'tomcat'. Se depois de um tempo você estiver constantemente percebendo vários programadores sempre circulando pela mesa do mesmo programador (supondo que eles estejam trabalhando e discutindo algum problema, e não o localizador residente de coisas legais e engraçadas) ... então há uma razão para outros programadores estão gravitando para a mesa dessa pessoa. Se eles ainda não são um líder de equipe, provavelmente devem ser escolhidos o mais rápido possível.

Se algum ou todos estes se aplicarem, é provável que você tenha um bom programador em suas mãos. Observe que, por um bom programador, não apenas avalio sua capacidade de codificação, mas outras coisas úteis, como poder me comunicar com outros seres humanos ;-)

O gerente pode não saber quando o código que você escreve é ​​brilhante ou se pode ser aprimorado por um grande fator, mas o que ele sabe é: você cumpriu o prazo com o código que funcionou? Você é uma pessoa em quem ele pode confiar para resolver os problemas que outras pessoas criam? O cliente ou usuário notou um problema que foi encaminhado para o gerente? Houve um grande desastre no seu relógio (a tabela de usuários foi excluída, esqueceu de configurar backups, enviou um email aos clientes com dados proprietários de outro cliente que eles não deveriam ter visto, etc. Alguém elogiou seu trabalho (especialmente por escrito) As pessoas dizem coisas boas ou ruins pelas suas costas?

1. Na maioria dos casos, em que seu código não é avaliado por seu gerente, ele é avaliado por seus colegas (formal ou informalmente quando eles tentam trabalhar com seu código). Seu chefe usará as opiniões de seus colegas (novamente, formais ou informais) até certo ponto.
2. Sua confiabilidade geral e a rapidez com que você progride e conclui tarefas geralmente é um fator muito importante, separado da sua capacidade de codificação.
3. Comunicação. Se você está fazendo muito e bem, seu gerente precisa saber disso! (Evite se gabar, é claro). Aprenda a "gerenciar seu gerente" e não seja simplesmente passivo. Ajude seu chefe a saber como você trabalha.

Os gerentes são os próprios codificadores e, portanto, podem, por simples observação, descobrir se o codificador é bom ou não.

Se seus gerentes não são codificadores (e você está no negócio de software), você está ferrado.

Como gerente, aqui estão algumas das coisas que eu observei ao avaliar meus programadores:

• Opinião dos pares. Pedi aos programadores da minha equipe e aos programadores de outras equipes que me enviassem feedback sobre o meu pessoal.

• Respeito pelos pares . Quando meus programadores enfrentam um problema que não conseguem resolver, dizem "vamos pedir conselhos".

• Faz as coisas . Eu digo "eu quero X" e no dia seguinte, X está pronto.

• Torna as coisas inteligentes . Eu digo "Eu quero X" e no dia seguinte, não apenas o X está pronto, mas todas as coisas semelhantes ao X são resolvidas e não precisam de mais atenção.

• Me corrige . Eu digo "Eu quero X" e o programador diz "X não está certo, devemos fazer Y, e aqui está o porquê".

Não há muitos bons gerentes por aí (veja a pergunta relacionada: como os programadores sabem se uma pessoa é um gerente bom ou ruim?). Gerenciar bem as pessoas é difícil e exige muito tempo e muito trabalho. Assim que gerenciava 5 pessoas, quase não havia tempo para programação. Quando eu estava gerenciando mais de 8 pessoas, não podia mais gerenciá-las como elas mereciam.

Penso que a premissa da sua pergunta é um tanto falha, pois afirma que os gerentes não olham o código. Trabalhei em muitas situações em que meus gerentes eram colegas de engenharia e participaram ativamente de revisões de código.

No entanto, há definitivamente uma pluralidade de situações nas quais uma pessoa não técnica é responsável por engenheiros de software e eles não podem confiar em seu próprio conhecimento e experiência.

Nesses casos, os gerentes responsáveis ​​solicitarão conselhos aos colegas do engenheiro. Eles pedirão a pessoas não técnicas da organização com quem o engenheiro interage para verificar se ele possui boas habilidades de pessoas que são compatíveis com maior responsabilidade.

Os irresponsáveis ​​apenas seguirão suas reações "instintivas" e usarão algum tipo de "métrica" ​​geralmente não suportável.

É uma porcaria, mas você sempre pode sair e esperar algo melhor em outro lugar.

Onde trabalho, quando as avaliações dos funcionários são realizadas, os gerentes enviam um questionador informal e anônimo para aqueles que interagem regularmente com o funcionário; desenvolvedores e também clientes. Isso oferece aos colegas desenvolvedores a oportunidade de fornecer informações sobre o desempenho como codificador que os gerentes podem ignorar.

O gerente tem que olhar para mensuráveis. Quais aspectos do trabalho são mensuráveis ​​em termos de trabalho realizado, qualidade do trabalho. Eles podem não saber se você está fazendo um trabalho de qualidade, a menos que você gere muitos erros ou não permita que o usuário final faça o que deve fazer.

Seu trabalho custa dinheiro ao gerente em despesas; portanto, você deve ser financeiramente lucrativo para continuar empregando.

Não estou dizendo que essa é a melhor maneira de fazê-lo, mas eles podem basear-se na satisfação do cliente. Se eles gostam do aplicativo, aceitam a quantidade de bugs e sentem que adicionam novos recursos em tempo hábil, seus desenvolvedores poderiam realmente ser tão ruins assim?

Claro que eles poderiam. Eles são capazes de força bruta por meio da codificação, porque você tem 10 pessoas fazendo o trabalho de duas. Ou os clientes estão satisfeitos porque você vende seu aplicativo de forma barata.

Outro problema com essa abordagem é que você precisa aguardar até que um aplicativo esteja quase completo para que o gerente não técnico possa receber algum feedback do cliente. Crie um aplicativo por um ano apenas para lançá-lo e ninguém gosta.

A vida seria mais simples se você pudesse contar para as pessoas 'apenas fazer funcionar'. Quando você entende e faz as pessoas aderirem ao processo correto, você elimina muitos problemas. Você pode ter prazos exigentes e realistas. Qualquer tolo pode apresentar demandas irreais e correr o risco de perder pessoas talentosas.

Eu acho que a maioria de nós em uma equipe técnica sabe quem é ótimo e quem é ruim. A menos que você tenha uma tremenda rotatividade, o creme sobe ao topo e o peso morto afunda. Os desenvolvedores péssimos estão sempre com algum tipo de problema - eles esquecem de testar seu código antes de fazer o check-in para criar interrupções, sempre têm uma desculpa quando não fazem algo e assim por diante.

Eu acho que eles não sabem se alguém é um bom programador , porque eles não têm as habilidades necessárias para fazê-lo. Eles verificam se alguém é um bom desenvolvedor . A programação é uma atividade de desenvolvimento, mas o desenvolvimento tem muitas outras. Portanto, eles verificam se você está no prazo, se suas estimativas são boas, se existem muitos defeitos nas coisas que você fez no seu sistema de rastreamento de bugs, suas habilidades pessoais, comprometimento, comunicação etc.

O que alguns gurus de TI às vezes esquecem e se aborrecem é que nosso trabalho não é apenas programação, temos muitas outras coisas a fazer que também são muito importantes. Embora seu gerente não dê uma olhada em como o seu código se parece (porque é totalmente sem importância para ele), ele verificará se você é um jogador de equipe, responsável, respeitoso e faz um trabalho de alta qualidade em geral .

Às vezes, acho que o código está superestimado.

Eu acho que existem muito poucas pessoas (muito menos gerentes) que não têm um bom entendimento geral da hierarquia dos desenvolvedores. Todo mundo pensa que é um desenvolvedor de primeira linha, as únicas pessoas que não sabem quem são os maus desenvolvedores, são os próprios desenvolvedores. De qualquer forma, se você pedir a alguém para classificar os desenvolvedores com quem trabalha, tenho certeza de que seria uma tarefa fácil para a maioria das pessoas. Portanto, não há mágica em determinar quem está se saindo muito bem e quem está se saindo mediano ou ruim, etc. sobre, mas realmente não. A maioria dos gerentes é enganada por eles, mas os desenvolvedores não.

Depois disso, são os preconceitos de seu gerente que determinam sua classificação. Para alguns, a codificação é uma tarefa de nível básico, portanto, embora você seja excelente em codificação, não será a promoção que você está procurando. Enquanto outros consideram os aspectos de design ou arquitetura os mais importantes. E outros acreditam que a definição e coleta de requisitos (ou seja, análise de negócios) é mais importante. Se você deseja saber o que é importante para o seu gerente e não obteve uma classificação de melhor desempenho, pergunte a ele o que preciso fazer para obter uma classificação de melhor desempenho? Você aprenderá o que é importante também para eles nessa resposta e depende de você se destacar nas áreas de importância.