O que define um bom desenvolvedor de software?

Publicado em Setembro 6, 2017

Existem centenas de técnicas de entrevista, milhares de ferramentas, cada uma com um conhecimento necessário correspondente para trabalhar, incontáveis algoritmos “clássicos” e uma miríade de diferentes tipos de projetos para tentar avaliar um Desenvolvedor de Software. No entanto, não é fácil, nem formal ou matematicamente, separar um bom desenvolvedor de um mau. Porque?

Como sempre, não há uma resposta fácil para essa pergunta. A principal razão para isso é, talvez, que não sabemos o que um Desenvolvedor de Software faça de fato. A criação de software não é uma tarefa mecânica e, mesmo que fosse, escrever código, em alguns casos, não é a principal atribuição de um desenvolvedor de software.

Até mesmo identificar esse problema é uma questão de debate. Dizer que a principal função de um Desenvolvedor de Software não é desenvolver software certamente levantará uma discussão, e posso entender isso. Mas acho que o verdadeiro problema é que, mesmo que concordemos com isso, não sabemos o que realmente significa “desenvolver software”. É escrever um programa? É encontrar a ferramenta certa para a tarefa? É o debug de um sistema? E, se você responder “Todas as opções acima” … bem, como você mede cada uma delas? Se você não consegue medir, não saberá dizer categoricamente quem é um bom desenvolvedor.

Níveis de educação e conhecimento formal

Uma das maneiras mais básicas de filtrar candidatos é avaliar seus conhecimentos formais de ciência da computação. É quando fazemos um teste perguntando coisas sobre a complexidade do algoritmo ou questionamos algum problema clássico de ordenação.

Isso falha em vários níveis. Mesmo que o conhecimento deles seja bom, há muitos empregos em que o candidato nunca usaria tal conhecimento na empresa. Por que se preocupar em perguntar sobre o algoritmo de quick-sort se a atribuição principal será um serviço CRUD simples? Além disso, se não é uma questão urgente, por que você não pode contratar e ensinar?

Esse tipo de avaliação traz o pior tipo de entrevista: “Escreva no quadro branco um merge-sort”. Se você não conseguiu memorizar todas aquelas 28 “perguntas clássicas da entrevista em código”, você já falhou.

Eu realmente odeio a ideia de que você precisaria ler um livro apenas para passar em uma entrevista. E, o pior de tudo: mesmo que o seu candidato consiga resolver esses problemas à queima-roupa, não é garantido que ele terá um bom desempenho com a stack e o conjunto de ferramentas do seu ambiente.

Conhecimento de ferramentas

Todo desenvolvedor de software que se preze tem alguma stack ou ferramentas com as quais se sente confortável. Melhor ainda, eles deveriam ter muitas ferramentas em seu conjunto de habilidades, porque isso evita a armadilha comum de “quando sua única ferramenta é um martelo, tudo parece um prego”.

Mas, como eu disse antes, devemos sempre ter cuidado com a ferramenta certa para o trabalho certo. Além disso, depender apenas de ferramental, você perderá alguns bons profissionais apenas porque eles não conhecem as ferramentas usadas em seu ambiente.

E, depois de tudo isso, como você mede se um desenvolvedor de software sabe como usar alguma ferramenta? Eles podem ter aprendido, lido em algum lugar, mas podem falhar em usá-la em um problema do mundo real. Voltamos ao “o que você realmente faz?”.

Diferença de performance em diferentes empresas

Outro problema da mensuração é que um bom desenvolvedor de software na empresa A pode ser um mal desenvolvedor de software na empresa B, mesmo que essas empresas compartilhem a mesma stack tecnológica. Existem inúmeras maneiras de uma empresa se diferenciar da outra, e cada uma delas pode fazer o desempenho de um desenvolvedor de software variar.

