Forem: Júlia Kastrup

Problemas para contratar desenvolvedores seniores? Provavelmente é sua culpa...

Júlia Kastrup — Tue, 17 Dec 2019 18:36:26 +0000

Tradução livre do artigo Trouble hiring senior engineers? It's probably you, de autoria de Alexander von Franqué

Edit: este post provocou ótimas discussões no HackerNews e no /r/programming, fique à vontade para participar!

É um fato: é difícil contratar desenvolvedores de software seniores. No entanto, não acredito na narrativa de que o mercado está completamente seco. Ao longo da minha carreira, trabalhei com muitas equipes de desenvolvimento diferentes, que podiam ser divididas em duas categorias: as que lutam para contratar seniores e as que não tem nenhum problema para isso. De fato, as equipes da última categoria estavam geralmente cheias.
Existem muitas razões pelas quais algumas equipes não conseguem atrair bons talentos. Mas todas as equipes já perceberam um fato bem simples sobre a situação do mercado:

Ao contratar desenvolvedores seniores, a empresa não escolhe o candidato, o candidato escolhe a empresa.

Ou, de forma mais simples:

Ao contratar desenvolvedores seniores, você não está comprando, está vendendo.

Se você não concorda com a afirmação acima, deixe-me colocá-la em perspectiva. Alguns anos atrás, meu currículo foi parar em uma rede de recrutadores. Na época, eu tinha cerca de 3 anos de experiência como desenvolvedor de software em empresas menores. Durante dias, minha caixa de entrada foi inundada com e-mails de recrutadores. Outra vez, alguns anos depois, recebi telefonemas não solicitados de três recrutadores diferentes em um único dia.

Esta história não diz nada sobre minhas habilidades como desenvolvedor. Muitos de meus colegas com várias formações e níveis de habilidade têm histórias semelhantes. Na situação atual do mercado, um desenvolvedor com alguns anos de experiência em suas mãos tem muitas e muitas opções.

O engraçado é que, enquanto eu estava empregado nos dois momentos, não estava particularmente feliz com meu trabalho. Eu estaria interessado em novas oportunidades, mas esses recrutadores fizeram um trabalho tão ruim em tentar fazer a oferta parecer atraente que eu me recusei a conhecê-los pessoalmente. Portanto, não pense que os desenvolvedores seniores não estão interessados em sua oferta, você só precisa torná-la atraente - você precisa vender! A maioria dos gerentes e recrutadores de contratação com quem conversei tendem a concordar com esta declaração. Mas, se você observar o que a empresa está fazendo no que diz respeito à contratação, as ações deles não correspondem às suas palavras.

De fato, quase tudo que fazemos no recrutamento moderno é ruim. É ruim para todas as partes envolvidas, mas especialmente para o candidato. Vejamos algumas áreas específicas.

Seu anúncio de emprego provavelmente é uma droga.

Imagine que você está contratando para uma posição diferente (não de desenvolvimento). Você postou sua oferta de emprego e agora recebeu mais de 200 currículos para ler. Quanto tempo você gastaria em cada currículo individual? Um minuto ou dois? Menos ainda? Esta é a posição em que um desenvolvedor sênior está, ao procurar um emprego.

Seu anúncio de emprego é como o currículo de um candidato. Eles vão gastar apenas alguns segundos para julgá-lo e, se isso não chamar sua atenção, eles vão embora. Infelizmente, a maioria das ofertas de emprego é péssima.

Por exemplo, vamos olhar para uma anúncio comum de emprego para uma posição sênior de desenvolvimento. Eu entrei em uma das grandes plataformas de trabalho e procurei por "Senior Software Engineer". Escolhi uma postagem aleatória e a desfoquei porque não queria escolher publicamente uma empresa específica. As áreas vermelhas comunicam o que o empregador precisa e as áreas verdes comunicam o que o empregador pode oferecer ao candidato.

Se você tem uma mentalidade de compra, tudo bem - você está dizendo o que precisa. Mas se você vem de uma mentalidade de venda, isso nao faz sentido! Você está acostumado a ler currículos, então imagine como você se sentiria sobre um candidato cujo currículo contenha mais de 50% de informações sobre o que ele deseja.

