Como formar um programador 10x

Luca Bastos luca.bastos@concretesolutions.com.br

Agile Brazil 2011 Fortaleza, CE

A ma ior r i queza do homem ���é a sua i n comp le tude . ���Nesse pon to sou aba s t ado. ���Pa l av r a s que me ace i t am como sou - eu não ace i to. ���

Não agüen to se r apenas um su j e i to que abre por t a s , ���que puxa v á l vu l a s , que o lha o re lóg io, ���que compra pão à s 6 hora s da t a rde , ���que va i l á fo r a , que aponta l áp i s , ���que vê a uva e t c . e t c . ���

Perdoa i ���Mas eu p rec i so se r Out ros . ���Eu penso renovar o homem usando borbo le t a s . ���

Manoe l de Barros

Quem sou:

Desenvolvedor do tempo da Carochinha, ávido ���leitor e praticante sempre interessado em ���metodologias de desenvolvimento, ���

desde antes de surgirem programação modular, programação estruturada e todas as demais até���os dias de hoje.

Meninos, eu vi. E vivi.

Onde trabalho: http://www.concretesolutions.com.br/

A Concrete tem 10 anos com um portfólio de clientes ���bem variado no Brasil e no exterior. No início a maior ���demanda do mercado era para soluções de integração e ���assim foi natural a parceria com os grandes players como Oracle, Red Hat, etc. ���

Atualmente a diversificação é bem grande e temos também���ótimos projetos nas áreas de cloud, mobile, web e lean���startups de tecnologia.

Praticamos e pregamos o desenvolvimento ágil desde 2007. ���Hoje temos 56% do faturamento usando Scrum e Kanban e ���só 12% de projetos fechados.  

“Design and programming are human activities; forget that and all is lost.” ���

Bjarne Stroustrup���The C++ Programming Language, 2nd Ed, Section11.1, pág.363

Arbitrariamente vou definir um programador 10x como aquele que sem ser gênio, tem pelo menos um pouco das seguintes qualidades:

-  inteligente (e com bons princípios éticos),

-  personalidade que alie GTD a criatividade e mais ���boa interatividade com time,

-  sabe programar e conhece as tecnologias do ���projeto ���(melhorar aqui é o foco desta apresentação)

Veremos o que fazer para elevar o nível de um ���programador iniciante

e como criar condições de um dia ele vir a ser���um programador 10x.

Você conhece um programador 10x?

Melhor dizendo, ���

reconhece um programador 10x?

Você contrataria alguém como ���os personagens das fotos seguintes?

Ops...

Desculpa aí Milfont ...

Origem do meu interesse���no tema da apresentação Ligue djá

Segundo o prof. Robert Glass, no livro de 2002���Facts and Fallacies of Software Engineering

Fato 1: O fator mais importante no trabalho com software���é a qualidade dos programadores.

Fato 2: A diferença entre os melhores e os piores ���programadores pode ser de até 28 vezes.

A diferença de produtividade entre programadores���já foi motivo de preocupação de estudiosos como ���Bohem, De Marco, Spolsky e outros.

Steve McConnell também discute o que é um ���programador 10x e se é viável medir variações na produtividade

Ver último capítulo de Making Software, What���Really Works, and Why We Believe It, O’Reilly 2011

Origem do termo programador 10x

Segundo um estudo de 1968 (ver *) ���

Diferenças entre o melhor e o pior entre programadores com 7 anos de experiência,

Tempo para “codar” 20x Tempo para debugar 25x Tamanho do código 5x Tempo de execução do código 10x

* Making Software, What Really Works, cap.30, What Does 10x Mean? Steve McConnell

Segundo o mesmo McConnell (*), o tal estudo tem falhas���porque compara resultados de programadores usando���linguagens de baixo nível com outros usando linguagens���de alto nível

Tempo para “codar” 20x

Tempo para debugar 25x Tamanho do código 5x Tempo de execução do código 10x

* Making Software, What Really Works, cap.30, What Does 10x Mean? Steve McConnell

Porém McConnell (*) repara que a diferença entre���os melhores e os piores pode ser considerada como���10x

