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

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 mentorizam os outros bem?
• Eles precisam de muita atenção da gerência para fazer as coisas?
• O programador parece se divertir com o trabalho deles?

* Pode ser, no entanto, que em um contexto e ambiente diferente, eles ficariam muito felizes e entusiasmados. Talvez seja apenas esse tipo de programador que eles se opuseram, 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 bom desempenho de um funcionário.

Eu não concordo com a afirmação de que os gerentes não olham para o código. Quando gerenciei equipes, examinei algumas das saídas de todos os engenheiros - e um dos principais é o código. Mas não o único - e-mails, documentos de design, whitepapers - tudo isso influencia.

Mas isso definitivamente não é o único fator. Se um cara está sentado em um canto e escrevendo código brilhante , mas ele é uma fera para conversar, não vai responder a perguntas, não vai compartilhar o status e não vai comprometer quando surgirem problemas de desenvolvimento - eu Não tenho certeza se ele é um trunfo para a equipe. Especialmente em comparação com um cara que escreve um código moderadamente decente, mas pode fazer todos os itens acima.

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

• Status - é claro, preciso & oportuno? Quando discutido, a pessoa está no topo do status ou um pouco embaçada nas questões atuais? A pessoa tem o julgamento correto para levantar uma bandeira vermelha quando algo pegou fogo?
• Resolução de problemas - tanto perguntar como responder é importante. A pessoa sabe quando pedir ajuda ou onde ela gira indefinidamente? Melhor ainda, quando os outros têm problemas, a pessoa ajuda a encontrar a solução ou a se tornar parte do problema? Mesmo tendo o bom senso de recuar quando o problema não está em sua área de especialização, vale alguns pontos. Também há pontos para sair do grupo ou da empresa e ir a sites como esse ou outras respostas da internet.
• Atenção ao processo - geralmente isso é bastante óbvio - mesmo em uma empresa não anal-retentiva, se alguém está contrariando o sistema, é visto no caos que eles deixam para trás. Se outras pessoas estão limpando as características de outra pessoa porque não aderiram à orientação ou arquitetura, então temos um problema. 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 vs. complexidade - conclua o trabalho, mas faça as coisas da maneira certa. Todo mundo tem alguns bugs, mas se o cara fizer as coisas rápido e com problemas, nós temos um problema. Eu geralmente acho que isso não é algo que você pode avaliar no sentido diário - tem que estar olhando para um release, uma fase ou um trimestre fiscal.

E a contribuição de outras pessoas. Frequentemente tenho estado em uma posição onde vários engenheiros estavam encarregados de várias partes do projeto. Às vezes, os líderes de equipe e, às vezes, apenas os proprietários de um determinado item de saída (como "o cara da construção"). As pessoas adoram falar sobre os extremos - os atos de heroísmo ou a frustração das crianças problemáticas. Normalmente, no ato de seguir em frente com essas questões, eu descubro muito sobre as duas partes.

Existe também um fator a respeito de gerenciamento de seres humanos . Nenhum engenheiro é exatamente como qualquer outro. Então nem todos brilham na mesma luz. Um escreve um código livre de bugs, mas outro ajuda a resolver problemas transversais que quebram o código de todos. Um é ótimo em pessoa, um é melhor por escrito. Um é incoerente às 9:00 da manhã, um está fora daqui às 15:00. Há uma certa necessidade de dar um passo para trá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 esperto às 4 da manhã, só porque não posso trabalhar até as 11: 00:00).

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

• Para a maior parte, eles provavelmente estão julgando você sobre como você se comunica . Como você se comunica com o gerente e como você é visto se comunicando com seus colegas.
• Se você tiver a sorte de ter um desenvolvedor líder que esteja mais próximo do gerente, o gerente poderá procurar informações do desenvolvedor líder.
• Lembre-se de que a principal responsabilidade do gerente é fazer com que as coisas sejam realizadas. Ele precisa ver produzir vários resultados e metas para atender ao plano de negócios. Então, se você de alguma forma for capaz de parecer como se tivesse uma influência direta no resultado , isso seria um bom presságio para você.

Geralmente, eles não.

É por isso que a programação é um "mercado de limões". link

O código é complicado, e geralmente não é por 2-3 anos antes de você saber. Os programadores geralmente ficam 18 meses, então você nunca vê os culpados pelo fracasso.