Em vez disso, eles provavelmente tentaram preencher seu currículo com 100% de informações sobre os benefícios que podem oferecer à empresa. Eles o otimizaram para colocar os argumentos mais convincentes sobre si nos pontos mais visíveis.

Eu compilei os erros mais comuns nas descrições de cargo nesta postagem.

Em uma publicação futura, veremos como deve ser a publicação perfeita da vaga. Inscreva-se na nossa newsletter abaixo [N.T.: é possível se inscrever pelo artigo original] para ser notificado quando sair.

Provavelmente é muito difícil encontrar informações sobre sua empresa.

Indo além da publicação de vagas, a maioria das empresas dificulta a obtenção de informações vitais sobre elas.
Seja honesto, é fácil encontrar respostas para todas as perguntas a seguir, que podem ser superimportantes para possíveis contratações? Fácil tipo "no máximo a um clique do seu anúncio de emprego"?

Como a empresa está organizada?
Qual o estilo de gerenciamento ou metodologia de desenvolvimento (por exemplo, Scrum, XP) a equipe usa? A gerência possui uma formação técnica?
Quantas pessoas estão na equipe?
Como você lida com o horário de trabalho? Vocês usam alguma ferramenta de gerenciamento de tempo? (tipo Toggl, Clockify ou Harvest)
Em que produto / área do produto vou trabalhar?
Como é o ambiente do escritório? Qual hardware eu vou usar?
Como as pessoas geralmente se vestem no escritório?
A equipe sai para almoçar todo mundo junto?

Obviamente, pessoas diferentes têm necessidades diferentes. Nem todo mundo se preocupa com todas essas perguntas, mas para muitas suas respostas serão extremamente importantes.

Por exemplo, trabalhei com muitas pessoas que tiveram más experiências com o gerenciamento não técnico. Eles categoricamente não trabalham mais com gerentes não técnicos. Portanto, se sua equipe tiver um gerente com formação técnica, verifique se seus possíveis contratados sabem. Para algumas pessoas, é um grande ponto de venda!

Para analisar isso de uma perspectiva diferente, vamos nos colocar no lugar do candidato. Imagine que você estava procurando comprar um novo computador. Você vê um anúncio que parece interessante, mas ainda tem mais perguntas. Então, você acessa o site do vendedor, mas ainda não consegue encontrar todas as respostas que deseja. Você continua pesquisando e, depois de um tempo, finalmente encontra um número de telefone. Você liga para eles e faz todas as suas perguntas, mas, infelizmente, a pessoa no telefone não tem todas as respostas. Em vez disso, eles solicitam que você envie uma carta dizendo por que você deseja comprar o computador. Você também deve enviar a eles uma prova de que você tem dinheiro suficiente para comprá-lo. Depois disso, eles dizem que podem convidá-lo para uma reunião pessoal, onde responderão com prazer todas as perguntas que você tiver sobre o computador.

Você realmente passaria por todo esse processo ou apenas encontraria um computador diferente para comprar? Essa é a experiência que a maioria dos candidatos tem ao tentar obter respostas para as perguntas acima. Para a maioria das empresas, você não pode obtê-las até a hora da entrevista. Essa é uma grande desvantagem para a maioria dos desenvolvedores, o que me leva ao próximo ponto.

Seu processo de contratação/entrevista provavelmente é uma droga e muito lento

Vamos voltar ao exemplo de compra de um computador de cima. Imagine que você passou por todo o processo e agora está na loja de computadores. Você ainda tem todas as perguntas acima e aguarda um representante da loja para fornecer algumas respostas. Mas, meia hora depois do horário combinado, eles ainda nem apareceram. Quando chegam, eles continuam bombardeando você com perguntas sobre o motivo pelo qual você deseja comprar o computador deles. Eles não respondem a nenhuma das suas.
Quando chega a hora em que você tem permissão para fazer perguntas, eles dizem que não têm mais tempo. Ou dizem que não têm respostas para essas perguntas, porque não sabem os detalhes deste computador. Eles estão pedindo para você voltar mais tarde. Além disso, você deve preencher um teste de computador primeiro, para garantir que é bom o suficiente com computadores para comprar um. Depois de enviar o questionário (que demorou mais de uma hora para ser concluído), você não recebe uma resposta por semanas.