Tempo para “codar” 20x

Tempo para debugar 25x Tamanho do código 5x Tempo de execução do código 10x

10 X

Escolhi usar o termo 10x porque meu conceito de���10x está mais para os bons que podemos formar ���do que para os pontos extremos excepcionais que ���poderiam ser os tais 28x.

Mas eu conheço muitos bem acima do 10x

Chegaram lá por diversos motivos dentre eles ���qualidades pessoais acima da média

Vamos ver alguns que quase todos conhecem:

30x

Não é com estes que estou preocupado

É com os novos que contrataremos

E supondo que nossos iniciantes são inteligentes, ���falarei sobre o que fazer para que se tornem 10x���em menos tempo

#Fatos

Atualmente está difícil contratar programadores

O mercado está aquecido e há poucos disponíveis

Mais fácil contratar iniciantes e treiná-los até o���nível médio da equipe

Desafio número 1:

Dar condições para o iniciante virar bom ���programador continuando sendo um ser humano ���(sem arrogância).

Opinião do Joel Spolsky: ���

Contrate um super star caso queira um produto ���acima da média.

Mas todo mundo conhece um super programador ���que ninguém quer na equipe. ���

Um super piloto de caça nem sempre se sujeitará ���as normas de segurança de um avião de carreira ���ou o barão vermelho pode não ter habilidade para conviver com as demais pessoas.

Desafio número 2:

Reconhecer os melhores.

E como reconhecer os melhores?

a) Medindo a produtividade?  

b) Existem outros meios de reconhecê-los?

Medir a produtividade

Será fácil fazer isto?���

Linhas de código?

Mas programadores espertos produzirão mais ���escrevendo códigos mais longos���

Lembrando Dilbert: você obtem o que mede

Pontos de função? ���

Mas código ruim não gera mais pontos de função.  

Número de histórias prontas?

Mas e a complexidade diferente de cada uma?

Então não consigo medir a produtividade?

Para mim a resposta é não.

Parece até perda de tempo tentar.

Concordo com Martin Fowler em���

http://www.martinfowler.com/bliki/CannotMeasureProductivity.html

Então como saber se um programador já é 10x?

Se não se pode medir���

Quais serão então os tais outros meios?  

Minha resposta: ���

acompanhamento dia a dia  

Para nossa sorte, ���

os meios de acompanhamento úteis��� para reconhecer um programador 10x

São exatamente os mesmos ���

que possibilitam conduzir um iniciante ��� ao conceito 10x

- Programação pareada

- Revisão de código  

- Compartilhamento de conhecimento, workshops, práticas de dojos, etc.  

- TDD, boa comunicação, etc.

Primeiro resultado desta apresentação���

Não é possível medir a produtividade dos ���programadores

mas se pode avaliar cada um por meio de ��� acompanhamento frequente.

Esta página foi intencionalmente deixada em branco���para que você pense no dia a dia do seu projeto

Impressões minhas: ���

Algumas práticas do desenvolvimento ágil adequadas a elevar o nível dos iniciantes são ���deixadas de lado ao estimar um projeto.  

Nem sempre o ambiente de desenvolvimento ���facilita o emprego destas práticas.

No seu projeto ou na sua empresa:

- nas estimativas é previsto o pareamento?  

- ou cada desenvolvedor pega uma tarefa?  

- e há tempo para revisão de código?  

- há práticas de disseminação de conhecimento?  

- o ambiente de trabalho facilita o pareamento? ���existem baias? As mesas permitem pareamento?  

- é fácil trocar de par ou os desenvolvedores tem ���lugar fixo?

Considerando que uma boa parte dos ���desenvolvedores trabalha alocado nos clientes, ���

e que dentro do ambiente deles dificilmente���conseguimos tempo no projeto e espaço físico ���ideal, ���

só pode ser pegadinha do Malandro falar ���destas práticas.

Mesmo nas empresas cujo objetivo principal é o ���desenvolvimento de software, nem sempre há ���espaço físico propício às práticas citadas ���

Também não é fácil encontrar imóveis e móveis ���ideais

