Compreender e apoiar as habilidades dos desenvolvedores é algo em que penso muito. Deixe-me explicar por quê.

Primeiro, passei muitas horas da minha juventude aprendendo BASIC em um Commodore 64 (grite para as unidades de memória de fita cassete!) e depois em um IBM “Portable” de 30 libras. Lembro-me de renumerar tão nitidamente minhas linhas de código à mão apenas para perceber que não entendia que havia uma função de renumeração automática e me perguntei por que não tinha aprendido isso antes.

Em segundo lugar, como líder em tecnologia, ao longo de minha carreira, entrevistei centenas de candidatos e vi milhares de currículos. E tive a sorte de trabalhar com equipes de recrutamento incríveis que revisaram centenas de milhares de currículos em meu nome. 

Terceiro, como CEO de uma empresa de software, o sucesso de nossa empresa vive e morre com a força de nossos engenheiros, nossa capacidade de remover os obstáculos à sua eficácia e nossa capacidade coletiva de ajudá-los a crescer em seus conhecimentos e habilidades.

Quarto e finalmente, no último ano deixei de ser apenas um consumidor de código aberto para entender como ele é criado e mantido. E leitor, eu estava. Soprado. Um jeito. A colaboração, a capacidade de completos estranhos de construir algo muito mais do que a soma de suas partes, os níveis coletivos de confiança estão no nível de uma das maiores realizações coletivas da história e certamente entre os principais esforços organizados por voluntários, juntamente com o compartilhamento resultados de experimentos científicos. Então me tornei um grande fã.

Todas essas experiências me levaram a pensar—ok, obcecado—como melhorar a habilidade dos desenvolvedores.

A importância – e o desafio – de medir a habilidade do desenvolvedor

Para melhorar qualquer coisa, o primeiro passo é ser capaz de medi-la com precisão. E sim, “exatamente” aqui vem com uma grande ressalva, mas voltaremos a isso em um momento…

Se for possível medir a habilidade do desenvolvedor de forma eficaz, então:

  • Indivíduos que estão interessados ​​em seu próprio crescimento de habilidades e conhecimento (ou seja, quase todos os desenvolvedores que eu já conheci), têm um roteiro para entender onde eles podem se concentrar para chegar ao próximo nível
  • Os gerentes de contratação e os recrutadores podem combinar com eficiência os candidatos às funções certas. Isso é bom para eles, suas organizações e seus candidatos – ninguém ganha quando alguém está sub ou superqualificado para o cargo. Anos de experiência com uma tecnologia – especialmente aqueles irreais como “15 anos de experiência em React” – nem sempre contam a história.
    • Em particular, os engenheiros precisam de uma maneira melhor de transmitir seu nível de conhecimento em muitas linguagens e estruturas. Currículos que listam “AWS / TypeScript / Terraform” e dez outros itens não são vistos como confiáveis ​​pelos gerentes de contratação – não há contexto suficiente para determinar as capacidades de um candidato.
  • As organizações de software podem personalizar efetivamente as oportunidades de desenvolvimento profissional para cada engenheiro.
  • Por fim, os projetos de código aberto podem combinar melhor seus projetos com os desenvolvedores. Em meu envolvimento com projetos de código aberto, observei que os recém-chegados precisavam de um nível mínimo de habilidades e conhecimento para contribuir com código de maneira otimizada – tanto para os ocupados mantenedores de código aberto e seu projeto quanto para seu crescimento e jornadas profissionais. Quando as habilidades são combinadas com os requisitos, todos os colaboradores, mantenedores e projetos ganham.

Esses são os benefícios de medir a habilidade do desenvolvedor. Agora vamos voltar ao desafio de medir a habilidade com precisão . Não é fácil.

O código é um ofício, não uma competição, e isso significa que muitas das maneiras pelas quais medimos o sucesso ou a melhoria simplesmente não são aplicáveis ​​aos engenheiros de software.

Bater mais home runs este ano? Você está aprendendo a bater melhor (ou as bolas da Major League Baseball estão estranhas este ano… história para outra hora.).

Empresa obteve mais lucro este ano? A equipe pode ter aprendido coletivamente como administrar um negócio mais eficaz.

E quanto ao código… um desenvolvedor adicionando mais linhas de código a um repositório este ano? Pode ser uma boa ideia, pode ser uma má ideia, mas com certeza não é um bom indicador de habilidade.

Não, para desenvolvedores, o melhor indicador de habilidade do desenvolvedor é a avaliação subjetiva de outros engenheiros qualificados. Isso é inerente à definição do ofício.

E com isso em mente, construí a Matriz de Habilidades do Desenvolvedor para ajudar.

Uma matriz de habilidades e habilidades do desenvolvedor

A Matriz de Habilidades do Desenvolvedor é uma estrutura estruturada e subjetiva das características de codificação e não codificação de engenheiros de software, acessível a tecnólogos e não tecnólogos.

Deixe-me explicar:

  • Estruturado = há cinco níveis de Habilidade de Desenvolvedor: Iniciante, Iniciante Avançado, Intermediário, Avançado e Especialista
  • Subjetivo = baseado na sabedoria e conhecimento dos engenheiros. Ele pode ser administrado pelo próprio engenheiro, seus colegas ou seu gerente ou instrutor.
  • Características de codificação e não codificação = a Matriz inclui níveis de habilidade para habilidades básicas de software para linguagens e estruturas, incluindo estruturas de dados, estilo e semântica e outras habilidades gerais. Mas também inclui níveis para infraestrutura , incluindo controle de origem e gerenciamento do ciclo de vida do aplicativo. E a terceira categoria para as habilidades básicas/transversais de comunicação, incluindo dar e receber feedback. Quase toda codificação é um esforço de equipe e, portanto, a comunicação sobre o código com outras pessoas é fundamental para o sucesso do projeto.
  • Acessível a tecnó