Eu pessoalmente experimentei todas essas coisas, às vezes ao mesmo tempo.

Vamos dividir esse cenário em pontos e recomendações específicos. A maioria delas deve ser óbvia, mas muitas empresas ainda as entendem errado.

Seja pontual. Não deixe seus candidatos esperando.
Esteja bem preparado. Você deve ler o currículo do seu candidato antes, e deve ter uma estrutura para sua entrevista. Você deve saber o máximo possível sobre a posição e estar preparado para responder a perguntas.
Seja amigável. Parece óbvio, mas é super importante e muitas empresas entendem errado. É uma questão de mentalidade. Dê ao candidato a sensação de que você realmente deseja contratá-lo. Nunca pense que eles têm que provar a si mesmos a você - se alguém tem que provar a si mesmo nesse caso, esse alguém é você. Mesmo que ele se mostre um candidato fraco, ainda é melhor causar uma boa impressão. Talvez ele conte a seus amigos sobre essa ótima experiência ou se inscreva em alguns anos, com melhores habilidades.
Seja rápido em suas decisões, sem ser insistente.

Uma observação rápida sobre tarefas de programação

É compreensível que você queira saber se a pessoa que você está contratando pode realmente fazer o trabalho que você precisa e fazê-lo bem. Voltando ao exemplo acima de comprar um computador, é claro que o vendedor deseja verificar se você possui os fundos antes de comprar. Mas, se for espertos, assumirá que você tem o dinheiro. Ele só verificará essa suposição no último momento.

Você deveria fazer o mesmo. Claro, saber que momento é esse depende muito da sua situação e recursos específicos. Se você tem muitos candidatos, provavelmente precisará fazer algum tipo de pré-avaliação de suas habilidades. Mas o que quer que você faça, faça isso com a mentalidade de um vendedor e tente fazer com que o candidato realmente queira primeiro o emprego. E quando chegar a hora, você deve fazer com que sua avaliação seja o mais rápida e indolor possível para o candidato.

As opiniões divergem quanto a isso, mas, se outro dev estiver fazendo a entrevista, talvez não seja necessário fazer uma avaliação formal da habilidade. Na minha experiência, é bastante fácil julgar habilidades técnicas. Uma conversa amigável sobre interesses técnicos e projetos recentes pode ser suficiente. Se você decidir que uma avaliação formal é necessária, deixe o candidato escolher entre um pequeno projeto para levar para casa ou uma tarefa de codificação no escritório, com prazo determinado. De qualquer forma, recomendo fazer a avaliação o mais próximo possível do trabalho real. Deixe que ele use seu próprio notebook, forneça acesso à Internet, que faça perguntas. Faça com que pareça mais que vocês estão trabalhando em um desafio juntos do que em um teste das habilidades deles.

On-boarding e gerenciamento ruins

Esses tópicos merecem um post à parte. O que acontece após o processo de contratação pode ser ainda mais importante do que a própria contratação. Não entrarei em muitos detalhes aqui, mas lembre-se de que se os processos em sua empresa não forem bacanas, você poderá ter dificuldades em contratar pessoas excelentes, mesmo com o melhor processo de vendas.

Dependendo da sua posição na empresa, pode não ter muito o que fazer sobre isso. Mas você pode pelo menos estar ciente das vantagens e desvantagens da sua empresa e comunicá-las claramente aos seus candidatos.

Felizmente, muito disso é subjetivo. Como mencionei acima, pessoas diferentes querem coisas diferentes em seu trabalho. Algumas pessoas adoram trabalhar em casa, outras preferem passar um tempo em um escritório com uma grande equipe ao seu redor. É importante que você converse com sua equipe e saiba o que eles preferem e como atualmente lidam com as coisas. Esse conhecimento permitirá que você comunique isso melhor aos possíveis candidatos.