Muitas vezes por pressões dos clientes ou pelo���exíguo time to market do produto, é difícil subtrair���tempo do projeto para cuidar dos processos (*) de ���melhoria contínua e renovação da equipe.

* Se não cuidar destes processos, então cuidado com a ��� lei de Brooks: “adicionar pessoas a um projeto atrasado ��� irá atrasá-lo ainda mais”

Desafio número 3 (este sim o mais difícil)

1. Convencer os gestores das empresas da importância destas práticas.

2. Convencer os clientes que produto feito sob encomenda só será bom e atualizado, se estiver sob um processo de melhoria contínua. ���Portanto é preciso reservar tempo para isto.

3. Convencer os desenvolvedores de são eles os���beneficiados e que também precisam doar tempo.

O passo 1, ao contrário do que dizem, costuma ser���o menos difícil: ��� convencer os chefes.

E eles tem acesso e mandato para convencer nossos ���clientes.

Porém ninguém se iluda.

Muito mais difícil é convencer os colegas,

de que são parte interessada no processo de ��� melhoria e atualização e que  

também devem doar tempo.  

O desafio 3

é convencer���

convencer���

convencer ...

Segundo resultado desta apresentação:���

É preciso reservar tempo e esforço em prol da ���melhoria contínua.

Alguns podem discordar mas para mim isto não ���deve ocorrer só por parte da empresa. ���

É preciso convencer o desenvolvedor a também ���fazer a sua parte.

Práticas que ajudam a diminuir o gap técnico da���equipe e conduzem um iniciante ao conceito 10x

Relembrando programação pareada

•  Fred Brooks e Larry Constantine já falavam disto

•  Diminui o risco e evita o “truck factor” (Ceci Fernandes)

•  Resultado do código costuma ser mais legível

•  Ao contrário do que dizem, pode ser feito remoto

•  Gasta mais tempo.

•  Cansa mais a cabeça, nem todos suportam mesmo % / dia

Relembrando revisão de código

•  Brooks também citava

•  É uma prática aparentemente esquecida atualmente. ���

•  Além de diminuir o “truck factor”, é mais uma chance de���descobrir defeitos���

•  Parece funcionar melhor feito em grupo (ou par) ���

•  É mais fácil rever pequenos trechos de código em���pequenas janelas de tempo

Relembrando compartilhamento de conhecimento, ���workshops, práticas de dojos, etc.

•  Atividades que exigem mais doação dos desenvolvedores���do que da direção da empresa���

•  Geralmente feitos fora do horário de trabalho���

•  Em alguns casos contam com participação de ���desenvolvedores de outras empresas

•  Estimulam e dão oportunidade de afirmação aos que se���oferecem para estudar e apresentar temas

Relembrando TDD, boa comunicação, etc.

•  TDD pode diminuir o medo do iniciante de fazer uma���grande bobagem que acarrete muitas horas de debug���

•  TDD facilita a revisão de código

•  TDD retira bloqueios do tipo “se está funcionando não ���mexe”. Bloqueios deste tipo inibem iniciantes���

•  Boa comunicação é como uma plantinha que precisa ser���regada todo dia. Nem sempre todos percebem o exato���momento em que a comunicação começa a ter ruídos. ���O iniciante sofre mais com falha de comunicação

Terceiro resultado desta apresentação: ���

Práticas populares do XP porém já recomendadas ���desde a década de 70, junto com ações de ���disseminação de conhecimento e mais TDD, ���permitem avaliar a produtividade e elevar o nível ���médio dos times.

De quebra diminuem o risco de falha do projeto e ���ainda preparam a equipe para maiores desafios

E o tal programador 10x?

Não há como medir a produtividade #fato  

Dizer que um vale 10 vezes o outro é chute

Daí a definição arbitrária do programador 10x���no início desta apresentação sem comparar ���com nenhum outro #constatação  

Moral da história

Se não podemos medir, não há como colocar ���números comparativos.  

O termo programador 10x significa ...  

apenas um bom programador (como definido).

Você conhece um programador 10x?

?

Obrigado

luca.bastos@concretesolutions.com.br