Níveis de habilidade quantificado​​s para desenvolvedores

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ólogos e não tecnólogos = é trabalho dos tecnólogos usar sua sabedoria e julgamento para atribuir a si mesmos ou a sua equipe níveis de habilidade. Depois de concluídos, ter níveis claros torna os resultados instantaneamente compreensíveis para outras pessoas no ecossistema – sim, estou pensando nas milhões de horas que os recrutadores gastam examinando currículos, tentando tornar suas vidas um pouco mais fáceis.

Exemplos de dois níveis:

Um desenvolvedor iniciante está apenas começando e tem pouco ou nenhum conhecimento ou habilidade de codificação. Eles podem ser desenvolvedores autodidatas que estão apenas começando, ou estudantes de programação ou ciência da computação em seus primeiros dois anos de estudo.

Com relação às habilidades básicas de software, eles podem implementar soluções gananciosas para problemas de algoritmo, mas perdem casos de canto. Eles têm pouca ou nenhuma compreensão de teste de unidade. Eles estão familiarizados com um pequeno número de frameworks, alguns apenas pelo nome.   

Iniciantes avançados fornecem mais valor do que exigem de uma equipe de desenvolvimento. A maioria dos desenvolvedores que codificam há alguns meses a alguns anos estão nessa categoria.

Em habilidades básicas de software, eles podem implementar soluções básicas que podem não ser ótimas e capturar casos simples de esquina. Eles construirão testes se atribuídos, mas precisam de padrões para construir. Eles estão fortemente familiarizados com pelo menos um framework.

Eu acredito muito em matrizes, também conhecidas como estruturas, também conhecidas como rubricas.

Pense no exemplo das rubricas de proficiência em linguagem humana. Saber seu nível de inglês, espanhol ou qualquer um dos mais de 7.100 idiomas da Terra (!) para o próximo nível. Aqui está um exemplo de proficiência linguística, o Quadro Europeu Comum de Referência para Idiomas . A aprendizagem de um idioma começa com A0, Absolutely No Knowledge, e pode progredir por sete níveis totais, até C2, Advanced Native Speaker.

Depois de decidir sobre um formato de matriz, tive que determinar os níveis e categorias corretos. Cinco níveis pareciam o equilíbrio certo entre significativo (o que levaria a mais níveis) e acionável (o que exige menos). 

Então eu precisava criar categorias. É claro que precisava haver uma categoria para habilidades básicas de software … mas eu queria fornecer uma visão um pouco mais ampla também. A infraestrutura é muito importante, especialmente o lado inicial da Matrix: um codificador pode vir da universidade como um Iniciante Avançado para uma linguagem de software, mas não tem ideia do Git. Essa pessoa não está pronta para contribuir com código para um projeto de código aberto (mas pode ficar pronta rapidamente).

Finalmente, a comunicação — incluindo a capacidade de dar e receber feedback por meio de revisões de código e outros métodos — é um componente essencial da capacidade de um engenheiro de ter sucesso profissional e contribuir com sua equipe. Eu queria isso na rubrica especialmente para que os engenheiros pudessem obter feedback adequado sobre suas habilidades de comunicação de seus gerentes e colegas. 

Depois que a estrutura básica foi montada, o Matrix passou por muitas, muitas revisões por meio de discussões e edições de linhas com tecnólogos apaixonados pelo ofício de codificação. Os pontos fortes desta Matriz devem-se às suas contribuições; os defeitos são todos meus.

E uma Matrix como essa pode, na melhor das hipóteses, estar apenas parcialmente correta na primeira versão e, portanto, pode ser usada livremente e melhorada pela comunidade como um projeto de código aberto AGPL-3.0 .

Colocando a Matriz de Habilidades do Desenvolvedor para funcionar

Há algumas maneiras de usar a Matriz de Habilidades do Desenvolvedor para avaliação inicial :

• Autoavaliação : Os engenheiros devem aplicar seu melhor julgamento a si mesmos. Mesmo para desenvolvedores iniciantes, vale a pena fazer isso. Uma das habilidades fundamentais da engenharia é desenvolver as próprias habilidades de estimativa e, portanto, não há melhor lugar para começar do que estimar as próprias habilidades.
• Avaliação por pares : os engenheiros pedem a seus pares a perspectiva de suas habilidades. Como qualquer área subjetiva de medição, mais perspectivas são melhores do que uma para triangular – embora isso não signifique que a opinião de cada pessoa deva ter o mesmo peso.
• Avaliação do gerente/instrutor : Chefes e professores de codificação aplicam seu próprio julgamento para avaliar seus funcionários/alunos.
• Avaliação de especialistas : Observadores altamente treinados realizam avaliações independentes de codificadores por meio de entrevistas qualitativas e revisões de código (no sentido informal). Eu não tentei isso ainda, mas a evidência é forte de outros ofícios que poderia ser uma das maneiras mais poderosas e eficazes para uma organização fazer isso.