Da mesma forma, alguns gerentes simplesmente não se sentem confortáveis com determinadas vantagens, como home-office ou horário de trabalho flexível. Portanto, às vezes, mesmo quando você pensa em vender, não pode fazer tudo o que seus candidatos desejam, e tudo bem. Esteja ciente de que não oferecer algumas vantagens é uma fraqueza potencial da sua empresa quando se trata de contratar desenvolvedores. Ainda assim, conhecer esses pontos fracos do seu "produto" é importante, pois você poderá comunicá-los melhor. E pode até valer a pena comunicar abertamente suas fraquezas. Isso impedirá que você contrate candidatos que possam se encaixar mal.

Conclusão

Se você é acostumado a recrutar para outro setor, pode ser difícil mudar sua mentalidade. Na maioria das indústrias, o candidato é o vendedor. E mudar essa premissa tem muitas implicações. Todos os sistemas, ferramentas e processos que estabelecemos há décadas não são mais aplicáveis ou podem ser amplamente aprimorados.

Portanto, meu conselho é parar de lutar contra isso, aceitar que você está vendendo e começar a fazê-lo bem. Sempre que você estiver fazendo algo relacionado à contratação, coloque-se no lugar de um candidato que já tenha cinco ofertas na mesa. Pergunte a si mesmo: "Como posso vencer a concorrência?" Além disso, verifique se todos os envolvidos no processo de contratação estão na mesma página - por exemplo, compartilhando esta postagem com eles! ;-)

Edit: este post provocou ótimas discussões no HackerNews e no /r/programming, fique à vontade para participar!

Lembrando: esse texto é uma tradução livre do artigo Trouble hiring senior engineers? It's probably you, de autoria de Alexander von Franqué

Um "quase-diagnóstico" como muleta

Júlia Kastrup — Thu, 14 Nov 2019 22:50:21 +0000

Mais um texto quase advindo de um tweet. Dessa vez, pulei o tweet e vim direto pra cá, porque queria externalizar um pouco como venho me sentindo desde que comecei a terapia, e como um possível diagnóstico de TDA tem mudado a minha vida.

Comecei a terapia há alguns meses, pois "andava muito à flor da pele". Qualquer mínima discussão ou discordância era suficiente para me fazer chorar. Na primeira sessão, contei o que me levava até ali, e como tinham sido as minhas outras tentativas de terapia.

A terapeuta ficou interessada em saber por que eu tinha sido encaminhada para terapia com 9 anos. Contei que tinha sido a primeira da turminha a começar a ler, mas que andava desatenta. Contei também que a recomendação do colégio tinha sido psicoterapia e kumon, justamente pra melhorar a concentração e atenção.

Ao longo das nossas sessões, ela perguntou se eu já tinha desconfiado de TDAH. Fiquei apreensiva, porque sei como essa doença é superdiagnosticada. Falei que já tinha pensado nisso "mas tinha conseguido passar no vestibular e terminar o colégio e a faculdade". Ela me explicou um pouco mais sobre a condição e me passou um questionário. Me explicou que o questionário por si só não era o suficiente para diagnosticar o transtorno, mesmo que eu tenha "gabaritado" a parte atencional.

Passei algumas semanas sofrendo com esse possível diagnóstico. Tinha, intimamente, dois sentimentos:
1) o medo de precisar tomar remédio, embora ela tenha me dito que nem sempre a medicação é necessária;
2) o medo de me apoiar num diagnóstico para justificar qualquer falta de atenção minha. e aí nunca mais tentar nada sem que estivesse medicada porque "eu sabia que não conseguiria". tipo aquelas pessoas que dizem que são ciumentas porque são escorpianas, sabe? eu morria de medo de usar esse transtorno como muleta.

Eu nunca falei pra ninguém sobre esse segundo ponto, mas era o que eu mais pensava. Mesmo sem falar pra terapeuta sobre isso, fomos trabalhando a minha autocobrança, e ela foi me falando sobre o conceito de autocompaixão. Eu dizia que eu me perdoava demais, ela dizia que eu me cobrava demais. "Larga o chicotinho", ela ainda diz.

Bom, quanto mais vamos conversando, mais próximas estamos de realmente firmar o diagnóstico no transtorno de atenção. No entanto, diferentemente do que eu imaginava, eu tenho usado o 'quase-diagnóstico' pra me perdoar positivamente, e não pra desistir.

Essa semana, eu concluí um curso on-line. Parece bobeira, mas eu nunca concluo nenhum curso, por menor que seja. Então foi bem simbólico para mim.

