>
Desde que estou no software, fala-se do programador 10x. Estas são as pessoas que você quer resolver seus problemas; eles o farão em 1/10 do tempo, com 1/10 do número de linhas de código. Eles soam muito bem.
Mas o termo veio de? Será que eles existem? E mesmo que existissem, você gostaria de ser um de qualquer forma?
Tom DeMarco e Tim Lister têm, desde 1977, conduzido os “Jogos de Guerra de Codificação”. Esta é uma pesquisa pública de produtividade na qual equipes de implementadores de software de diferentes organizações competem para completar uma série de benchmarks em tempo mínimo com o mínimo de defeitos. Eles tiveram a participação de mais de 600 desenvolvedores.
O que eles aprenderam?
- A escolha da linguagem de programação teve pouco impacto – quer fosse COBOL/Fortran ou uma linguagem de alto nível como Pascal a propagação dos resultados é praticamente a mesma. A única exceção foi a linguagem assembly.
- Não houve correlação entre experiência e desempenho, exceto que aqueles com menos de seis meses de experiência com uma linguagem não fizeram tão bem quanto os outros.
- Os desenvolvedores de soluções com defeito zero não pagaram nenhuma penalidade de desempenho por fazer um trabalho mais preciso (na verdade, eles levaram um pouco menos de tempo!).
Eles descobriram que havia enormes diferenças entre as organizações. A melhor organização trabalhou 11,1 vezes mais rápido do que a pior. Além disso, as que trabalharam mais rápido desenvolveram códigos que passaram no teste de aceitação. Caso encerrado?
Bem, não é bem assim. O estudo segue então para correlacionar o ambiente de trabalho (que é diferente em toda a organização) com o desempenho. Acontece que o grupo de espaço de trabalho silencioso, privado e dedicado teve um desempenho significativamente melhor.
Lesson learnt – get your work environment right first before you start to worry about whether you can find 10x developers or not!
O Programador de Produção Negativa Líquida
Schulmeyer observa que alguns desenvolvedores são “programadores de produção líquida negativa” (NNPP), ou seja, eles produzem tantos defeitos que removê-los da equipe aumenta a produtividade. Isto é quase o oposto do programador 10x – é possível ter alguém na equipe que o piora.
Se existem produtores negativos (- Desenvolvedores Nx?) então é claramente possível ter um programador 10x (matemática à parte).
Não é o maior argumento para o programador 10x, pois não? Se eu pedisse a uma criança da escola para se juntar a uma equipe, eles seriam um produtor net-negativo? Provavelmente, se eu os deixasse sentar em um canto e bater em algum código (e se algum como eles podem empurrar para a produção!). Se você é o tipo de empresa que deixa as pessoas sentarem num canto, não dá feedback e as deixa empurrar para a produção, então eu acho que você provavelmente merece ter NNPPs na sua equipe!
Mais realista, espero que em qualquer empresa normal, se você empregar alguém, você vai dar a ele todo o suporte necessário para que ele seja incrível em seu papel (revisão do código, feedback, um mentor, análise automática do código para feedback, materiais de aprendizagem, etc.)
Acho que ainda é possível que você possa acabar com um NNPP, mas suspeito que seja altamente improvável. Esta certamente não parece ser a melhor história para a existência de 10x desenvolvedores.
Estudos experimentais exploratórios comparando performance de programação online e offline
Sackman, Erikson, Grant publicou um artigo em 1968 chamado “Estudos experimentais exploratórios comparando performance de programação online e offline”. Uma das citações no final é em torno de diferenças individuais e os estudos “revelaram grandes diferenças individuais entre alto e baixo desempenho, muitas vezes por uma ordem de magnitude”. Poderá ser este o artigo mágico que descreve essa diferença de 10x?
Paga para ler todo o estudo e colocar algum contexto em torno disso. Em primeiro lugar, estes testes estavam comparando tanto o desempenho da caneta e do papel quanto o desempenho online usando um IBM AN/FSQ-32. Os programadores escreveram o seu código (seja em caneta/papel para dar a um operador, ou directamente no computador) usando uma linguagem chamada STC (um derivado de ALGOL).
Tinham duas tarefas a resolver, a primeira era interpretar equações algébricas com uma única variável dependente. Eles receberam o trabalho de Samelson e Bauer para ajudar a implementar a solução. Uma imagem do papel é mostrada abaixo:
A segunda tarefa era resolver um labirinto de 20×20 que tem exatamente um caminho. O labirinto foi descrito por uma tabela de 400 elementos onde cada entrada continha informações sobre as saídas de cada célula. Nenhum material de apoio foi fornecido para este desafio. A resolução do labirinto é um fascinante espaço para problemas e eu adivinharia que aqueles que completaram um curso de teoria gráfica recentemente tiveram uma grande vantagem!
Conhecendo estas tarefas, não me surpreende que haja grandes diferenças individuais. Em 1968, a engenharia de software nasceu apenas como uma disciplina. As tarefas são de natureza matemática e não está claro quais foram os antecedentes dos participantes. Certamente favoreceria aqueles que fizeram cursos de matemática de nível superior.
Acho que a pessoa 10x que você encontrará a partir disto é dotada de talento para resolver estes problemas. Posso acreditar que no espaço de problemas de “resolver um labirinto + equações lineares” pode haver um desenvolvedor 10x, mas é difícil que isso se transfira para qualquer outro domínio.
Devo ser um desenvolvedor 10x?
Provavelmente. Mas provavelmente 10x melhor em escrever código.
Existe uma discussão muito melhor sobre as metodologias de pesquisa por trás do mito do desenvolvedor 10x neste excelente livro. Mesmo que um desenvolvedor 10x exista, você provavelmente não deveria aspirar a ser um; mesmo que você possa implementar código perfeitamente na primeira vez, você provavelmente descobrirá que estava resolvendo o problema errado em primeiro lugar.
Se esses estudos fossem verdadeiros, a engenharia de software avançou (pelo menos no meu domínio de desenvolvimento de produtos).
Nos velhos tempos, nós poderíamos fazer um único grande lançamento por ano, ter alguns requisitos e passar o ano implementando-os. Isto mudou para uma abordagem ágil onde há um ciclo contínuo de elicitação, imaginação, implementação e verificação. Neste modelo, implementação não é (geralmente) o gargalo de gargalo
Uma hora salva no não gargalo é uma miragem. (Eliyahu Goldratt)
Então o que você deve fazer em seu lugar? Bem, concentre-se em ser mais valioso para o seu negócio. Você pode:
- Identificar problemas valiosos para o seu negócio?
- Desenhar uma solução que as pessoas possam usar?
- Reagrupar feedback para avaliar se é valioso?
- Escrever software que faça uma verdadeira diferença para pessoas reais?
- Focalizar nos problemas reais em vez de nos interessantes?
- Criar membros na equipa para serem espectaculares?
E um milhão e uma coisas que são mais valiosas do que escrever código perfeito em tempo recorde (ver em forma de t!).
Isto não quer dizer que a codificação não seja importante. A codificação é importante! O código é lido 4x mais do que é escrito, então se você escrever fácil de raciocinar sobre código, então ele compensa dramaticamente no futuro (talvez haja uma história 10x em algum lugar, mas eu vou deixar isso para outro dia). Investir tempo na sua arte (seja código ou design ou gerenciamento de projeto) é uma obrigação, mas lembre-se que sua arte não existe isoladamente e existe para servir um objetivo maior.
Não se concentre apenas em ser o melhor desenvolvedor do mundo, concentre-se no cenário maior (lembre-se Produto sobre Projeto!). Aprenda um amplo conjunto de habilidades (especialmente aquelas relacionadas às pessoas) e você será muito mais valioso e muito mais próximo de um verdadeiro “desenvolvedor” 10x.