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).