Durante o curso, eu tive as mesmas dificuldades de sempre, mas, em vez de desistir, eu me dei um tempinho, aceitei que o meu ciclo atencional é curto. Lancei mão de alguns artifícios. Pausei quando minha atenção voou. Fui olhar o twitter sem culpa. E voltei. Fiz isso várias vezes, mas, diferentemente de todas as outras vezes, em que eu pensava em como eu era burra e preguiçosa, dessa vez eu pensei "bom, é. o meu ritmo pode ser diferente do ritmo das outras pessoas mesmo. mas devagar e sempre, vamo lá.". Foi quando eu concluí essa etapa do curso que eu entendi esse lance da autocompaixão que a minha terapeuta vive falando. Talvez o "quase-diagnóstico" esteja de fato sendo uma muleta, mas uma que cumpre o seu papel: o de ajudar a andar quem tinha dificuldade.

Eu ainda não sei se realmente tenho o tal do transtorno de atenção. Acredito que sim. Não sei se vou precisar tomar remédio pra sempre. Espero que não. Mas as coisas estão melhorando.

Como sou muito ruim em terminar textos - e como percebi que tem gente que realmente lê o que eu escrevo, queria recomendar um vídeo para quem se identificou com isso que eu falei de autocompaixão. Procurem palestras da Brené Brown no Netflix e no Youtube :)

Um texto grande demais que deveria ser sobre terapia e pythonbrasil e lt, mas acabou sendo sobre trabalho e sobre mim

Júlia Kastrup — Fri, 01 Nov 2019 04:39:11 +0000

"eu poderia escrever um post inteiro sobre como ir à python brasil e apresentar uma lightning talk mudaram totalmente o rumo que eu tava tomando para além dos limites profissionais."

Esse foi o tweet que me inspirou a, de fato, escrever um post inteiro sobre isso. Relendo, vi que fui injusta, pois a própria decisão de ida e, sobretudo, a de apresentar uma lightning talk foram resultado de outras construções, como ter começado a terapia.

A verdade é que é certo que os dias 24 a 28 de outubro foram um marco: eu sinto agora uma energia que eu não sentia há muito tempo. E quando falo 'muito tempo', falo de mais de ano.

Há dez meses, troquei um emprego que eu gostava muito, com um produto que eu adorava e pessoas com quem eu amava trabalhar por outro trabalho: um estágio - aos 27 anos - em Desenvolvimento. Fiz isso com bastante medo e, apesar de não ter me arrependido nem por um segundo, esses últimos meses foram aterrorizantes.

Pela primeira vez, eu estava trabalhando principalmente com desenvolvimento, tendo que lidar diariamente com a frustração. Não é um sentimento fácil. Some a isso uma autoestima bem complicada desde sempre. Eu tava no extremo inferior do vale da autoestima. Eu pensei em desistir muitas vezes.

Tenho a sorte de trabalhar com pessoas incríveis que sempre fazem questão de me colocar para cima, não só com palavras, mas realmente acreditando em mim. Sou apaixonada pelo meu trabalho e pelas pessoas com quem eu tenho o prazer de dividir o dia, mas parece que o buraco era mais embaixo. São mais de 20 anos no rolê da autoestima cagada e isso não dá pra mudar só de fora para dentro, né?

Ouvi muitas vezes que era síndrome do impostor, mas, embora eu saiba que essa é uma resposta comum das vítimas da real síndrome do impostor, eu sabia que não era. Eu estava, sim, enfrentando o meu maior desafio profissional do ponto de vista intelectual - e não tava evoluindo tão bem quanto eu gostaria. "Não é sindrome do impostor se você realmente não sabe." Vi essa frase meio óbvia em um tweet hoje e me identifiquei bastante.

Eu até conseguia ver alguns pontos bons no meu trabalho, sabia que eu era importante, comprometida e conseguia desafogar o time, mas isso não me impedia de ter crises, em algumas épocas, diárias. A importância que eu dou ao meu trabalho faz com que uma insatisfação profissional afete todos os outros campos da minha vida.

