ARQUIVO_DE_PESQUISA
A ciência do ritmo em engenharia
«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 constantemente, geralmente às 23h olhando para um PR pela metade.
VER A PRÁTICA
Transforme um pensamento que esta pesquisa explica em um passo claro.
O PENSAMENTO
“Um bom engenheiro não precisa de tempo de recuperação após trocar de contexto”
SUA RESPOSTA GRAVADA
“Bloqueio tempo de recuperação como se fosse uma reunião—porque reconstruir o contexto é trabalho real, não tempo morto.”
UM PASSO PRIVADO
No seu calendário para a próxima semana, adicione blocos de 'recuperação de contexto' de quinze minutos após cada reunião. Deixe-os privados. No final da semana, observe se bloqueá-los mudou seu tempo real em trabalho profundo.
O que a pesquisa mostra é que essa comparação repousa sobre bases frágeis. A descoberta original do 'programador 10x' veio de 12 pessoas em um estudo de 1968 que mediu o tempo dedicado a uma única tarefa, em condições que têm pouca semelhança com o trabalho de software moderno. Meio século depois, o framework SPACE documentou que a produtividade do desenvolvedor é multidimensional — a velocidade é uma fatia de um quadro muito maior, e as outras fatias costumam ser invisíveis em comparações entre pares. Enquanto isso, um mapeamento sistemático da literatura sobre burnout estabeleceu que a sobrecarga crônica é um preditor confiável do esgotamento do engenheiro, não um sinal de dedicação excepcional. O roteiro antigo — 'trabalhe mais rápido, prove seu valor' — está em contradição com o que as evidências mostram sobre como a boa engenharia realmente é feita.
Como a ciência mudou
- 1968
Sackman, Erikson e Grant publicam o estudo que se tornaria a origem do 'programador 10x': 12 programadores profissionais resolvendo um único problema mostraram uma razão de 28:1 no tempo de depuração e aproximadamente 10:1 no volume de código — achados amplamente citados, mas raramente auditados pelo seu design estreito de tarefa única. ↗
- 2001
A revisão de Magne Jørgensen sobre estudos de variação de produtividade individual constata que a razão entre programadores é real, mas dependente do contexto — estudos medindo diferentes tarefas, linguagens e contextos de equipe produziram razões que variam de 2:1 a mais de 20:1, alertando contra tratar qualquer razão única como universal. ↗
- 2019
Storey e Zimmermann pesquisam 2.000 desenvolvedores da Microsoft e descobrem que o ponto de dor mais comum não é a velocidade de digitação ou o desempenho das ferramentas, mas interrupções e troca de tarefas — chamando atenção para o fluxo de trabalho e o ambiente como grandes alavancas de produtividade invisíveis em comparações de velocidade. ↗
- 2019
Murphy-Hill e colegas no Google publicam achados de que o desempenho individual do desenvolvedor está mais fortemente correlacionado com fatores de equipe e organizacionais — cultura de revisão de código, segurança psicológica, carga de plantão — do que com esforço individual ou velocidade de produção bruta. ↗
- 2020
A revisão de McConnell do estudo original de Sackman/Grant de 1968 rastreia precisamente como o rótulo '10x' migrou para a crença popular: a razão original era sobre tempo de depuração em uma tarefa para 12 pessoas, não produtividade geral — e as repetições subsequentes inflaram e descontextualizaram o achado ao longo de cinco décadas. ↗
- 2021
Forsgren, Storey, Maddila, Zimmermann, Houck e Nagappan introduzem o framework SPACE no ACM Queue: Satisfação e bem-estar, Desempenho, Atividade, Comunicação e colaboração, Eficiência e fluxo — cinco dimensões da produtividade do desenvolvedor, nenhuma das quais se reduz apenas à velocidade. ↗
- 2022
Tulili, Capiluppi e Rastogi publicam um estudo de mapeamento sistemático do burnout em engenharia de software, sintetizando 74 estudos primários: o excesso de trabalho e a alta carga de trabalho emergem como os antecedentes de burnout mais consistentemente relatados na literatura, com engajamento e autonomia como fatores protetores. ↗
O que as pessoas acreditam vs. o que os dados mostram
A crença“O 'engenheiro 10x' é um traço individual real e estável — alguns desenvolvedores simplesmente são feitos para produzir dez vezes mais do que outros.”
Os dadosA revisão de McConnell de 2020 rastreia a razão '10x' a um único estudo de 1968 com 12 programadores completando uma tarefa sob condições controladas. A razão mediu o tempo de depuração, não a produtividade geral — e nunca foi demonstrado que se tratava de um traço individual estável em vez de um instantâneo da variância de desempenho em uma tarefa. ↗
A crença“O engenheiro que entrega mais tickets por sprint é a pessoa mais produtiva da equipe.”
Os dadosO framework SPACE identifica cinco dimensões ortogonais da produtividade do desenvolvedor. Contagens de atividade como tickets fechados são um proxy de apenas uma dimensão (Atividade), e o framework alerta que métricas de uma única dimensão perdem sistematicamente contribuições em comunicação, mentoria, qualidade de código e trabalho em estado de fluxo que não geram artefatos visíveis. ↗
A crença“Trabalhar mais horas é prova de comprometimento e resulta de forma confiável em mais produção.”
Os dadosO mapeamento sistemático de 74 estudos de burnout de Tulili, Capiluppi e Rastogi constatou que o excesso de trabalho e a alta carga de trabalho eram os antecedentes mais consistentemente relatados do burnout do engenheiro de software — não do alto desempenho sustentado. Engenheiros com burnout mostram qualidade reduzida, mais erros e maior rotatividade. ↗
A crença“A velocidade de entrega é a única métrica que realmente importa para avaliar o desempenho da equipe e do indivíduo.”
Os dadosA pesquisa da DORA de 2023 mostra que equipes de alto desempenho otimizam em frequência de implantação, tempo de lead, taxa de falha de mudanças e tempo de restauração — quatro dimensões diferentes. Equipes que maximizam a velocidade em detrimento da estabilidade produzem consistentemente taxas de falha mais altas e tempos de recuperação mais longos, resultando em um rendimento geral pior. ↗
A crença“Se você é mais lento do que seus colegas, significa que você é menos capaz — não que seu contexto é diferente.”
Os dadosMurphy-Hill e colegas descobriram no Google que o desempenho individual é mais fortemente previsto por fatores de equipe e organizacionais — carga de revisão de código, cultura de reuniões, segurança psicológica — do que por esforço individual. Dois engenheiros em equipes diferentes com a mesma capacidade podem mostrar velocidades de produção dramaticamente diferentes por razões estruturais, não pessoais. ↗
TESTE-SE · Quanto você sabe desta ciência?
01 Quantos programadores participaram do estudo de Sackman/Grant de 1968 citado como a origem da afirmação do 'programador 10x'?
A revisão de McConnell de 2020 rastreou o rótulo '10x' a um estudo de 1968 com apenas 12 programadores profissionais completando uma única tarefa. A razão mediu o tempo de depuração, não a produtividade geral, e o pequeno tamanho da amostra e o design de tarefa única raramente eram mencionados quando o achado era citado posteriormente. fonte ↗
02 O que significa o 'S' no framework SPACE?
O framework SPACE de Forsgren et al. significa Satisfação e bem-estar, Desempenho, Atividade, Comunicação e colaboração, Eficiência e fluxo. Começar com satisfação reflete o argumento dos autores de que o bem-estar é tanto uma dimensão da produtividade quanto uma condição necessária para as demais. fonte ↗
03 De acordo com o estudo de mapeamento sistemático de Tulili, Capiluppi e Rastogi, qual foi o antecedente mais consistentemente relatado de burnout em engenheiros de software?
Em 74 estudos primários no mapeamento sistemático, o excesso de trabalho e a alta carga de trabalho foram os principais antecedentes do burnout do engenheiro de software. A revisão também identificou o engajamento e a autonomia como os fatores protetores mais comuns — afastando a ideia de 'trabalhar mais' como estratégia de produtividade sustentável. fonte ↗
04 A pesquisa da DORA sobre equipes de engenharia de alto desempenho mede quatro métricas-chave. Qual combinação está correta?
A pesquisa da DORA estabeleceu a frequência de implantação, o tempo de lead para mudanças, a taxa de falha de mudanças e o tempo de restauração do serviço como as quatro dimensões-chave do desempenho de entrega de software. Essas métricas equilibram intencionalmente velocidade com confiabilidade — equipes que maximizam apenas a velocidade em detrimento das outras três consistentemente têm desempenho inferior no rendimento em nível de sistema. fonte ↗
05 O que Murphy-Hill e colegas descobriram que previa mais fortemente o desempenho individual do desenvolvedor no Google?
Murphy-Hill e colegas descobriram que fatores de equipe e organizacionais — incluindo carga de revisão de código, cultura de reuniões, carga de plantão e segurança psicológica — previam o desempenho individual do desenvolvedor mais fortemente do que esforço individual ou habilidades técnicas sozinhos. Isso significa que dois engenheiros de capacidade igual em equipes diferentes podem mostrar velocidades de produção dramaticamente diferentes por razões estruturais. fonte ↗