Pegue um desenvolvedor “Bom” de uma grande empresa. Ele deve ser capaz de sobreviver à burocracia e complexidade de comunicação para trazer suas habilidades de resolução de problemas para o jogo. Tal profissional pode não ser o programador mais brilhante, mas será capaz de prosperar e trazer resultados em tal ambiente.

Por outro lado, um “Bom” desenvolvedor de uma pequena empresa provavelmente precisará ser rápido no fornecimento de funcionalidade. Ele pode não construir os sistemas mais sustentáveis no longo prazo, mas certamente será a melhor aposta neste cenário.

(ambos os cenários são completamente hipotéticos. Qualquer semelhança com a realidade é pura coincidência)

Se trocarmos os desenvolvedores de lugar, há uma grande possibilidade de que serão rotulados como desenvolvedores “ruins” em cada empresa, mesmo com ferramentas, stack e conhecimento técnico iguais. Pior ainda, há uma grande chance de que ambos não vão tolerar as condições de trabalho.

(claro, poderíamos encontrar o tão famoso “desenvolvedor rockstar” que pode operar em todos os níveis de qualquer empresa de qualquer tamanho … mas é um peixe realmente raro, se é que existe)

Equipes

Depois de falharmos em medir o que é um bom desenvolvedor de software, alcançamos o próximo nível de dificuldade: geralmente trabalhamos em equipes e, embora as equipes sejam a maneira certa de construir algo sustentável, também é uma das maneiras mais fáceis para ir “abaixo do radar”. Se sua equipe de quatro desenvolvedores está apresentando um bom desempenho, como você pode saber qual deles tem um ótimo desempenho e quais são mais pobres? Isso é necessário por vários motivos, que vão desde o treinamento até as promoções e aumentos.

Este é especialmente difícil. Se um dos desenvolvedores compromete menos código (métrica ruim, eu sei), é porque ele não está funcionando direito ou é porque ele está ajudando e emparelhando com os outros? Pior ainda, ele está heroicamente interagindo com as partes interessadas e quebrando os recursos em tarefas técnicas? Ele está corrigindo o pipeline de entrega? Ou ele é … ruim? (alguns deles são realmente mensuráveis, eu sei, mas em alguns casos não é tão simples).

Além disso, as equipes são seres organicamente complexos. O que torna uma equipe boa não é facilmente definível (provavelmente tão difícil quanto definir um bom desenvolvedor de software), e os membros da equipe que têm um desempenho muito bom em um podem ser a desvantagem em outro. Isso significa que este jogador foi mau o tempo todo, ou isso significa que ele não se encaixa no novo ambiente? Como você pode responder a essa pergunta?

O que faz um desenvolvedor de software afinal?

Uma infinidade de coisas, na verdade.

Em ambientes menores (principalmente startups), um desenvolvedor de software geralmente desenvolve e coloca em produção diversas coisas diferentes. Quando se está tentando lançar algo rápido e sua base de clientes é menor, seu principal problema é obter novas funcionalidades e melhorar seu produto o mais rápido possível. Provavelmente, seus problemas de produção não consumirão tanto seu tempo, e será possível apagar os incêndios enquanto mantém estimativas e entregas. Com essa experiência, um desenvolvedor será medido por suas tarefas indo para a coluna de “pronto” e em sua capacidade de resolver os problemas de produção rapidamente, e de forma que não interfira na velocidade dos projetos.

Em empresas de médio porte (eu traço a linha em 100 funcionários), os desenvolvedores provavelmente começarão a perder velocidade. Na maioria dos casos, será preciso contratar pessoal especializado em operação para as interrupções e recuperações dos serviços para que possa manter os desenvolvedores focados na codificação. Outros cargos específicos também serão necessários: pessoas que possam priorizar as melhores tarefas, analistas de negócios para entender ideias e planejar novos rumos, etc. Como o ambiente se tornou mais complexo, sua equipe precisará, além das habilidades de código óbvias, começar a se comunicar efetivamente com todas essas áreas. Isso fará com que a equipe de desenvolvimento comece a participar de reuniões para dar e explicar estimativas, e também ajudar a priorizar as tarefas com o intuito de organizar as entregas e negociar escopos. Da codificação e do combate a incêndios, agora você precisa de pessoas que possam ajudar mais de perto os negócios, lubrificando os motores do todo. Sua equipe de desenvolvimento também precisará interagir com a operação e construir soluções em conjunto para que o ambiente de produção permaneça sólido e estável.