Foi há pouco mais de dois meses que, em uma retrospectiva do time, a coisa começou a mudar. Na dinâmica de check-in, enquanto todo mundo demonstrou que estava em ascenção, eu disse, com toda a convicção, que me via regredindo. Eu sentia como se eu estivesse desaprendendo o pouco que eu tinha aprendido. Decidimos fazer uma rodada de reuniões de feedback e aí, junto com o acompanhamento terapêutico, comecei um processo de guinada lenta, mas significativa.

Pouco tempo depois, eu tomei coragem de compartilhar com meus colegas algumas das coisas que eu vinha lendo sobre pair programming e, embora eu não tenha curtido a experiência de "palestrar", fiquei muito feliz ao sentir a melhora nas dinâmicas de pair programming da minha equipe. Foi então que pensei em apresentar uma versão nano dessa conversa no espaço de lightning talks (LT) da python brasil de 2019. Parece bobo dizer que subir num palco durante três minutos causou uma mudança significativa, mas, bem, aconteceu.

(e aqui talvez caiba um parágrafo para explicar as lightning talks para um possível leitor que ainda não conheça. As LTs são palestras curtíssimas, com inscrição na hora, por qualquer participante do evento, sobre um tema qualquer. Qualquer. É sério. Eu vi gente dançando, fazendo repente, cantando e até imitando o barulho de saxofone com as mãos como instrumento. Também já vi a Milena jogando luz à questão do óleo que vem destruindo o litoral nordestino, sem a devida atuação do governo e sem a devida cobertura da mídia tradicional. Três minutos de uma mensagem extremamente importante, emocionante e necessária. E sim, também fala-se bastante de tecnologia nas lightning talks.)

Três minutos. Era menos tempo do que os cinco que eu tinha imaginado que seriam quando cogitei me inscrever pras LT. O primeiro ensaio tinha durado 4 minutos e 27 segundos, e eu ainda achava que tava muito corrido. Mesmo assim, preparei os slides para que, caso viesse a coragem, eu estivesse pronta. Então me inscrevi. Fui chamada rápido demais para dar tempo de desistir.

Tive sorte que a luz do palco não me permitia olhar direito para a plateia, mas sei que era uma sala com muita, muita gente. Eu sinceramente nem sei quantas pessoas, mas provavelmente mais de cem, ou mais de duzentas. Ou mais de trezentas. Amigos, conhecidos e muitos desconhecidos. Eu não sabia qual desses grupos me deixaria mais nervosa se eu pudesse vê-los. Foi tudo tão rápido que eu nem sei o que eu senti. Achei que tinha falado merda uma hora, mas eu não tinha tempo para me explicar então segui. Isso é difícil porque eu sou uma pessoa que me explica bastante. Também não pedi desculpas, e isso também é bem difícil para mim hehehe

Pouquíssimo tempo depois, eu já estava de volta à plateia. O evento seguiu.

Eu não tinha percebido o quanto tudo aquilo tinha me afetado até voltar pra casa. Até ir trabalhar. Até ter energia, muita energia. Ter, de novo, vontade de fazer coisas. Voltei na segunda e, na terça, já tinha uma reunião marcada para tirar um evento do papel. No trabalho, aconteceram algumas coisas que, na semana anterior, teriam me deixado de cama, chorando, com um sorvete sabor fossa do lado e uma carta de pedido de demissão do outro. Por mais esquisito que parecesse para mim, dessa vez eu não me abalei.

E aí que hoje, essa quinta-feira, veio uma realização banal, mas, de novo, surpreendente para mim: eu percebi, de forma estranhamente satisfatória, que eu fui e sou agente de mudança positiva entre os que me rodeiam. Parece besta, mas só eu sei o tamanho da importância disso para mim.

Tá tudo fluindo como se tivessem trocado uma lâmpada que tava piscando, sabe? É uma sensação calma, de fluxo desimpedido, sem euforia, com seus altos e baixos até, mas plena. Não sei até quando dura, mas eu não quero que acabe.

Esse ano, pela primeira vez, eu falei que eu me odiava. Mais de uma vez. Me odiava em todos os aspectos. Hoje, eu não sinto mais isso. E isso é muito importante para mim :)

O que evitar quando programar em par

Júlia Kastrup — Tue, 01 Oct 2019 03:32:56 +0000

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?