Os gerentes precisam entender que, por exemplo, um lançamento leva quatro meses e uma centena de iterações. Talvez você esteja editando muitos arquivos de implantação manualmente e lendo os arquivos de log em busca de erros misturados com o 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.

How do managers know if a person is a good or a bad programmer?

Vou começar com uma generalização generalizada: a maioria dos gerentes não pode dizer a um "bom" programador de um programador "ruim".

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

how do they do it?

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

Um gerente orientado a processos está mais preocupado com "como as coisas são feitas". Isso significa chegar ao horário certo, vestindo a roupa certa e você tem a folha de rosto certa no relatório TPS.

person works well, if he or she should be put in charge of something

Ser "responsável" tem diferentes habilidades do que escrever código. Se uma pessoa tem as habilidades pessoais necessárias para liderar uma equipe, essa pessoa deve ser escolhida para isso. Se você promover pessoas com base nos elementos-chave do trabalho que estão desempenhando no momento, elas acabam chegando a um nível em que agora são incompetentes. Isso se chama O Princípio de Peter .

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 de forma imediata / consistente onde há problemas em fazer as coisas para atender aos requisitos atualmente especificados ... e são completamente irritantes por causa disso (isso é um desenvolvimento de software, afinal, se não for complexo o suficiente para ter essas questões, não é um projeto de desenvolvimento real).
• Se eles não têm certeza sobre algo, eles imediatamente dizem isso - apenas um programador confiante em sua própria capacidade faria isso (e eles sabem que, se você não gostar, eles podem facilmente conseguir outro emprego). Por outro lado, alguém que sabe que está seriamente fora de sua profundidade tende a esconder-se e procurar cobertura.
• O que outros programadores da equipe dizem / sugerem sobre os outros programadores? Se você é um gerente meio decente, você está nas trincheiras com sua equipe de programação - especialmente durante o teste de integração / tempo de correção de bugs. Então, se você não está recebendo este tipo de feedback, alguém deveria estar fazendo o seu trabalho.
• E meu favorito: o que eu chamo de programador 'tomcat'. Se depois de algum tempo você está constantemente percebendo que vários programadores estão sempre trabalhando na mesma mesa do programador (assumindo que estão trabalhando e discutindo algum problema problemático, e não o localizador residente de webmas interessantes e legais) ... então há uma outra razão programadores estão gravitando para a mesa daquela pessoa. Se eles já não são um líder de equipe, então eles provavelmente devem ser feitos um o mais cedo possível.

Se algum ou todos eles se aplicarem, você provavelmente terá um bom programador em mãos. Note que por um bom programador eu não avalio apenas sua capacidade de codificação, mas outras coisas úteis como ser capaz de se comunicar com outros seres humanos; -)

