O que evitar quando programar em par
Tags: pairprogramming, beginners
Published: 2019-10-01 03:32:56


#####Livre tradução do artigo *Pair Programming Antipatterns* - disponível em https://tuple.app/pair-programming-guide/antipatterns


É possível parear bem simplesmente evitando parear mal. 

Evite esses erros comuns e você vai aumentar suas chances de sucesso! :)


##**Para copilotos:**


###**Apontar erros rapidamente demais**

Dê ao piloto a chance de notar seus próprios erros de sintaxe e *typos* (erros de digitação).

Apontar constantemente pequenos erros prejudica o fluxo. O seu e o do próprio piloto. Isso também pode deixar seu par inseguro.

Lembre-se: seu trabalho é considerar o macro, e não apontar palavras erradas assim que você as vir.


###**Dar instruções “baixo nível”**

Se você tem uma sugestão para o piloto, comunique isso no nível mais alto de abstração que ele pode entender.

Se você se perceber ditando código (ou pior, tecla por tecla), pare e veja se você consegue comunicar sua ideia num nível mais elevado.

Se isso não funcionar, peça para pilotar um pouco para que você possa demonstrar sua ideia.
 

###**Não levar seu próprio teclado**

Leve seu próprio teclado para cada sessão de *pair programming* e plugue antes de vocês começarem.
 
Isso facilita na hora de trocar de papéis e permite que você mostre, em vez de falar, quando as palavras falharem.

Ter seu próprio mouse é bom também, mas não é tão essencial. (É fácil pedir para alguém clicar em algo, é mais difícil pedir para ele digitar vários caracteres.)


##**Para pilotos:**


###**Pilotar muito rápido**

Se você é muito experiente com o seu editor, é fácil fazer tudo rapidamente demais, de modo que até os copilotos mais experientes se percam.

A não ser que você tenha certeza que seu par está te acompanhando, não digite seu código tão rápido quanto você está acostumado.

Explicar o que você tá fazendo ajuda nisso.


###**Permitir um copiloto desatento(?)** 
*(original: Allowing a checked-out navigator)*

É fácil perder a atenção do seu copiloto ao ir rápido demais, ou fazendo coisas que ele não entende muito bem.

Se você perceber que a atenção do seu copiloto está vacilando, pare e sincronize.

**Uma pergunta ruim**: “Você entende isso, né?”
**Uma pergunta boa**: “Qual parte disso é mais difícil de acompanhar?”

Parear deve envolver comunicação constante em mão dupla. Se você ou seu copiloto ficaram quietos, parem e sincronizem.


###**Acesso à tela desigual**

Sente-se de modo que o monitor fique entre vocês dois. Garanta que vocês dois possam ver igualmente bem (considere aumentar o tamanho das fontes).

Se uma pessoa está mais pro lado, isso cria uma sensação subconsciente de hierarquia desigual.

Um par é **uma unidade**. *Nenhum de vocês é mais importante.*


###**Não fazer pausas**

Parear é exaustivo. Até mais do que programar normalmente.
 
Um bom jeito de garantir que vocês façam pausas adequadas é empregar o método Pomodoro. Considere combinar o tamanho dos turnos de trabalho e pausas com o seu par antes de vocês começarem.


###**Ouvir sem escutar**

É difícil ouvir e digitar ao mesmo tempo. 
Se o seu copiloto está fazendo uma sugestão, considere tirar as mãos do teclado. Melhor ainda: vire-se e faça contato visual! :)

##**Para os dois:**

###**Permitir distrações improdutivas**

Antes de começar a parear, desative todas as notificações (no seu computador e no telefone).

Uma sessão de *pair programming* deve ser interrompida por exatamente zero notificações no Slack ou mensagens de texto.

Se uma notificação aparecer, peça desculpa e desative as futuras. 
Não deixe o seu e-mail aberto em outro monitor.

(Você deveria fazer isso mesmo quando não está pareando. A forma mais rápida de melhorar a produtividade programando é reduzindo interrupções.)


###**Não trocar os papéis**

Ser piloto e ser copiloto são exaustivos por razões diferentes. 

Trocar os papéis permite que você descanse as partes cansadas do seu cérebro e ative as antes ociosas. 
Trocar os pilotos é um ótimo jeito de energizar uma sessão de pareamento que está perdendo o fôlego. Considere configurar um alarme para indicar toda vez que for a hora de trocar.


###**Esquecer que é uma habilidade**

*Pair programming* é uma habilidade que deve ser aprendida.

Você nunca vai ser bom nisso de primeira, mas a prática consistente vai resultar em melhorias.

Não desista depois da primeira experiência. Não presuma que desenvolvedores experientes são automaticamente ótimos em *pair programming*. Não espere ser bom sem prática.

Considere refletir junto com seu par sobre isso, ou pedir feedback depois de cada sessão. O que vocês poderiam ter feito melhor?