MECANISMOS_NOMEADOS
A ciência do ritmo em engenharia: por que comparar velocidade é a métrica errada
3 mecanismos nomeados — «Ela entrega duas vezes mais rápido do que eu — devo não ter perfil para isso» é o tipo de pensamento que os engenheiros de software ensaiam constante
A armadilha da comparação de velocidade é o padrão cognitivo de usar a velocidade de produção visível de um colega — tickets fechados, PRs mesclados, commits enviados — como proxy de sua produtividade geral e então medir o próprio valor contra isso. A pesquisa sobre o framework SPACE estabelece que contagens de atividade como essas representam apenas uma das cinco dimensões independentes da produtividade do desenvolvedor, perdendo sistematicamente contribuições em comunicação, qualidade de revisão de código, mentoria e trabalho de foco sustentado.
Como soa na sua cabeçaO roteiro interno: 'Ela entregou quatro funcionalidades neste sprint e eu entreguei duas — sou metade tão boa quanto ela.' A pesquisa lê isso de forma diferente: você viu quatro PRs e dois PRs; você não viu as revisões de código que ela recebeu e que você fez, a decisão de arquitetura que você discutiu, o engenheiro junior que você desbloqueou, nem as duas horas que cada um de vocês passou em reuniões que não podiam controlar.
O mecanismo do mito do 10x descreve como um achado de um estudo de 1968 com 12 programadores completando uma única tarefa de depuração se tornou uma crença popular amplamente repetida sobre uma classe estável e identificável de desenvolvedor dez vezes mais produtivo que a média. A auditoria histórica de McConnell mostra que a razão original mediu a variância do tempo na tarefa — não a produtividade geral — e nunca foi validada como um traço individual estável, mas circula como se fosse uma lei empírica replicada sobre a capacidade do desenvolvedor.
Como soa na sua cabeçaO roteiro interno: 'Talvez eu simplesmente não seja um dos engenheiros 10x — algumas pessoas são feitas de forma diferente.' A pesquisa lê isso de forma diferente: o '10x' foi um número de uma tarefa medida em um estudo de 1968. Não há evidência validada de que descreva uma propriedade individual estável e inerente em vez de um instantâneo da variância do tempo na tarefa sob um conjunto de condições.
A espiral de excesso de trabalho e esgotamento descreve o padrão em que a crença de que horas mais longas sinalizam dedicação e capacidade leva os engenheiros a ultrapassar limites sustentáveis, o que aumenta as taxas de erro e reduz a qualidade do código, o que aumenta a pressão para trabalhar mais para compensar, acelerando o esgotamento. O mapeamento sistemático de 74 estudos de esgotamento de Tulili, Capiluppi e Rastogi encontrou o excesso de trabalho como o antecedente mais consistentemente citado do esgotamento do engenheiro de software na literatura.
Como soa na sua cabeçaO roteiro interno: 'Se eu colocar as horas extras agora vou provar que sou sério e eventualmente vou alcançar os outros.' A pesquisa lê isso de forma diferente: a literatura sobre esgotamento do engenheiro de software constata que o excesso de trabalho sustentado é o que produz o esgotamento, a degradação da qualidade e a saída da área — não o alcance que promete.