O gerente pode não saber quando o código que você escreve é brilhante ou se poderia ser melhorado por um fator enorme, mas o que ele sabe é: Você cumpriu o prazo com código que funcionou? Você é uma pessoa em quem ele pode confiar para consertar os problemas que outras pessoas criam? O cliente ou usuário notou um problema que foi encaminhado ao seu gerente? Houve um grande desastre no seu relógio (excluiu a tabela do usuário, esqueceu-se de configurar backups, enviou um email para os clientes com dados proprietários de outro cliente que eles não deveriam ter visto, etc. Alguém elogiou seu trabalho com ele (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 (seja formal ou informalmente quando tentam trabalhar com seu código). Seu chefe usará as opiniões de seus colegas (de novo, formal ou informal) até certo ponto.
2. Sua confiabilidade geral e a rapidez com que você progride e conclui tarefas muitas vezes é um fator muito importante, separado de sua capacidade de codificação.
3. Comunicação. Se você está fazendo muito e fazendo bem, seu gerente precisa saber disso! (Evite se gabar, claro). Aprenda a "gerenciar seu gerente" e não apenas ser passivo. Ajude seu chefe a saber como você trabalha.

Os gerentes são os próprios programadores e, portanto, podem, pela 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:

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

• Respeito pelos colegas . Quando meus programadores resolvem um problema que não conseguem resolver, eles dizem "vamos pedir conselhos para o fulano".

• Conclui 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 só X é feito, mas todas as coisas semelhantes a X são resolvidas e não precisam de mais atenção.

• Corrige-me . 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á bons gerentes por aí (veja a questão relacionada: como os progamadores sabem se uma pessoa é boa ou ruim?). Gerir bem as pessoas é difícil e requer muito tempo e trabalho duro. Assim que eu estava gerenciando 5 pessoas, eu quase não tinha tempo para programar. Quando eu estava gerenciando mais de 8 pessoas, eu não conseguia mais gerenciá-las tão bem quanto elas mereciam.

Eu acho que a premissa da sua pergunta é um pouco falha, pois afirma que os gerentes não olham para o código. Eu trabalhei em muitas situações em que meus gerentes eram colegas engenheiros e participavam ativamente de revisões de código.

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

Nestes casos, os gerentes responsáveis vão pedir conselhos aos engenheiros. Eles perguntarão às pessoas não-técnicas da organização com as quais o engenheiro interage para ver se ele tem boas habilidades de pessoas compatíveis com o aumento de responsabilidade.

Os irresponsáveis vão apenas com suas reações "viscerais" e usam algum tipo de "métrica" geralmente insuportável.

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

Onde eu trabalho, quando as avaliações dos funcionários aparecem, os gerentes enviam um questionador informal e anônimo para aqueles que interagem regularmente com o funcionário; tanto colegas desenvolvedores como clientes. Isso dá aos colegas desenvolvedores uma oportunidade de fornecer informações sobre o desempenho como um codificador que os gerentes podem ignorar.

O gerente precisa olhar para os 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.

O seu trabalho custa dinheiro ao gestor em despesas, portanto, você tem que ser financeiramente lucrativo para continuar no emprego.

Não estou dizendo que essa é a melhor maneira de fazê-lo, mas eles poderiam basear-se na satisfação do cliente. Se eles gostarem do aplicativo, aceitarem a quantidade de bugs e sentirem que você adicionou 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 através de codificação porque você tem 10 pessoas fazendo o trabalho de dois. Ou os clientes estão satisfeitos porque você vende seu aplicativo de maneira barata.

Outro problema com essa abordagem é que você tem que esperar até que um aplicativo esteja quase concluído antes que o gerente não técnico possa obter qualquer feedback do cliente. Construa um aplicativo por um ano apenas para liberá-lo e ninguém gosta dele.

A vida seria mais simples se você pudesse contar para as pessoas: "Apenas faça funcionar". Quando você entende e faz as pessoas aderirem ao processo correto, você elimina muitos problemas. Você pode ter prazos exigentes que são 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 é que é o melhor e quem é ruim. A menos que você tenha um volume de negócios enorme, o creme sobe até o topo e o peso morto afunda. Os crummy devs estão sempre em algum tipo de problema - eles se esquecem de testar seu código antes de fazer o check-in, então eles criam uma quebra, eles 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 para fazê-lo. Eles verificam se alguém é um bom desenvolvedor . A programação é uma atividade de desenvolvimento, mas o desenvolvimento tem muitos outros. Então eles verificam se você está no horário, se suas estimativas são boas, se há muitos defeitos em coisas que você fez no seu sistema de rastreamento de bugs, suas habilidades sociais, comprometimento, comunicação, etc.

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

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

Eu acho que há muito poucas pessoas (sem falar em gerentes) que não tenham uma boa compreensão geral da hierarquia dos desenvolvedores. Todo mundo acha que eles são um desenvolvedor de primeira, as únicas pessoas que não sabem quem são os desenvolvedores ruins são aqueles desenvolvedores ruins. De qualquer forma, se você fosse dar uma volta e 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. Então não há mágica em determinar quem está se saindo muito bem e quem está com desempenho médio ou ruim, etc ... A única pegadinha que os desenvolvedores e gerentes vão discordar são aqueles tipos de vendedores, os barulhentos que soam como se soubessem o que estão falando sobre mas realmente não. A maioria dos gerentes é enganada por eles, mas os desenvolvedores não são. Geralmente, é preciso uma falha épica do vendedor antes que o gerente perceba.

Depois disso, são os preconceitos de seu gerente que determinam sua classificação. Para alguns, a codificação é uma tarefa de nível de entrada, por isso, embora você possa ser excelente em codificação, ela não lhe dará a promoção que você está procurando. Enquanto outros olham para o design ou aspectos arquitetônicos como sendo mais importantes. E outros acreditam que a definição e a coleta de requisitos (por exemplo, análise de negócios) é mais importante. Se você quer saber o que é importante para o seu gerente e não obteve uma classificação de desempenho superior, pergunte a eles o que eu preciso fazer para obter uma classificação de melhor desempenho. Você também aprenderá o que é importante para eles nessa resposta e, então, cabe a você certificar-se de que você se destaca nessas áreas de importância.