Com todos esses métodos, a variação é sua amiga. O que quero dizer com isso?

Na autoavaliação, se você se der o mesmo nível para todas as nove subcategorias, é provável que você não consiga ver claramente a variação em sua própria habilidade. A única exceção seria um desenvolvedor totalmente novo, que poderia ser Iniciante em todos os níveis.

Na avaliação de gerente/instrutor, se todos os membros de sua equipe também tiverem a mesma pontuação geral, você provavelmente não verá a variação entre os indivíduos.

Em ambos os casos, se você encontrar consistência em todos os aspectos, traga uma segunda, terceira ou quarta pessoa para calibração.

Como se mover entre os níveis

Uma vez que você pode avaliar a habilidade, então você pode trabalhar para aumentá-la.

Existem três categorias de métodos para melhorar a habilidade do desenvolvedor: mais prática, mais feedback e mais alongamento.

Mais prática . Talvez você já tenha ouvido falar do famoso estudo de dois grupos de oleiros , um encarregado de fazer grandes vasos e os outros com o maior número possível de vasos. No final, o grupo focado em quantidade também criou potes de maior qualidade.

Como um ofício, a codificação fica melhor com mais experiência. Portanto, os engenheiros que desejam melhorar devem encontrar o maior número possível de oportunidades para codificar.

Essa é uma das razões pelas quais sou tão apaixonado pelo código aberto – é uma oportunidade 24 horas por dia, 7 dias por semana, 365 dias por ano para continuar trabalhando em seu ofício em domínios que você gosta.

As equipes de engenharia também devem estar hiper focadas na remoção de bloqueadores para os engenheiros que realmente codificam. Quantas reuniões eles têm? Quanto tempo demoram as construções? Fique de olho no que está impedindo os desenvolvedores de realmente trabalhar em seu ofício.

Nota lateral: mencionei acima que medir a quantidade de código como linhas de código não é uma boa maneira de avaliar a habilidade do desenvolvedor; no entanto, é uma maneira confiável de aumentar a habilidade.

Mais comentários . A avaliação subjetiva da habilidade de um engenheiro (incluindo as categorias não codificantes) é um dos melhores aceleradores de crescimento.

Felizmente, o desenvolvimento de software tem um método embutido para fornecer esse feedback: revisões de código. As equipes devem tratar as revisões de código com a maior reverência – priorizando o tempo de revisão de código em vez de uma nova codificação, reconhecendo ótimos revisores de código, estabelecendo o tempo e a estrutura para revisões adequadas.

As revisões de código devem ser complementadas por treinamento prático em comunicação – dando e recebendo feedback. A maioria dos humanos não sabe naturalmente dar ou receber feedback bem… é uma habilidade também. 

Mais alongamento . Não se trata de fazer mais ioga. Embora eu recomende!

Alongar é trabalhar em tarefas que não são muito fáceis e um pouco difíceis (mas não muito difíceis). Grite para Yerkes e Dodson , descanse em paz. 

Se o trabalho é muito fácil, perde o interesse.

Se o trabalho é muito difícil, leva à “zona oprimida” ou à “zona de desamparo”.

Bons líderes e gerentes comunitários estão constantemente reavaliando os níveis de habilidade de seus colegas e encorajando-os a enfrentar o próximo desafio.

Aprendendo mais e participando

A liberação desta Matrix é apenas o primeiro passo. Eu adoraria ter sua ajuda na jornada.

1. Use os padrões da Matriz de Habilidades em seus currículos, portfólios e entrevistas. Lembre-se de que a arte da codificação é baseada na confiança – seja o mais preciso possível. Tente encontrar uma ou duas pessoas em quem você confie, talvez um gerente anterior ou um mentor, para revisar seus resultados para calibração. 
2. Você avalia manualmente suas habilidades ou pode instalar um Discord Bot de código aberto que avaliará suas habilidades, ou pode ingressar em nossa comunidade Discord e usar o Discord Bot aqui.
3. Aplique os níveis de habilidade a si mesmo para onde suas habilidades estão atualmente. Por exemplo, para ser um Iniciante Avançado, você já deve estar atuando no nível Iniciante Avançado.
4. Lembre-se, é provável que você esteja em níveis diferentes para habilidades diferentes. Talvez você seja avançado em habilidades básicas de codificação para JavaScript, intermediário para React e iniciante avançado para comunicação. Não tenha medo de descrever todas as suas capacidades — ter níveis diferentes é mais honesto e mais confiável.
5. Dê-nos feedback sobre como pode ser melhor. Você pode responder aqui, criar problemas no GitHub ou se juntar a nós em nosso servidor Discord.
6. Ajudar! Queremos criar versões de código aberto da avaliação para o Slack, a Web e outras ferramentas. Faça um ping em nosso canal de contribuidor no Discord para ser voluntário.

Mal posso esperar para ver o que você pensa e como usá-lo. Avance!