Apresentação feita na Caelum na Noite Ágil de 09/08/2011

1. Como formar um programador 10x
Luca Bastos
luca.bastos@concretesolutions.com.br
Noite Ágil - Agosto/2011
Caelum SP

2. A m a i o r r i q u e z a d o h o m e m
é a s u a i n c o m p l e t u d e .
N e s s e p o n t o s o u a b a s t a d o.
P a l av r a s q u e m e a c e i t a m c o m o s o u - e u n ã o a c e i t o.
N ã o a g ü e n t o s e r a p e n a s u m s u j e i t o q u e a b r e p o r t a s ,
q u e p u x a v á l v u l a s , q u e o l h a o r e l ó g i o,
q u e c o m p r a p ã o à s 6 h o r a s d a t a r d e ,
q u e v a i l á f o r a , q u e a p o n t a l á p i s ,
q u e v ê a u v a e t c . e t c .
Pe r d o a i
M a s e u p r e c i s o s e r O u t r o s .
E u p e n s o r e n o v a r o h o m e m u s a n d o b o r b o l e t a s .
M a n o e l d e B a r ro s

3. 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.

4. 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.

5. “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

6. 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)

7. 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.

8. Você conhece um programador 10x?

9. Melhor dizendo,
reconhece um programador 10x?

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

16. Ops...
Desculpa aí Milfont ...

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

18. 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.

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

20. 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

21. 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

22. 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

23. 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
Tamanho do código
Tempo de execução do código
10 X
25x
5x
10x

24. 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.

25. 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:

27. 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

29. #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

30. Desafio número 1:
Dar condições para o iniciante virar bom
programador continuando sendo um ser humano
(sem arrogância).

31. Opinião do Joel Spolsky:
Contrate um super star caso queira um produto
acima da média.

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

33. 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.

34. Desafio número 2:
Reconhecer os melhores.

35. E como reconhecer os melhores?
a) Medindo a produtividade?
b) Existem outros meios de reconhecê-los?

36. Medir a produtividade
Será fácil fazer isto?

37. Linhas de código?
Mas programadores espertos produzirão mais
escrevendo códigos mais longos
Lembrando Dilbert: você obtem o que mede

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

39. Número de histórias prontas?
Mas e a complexidade diferente de cada uma?

40. 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

41. Então como saber se um programador já é 10x?
Se não se pode medir
Quais serão então os tais outros meios?

42. Minha resposta:
acompanhamento dia a dia

43. Para nossa sorte,
os meios de acompanhamento úteis
para reconhecer um programador 10x

44. São exatamente os mesmos
que possibilitam conduzir um iniciante
ao conceito 10x

45. - Programação pareada
- Revisão de código
- Compartilhamento de conhecimento,
workshops, práticas de dojos, etc.
- TDD, boa comunicação, etc.

46. 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.

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

48. 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.

49. 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?

51. 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.

52. 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

53. Blog do @sumeet_moghe
http://www.learninggeneralist.com/2011/08/spatial-serendipity-key-to-social.html

54. Blog do @sumeet_moghe
http://www.learninggeneralist.com/2011/08/spatial-serendipity-key-to-social.html

55. Nosso ambiente na Concrete SP

56. 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”

57. 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.

58. 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.

59. 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.

60. O desafio 3
é convencer
convencer
convencer ...

62. 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.

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

64. 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

65. 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

66. 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

67. 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

68. 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

69. 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

70. 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).

71. ?
luca.bastos@concretesolutions.com.br
Você conhece um programador 10x?
Obrigado