É horrível programar com alguém te interrompendo e buzinando na sua orelha a cada dois minutos. Isso atrapalha o seu raciocínio e o faz esquecer sobre o que estava pensando. Isso é para pessoas que tem déficit de atenção e não conseguem se concentrar por mais do que 30 segundos.
Por que dizem Nietzsche e não “Nietzsche + um outro cara” ou Beethoven e não “Beethoven + um outro cara”? Porque para se fazer qualquer coisa é necessário se concentrar, e para se concentrar é necessário estar só. Não existe pensamento “coletivizado”. Isso é algo individual.
Às vezes invejo matemáticos e cientistas que não tem que lidar com idéias cretinas assim.
Quando se trata de programacao como atividade individual criativa, concordo contigo.
A questao eh que na maioria dos casos estamos sendo pagos para produzir algo em equipe, e isso exige uma postura profissional totalmente diferente. Embora programacao seja uma atividade individual, desenvolvimento de software como profissao eh uma atividade coletiva.
Minha primeira experiencia com pair programming ja tem quase 10 anos. Nunca vi uma base de codigo decente produzida por programadores isolados sem um ciclo frequente de feedback (seja pairing ou reviews).
Ou seja, voce pode nao gostar de pair programming, mas a ideia esta longe de ser um scam. Se voce quer ser um “Beethoven” do codigo sugiro que voce deixe seu emprego e va criar algo proprio onde o seu pensamento individual possa prevalecer.
Pair programming no final das contas acaba impedindo que idéias novas e interessantes sejam introduzidas, pois não há como tê-las coletivamente. Idéias são coisas individuais.
Esse é o problema. As pessoas acham que programação é como se fosse uma linha de montagem onde você só aperta parafuso.
Voce pode dar um exemplo? Na minha experiencia eh justamente a troca de ideias durante pair programming e reviews que faz as melhores ideias aparecerem.
De que pessoas voce esta falando? E o que isso tem a ver com pair programming?
Interessante seria se você explicasse qual é a gênese das idéias, pois isso não faz o mínimo sentido.
Idéias não surgem do nada, elas são tão boas quanto a experiência do desenvolvedores envolvidos. Da forma como você fala até parece que uma “idéia” é uma coisa que acontece randomicamente, do nada, sem nenhum motivo aparente.
Assim como um livro, para se desenvolver qualquer solução é necessário primeiro entender o domínio, depois brincar com algumas idéias até que se as desenvolve gradualmente. E como um bom livro, as idéias seguem um tema comum. É um processo de tentativa e erro e de exploração.
Logo concentração é importante, pois estudar e entender o problema é metade da solução.
E é assim que produtos de sucesso são desenvolvidos. E também é por isso que produtos criados por “comitê” geralmente são o mínimo denominador comum e muito mais lentos para adotar novos recursos.
Pair programming tem dois problemas relacionados:
Não leva em consideração o período de estudo e entendimento. Com alguém falando na sua orelha é impossível se concentrar. Isso indica que as pessoas que criaram isso acreditam que programação é algo pouco além de digitação;
Digitar o código é a última parte do desenvolvimento de software, mas não é a única.
Também commoditiza o papel do desenvolvedor, pois agora não há mais autoria. Ou seja, ninguém é individualmente responsável por nada. Se o trabalho foi bom, não foi por sua causa especificamente.
Assim fica mais fácil tornar o desenvolvedor em uma engrenagem facilmente substituível.
Enfim, isso é uma forma de produzir o “mínimo denominador comum” além de tornar as nossas vidas mais difíceis.
Ideias nao sao randomicas. Eu penso como voce: elas nascem da experiencia e do entendimento das pessoas envolvidas. E tambem concordo que estudar em pares eh horrivel. Mas programacao em par no meu ponto de vista nao tem a ver com momentos de exploracao e entendimento (pra isso servem pesquisa, spikes e prototipos). Agora, quando chega a hora de escolher uma solucao e coloca-la em pratica, ai sim eu vejo esta troca de ideia como algo de muito valor.
Exato. Pair programming nao eh tecnica de estudos. E tambem nao eh assistente de digitacao. Eh uma tecnica de feedback rapido para decisoes de implementacao.
Alem disso, ela depende de que as pessoas envolvidas estejam abertas a esse tipo de dinamica. Tanto que os proprios integrantes do C3 (projeto que deu origem ao eXtreme Programming) admitem que o fato de muitos da equipe ja terem trabalhado juntos antes e conhecerem o dominio ajudou muito na adocao da nova pratica. E nao surpreende que hoje em dia as pessoas abusam da pratica.
Eu tambem nunca vi uma equipe programando em par 100% do tempo e que fosse eficiente. Existem horas par estudo, validacao, experimentacao e implementacao final. E nessa ultima, pelo menos, programacao em par pode ter muito valor.
Dividir a autoria tambem nao eh o objetivo da programacao em par, embora esse acabe sendo um efeito colateral. E eu nunca vi essa tecnica por si soh tornar um bom profissional numa peca substituivel. Voce ja?
Tambem nunca vi um bom programador nao ser reconhecido pelo seu trabalho soh porque criou algo em par. Por outro lado, eu ja vi muito conhecimento sendo passado para outros atraves dessa pratica. E todo projeto tem a ganhar com isso.
[quote=Longino]
Enfim, isso é uma forma de produzir o “mínimo denominador comum” além de tornar as nossas vidas mais difíceis.[/quote]
Eu tambem concordo que pairing faz a vida mais dificil. Principalmente quando existe uma diferenca de nivel entre os dois programadores. Porem, tanto nos casos quando programei com alguem muito melhor que eu ou alguem bem iniciante, nunca senti que a solucao foi o minimo denominador comum. Muito pelo contrario.
Talvez voce precise tentar com outros programadores ou num novo contexto (num coding dojo, talvez) para ver o valor da pratica.