Para as grandes empresas, pegue os problemas de médio porte e torne-os ainda maiores, e acrescente os famosos sistemas legados no cenário. Sua equipe de desenvolvimento precisará se tornar muito boa em documentação e comunicação e precisará aprender a lidar com a coordenação da entrega de funcionalidades, a criação de um processo para organizar muitas equipes trabalhando na mesma base de código e a complexidade geral de todos os sistemas trabalhando juntos. Em tal ambiente, você pode ver a equipe de desenvolvimento trabalhando basicamente em toda a empresa: auxiliando nas decisões de negócios, estimando os entregáveis e organizando a ordem de ataque às tarefas.

Ah, e também criando novas funcionalidades.

Dada a enorme mutabilidade da descrição do trabalho, a pergunta volta.

Como medir?

É uma gama de possibilidades tão ampla que é quase impossível julgar matematicamente quem é bom ou mau desenvolvedor. João pode ter menos commits, mas isso pode ser porque ele está ensinando os menos experientes. Julia falha na maioria de suas estimativas, mas é a mais rápida para resolver problemas em produção. Bueno é capaz de quebrar as solicitações da área de produto em histórias de bom tamanho. Maria é a codificadora mais criativa. Paulo é o melhor revisor de código.

A única maneira que funcionou na minha experiência, tanto para medir os bons desenvolvedores quanto para ajudá-los a melhorar, foi o feedback constante, tanto dos pares quanto da gestão.

Feedback

Quando se trata de feedback, quanto mais próximo melhor. É bom ter o feedback de outra área, é importante ter o feedback de outra equipe, é necessário ter feedback do gestor e é vital ter o de seus pares. É função do gestor coletar esses feedbacks para ser capaz de avaliá-lo e ser capaz de orientar o desenvolvedor para melhorar.

Eu gosto do formato de feedback 360, mas é muito demorado, o que o torna quase impraticável como um loop de feedback constante. Além disso, tal encontro pode ter um impacto negativo em pessoas mais ansiosas, portanto é melhor coletar as informações separadamente.

Para feedbacks entre áreas, uma mensagem ou e-mail é “bom o suficiente”, se você não tiver tempo. Envie uma mensagem e pergunte educadamente sobre a colaboração da equipe. Deixe claro que é para fins construtivos e que neste caso, quanto mais informação, melhor.

Para outras equipes, a mensagem é boa, mas o contato direto é melhor. Faça-lhes as mesmas perguntas e seja claro sobre o objetivo. Faça anotações sobre as opiniões ou problemas levantados.

Dentro da equipe, gosto de dois formatos. Uma aberta, que às vezes é chamada de “Fast Feedback”, onde a equipe se encontra e, em duplas, fala os pontos positivos e os “pontos a serem melhorados” um para o outro. O outro é fechado, a equipe se reúne sem o avaliador e lista os mesmos pontos. Isso é útil para os membros da equipe que são muito tímidos para criticar ou os “gente boa” que, devido às suas habilidades sociais, é difícil apontar problemas cara a cara.

Com todo esse material em mãos, é possível agendar encontros individuais com os membros da equipe e enfrentar os problemas ou parabenizar pelo desempenho. É possível, mesmo dentro de uma equipe, avaliar o desempenho individual. É muito mais pessoal do que números, então sempre há chances de erros e enganos, mas é a coisa mais próxima que você pode obter do desempenho do desenvolvedor no mundo real.