pareamento para dev junior: como pedir ajuda sem virar sombra

Pareamento assusta muito dev junior porque parece que alguém vai sentar do seu lado para descobrir tudo que você não sabe.

Na prática, pareamento bom é o contrário. É uma forma de reduzir ruído quando você já tentou sozinho, registrou contexto e precisa de outro cérebro para atravessar um trecho específico. Pode ser pair programming, call rápida, revisão parcial, leitura conjunta de erro, debug compartilhado ou alguém vendo você navegar pelo código por 20 minutos.

O problema começa quando pareamento vira um destes extremos: você evita pedir ajuda até travar o dia inteiro, ou pede ajuda cedo demais e transforma a pessoa sênior em GPS de cada clique.

Este guia é para usar pareamento com maturidade no estágio, primeira vaga tech, suporte técnico, QA, dados, produto técnico ou desenvolvimento. A meta não é parecer independente o tempo todo. A meta é sair da conversa mais autônomo do que entrou.

Se você ainda está calibrando o primeiro mês, leia também primeiros 30 dias como dev junior e daily como dev junior. Pareamento funciona melhor quando daily, PR e 1:1 já mostram contexto, não surpresa.

pareamento não é aula particular

Pareamento não é chegar em call e falar:

Não entendi nada. Você consegue me explicar esse sistema?

Isso é amplo demais. A pessoa não sabe por onde começar, você vira espectador e a conversa vira palestra improvisada.

Também não é:

Você pode fazer comigo?

Essa frase parece inofensiva, mas pode soar como terceirização. O objetivo não é alguém fazer por você. É vocês olharem juntos para um problema delimitado.

Pedido melhor:

Estou travado na validação do cadastro.

Já encontrei o endpoint, rodei o teste X e reproduzi o erro com usuário sem telefone.
Minha dúvida é onde a regra deveria ficar: frontend, backend ou os dois.

Você consegue parear 20 min para eu validar o caminho antes de abrir PR?

Perceba a diferença: existe escopo, tentativa, hipótese e limite de tempo.

quando pedir pareamento

Peça pareamento quando o problema tem custo alto se você continuar sozinho.

Bons sinais:

• você tentou por 30 a 60 minutos e não saiu do mesmo ponto;
• a tarefa encosta em produção, dado sensível, pagamento ou regra crítica;
• você tem duas opções técnicas e não sabe qual é mais segura;
• o PR começou a crescer além do combinado;
• o mesmo comentário voltou em dois reviews;
• você não consegue reproduzir um bug que outra pessoa consegue;
• a documentação contradiz o comportamento do sistema;
• você precisa entender um fluxo antes de mexer nele.

Sinais ruins:

• pedir pareamento antes de ler o ticket;
• pedir pareamento sem rodar o projeto;
• pedir pareamento para evitar escrever uma pergunta;
• pedir pareamento porque está ansioso, mas sem situação concreta;
• pedir pareamento para alguém decidir tudo por você.

Ansiedade é real, mas precisa virar recorte. Em vez de “estou perdido”, tente “estou perdido entre estes dois arquivos e preciso entender qual deles controla a regra”.

chegue com o contexto pronto

Antes de chamar alguém, escreva um bloco curto. Não precisa ser bonito. Precisa ser útil.

Modelo:

Contexto:
- ticket: BUG-234
- objetivo: mostrar mensagem quando CPF vem inválido
- ambiente: local com dados de teste

O que tentei:
- rodei fluxo pelo navegador
- chamei endpoint direto pelo Postman
- procurei validação em cadastro.service.ts e cpf.ts

O que aconteceu:
- backend retorna 400
- frontend mostra erro genérico

Minha hipótese:
- preciso mapear esse 400 para mensagem específica no frontend

Pedido:
- parear 20 min para validar se esse é o lugar certo antes do PR

Esse bloco economiza metade da call. A pessoa que vai ajudar não precisa arrancar informação de você. Ela entra no problema já com trilha.

Se você mantém um caderno de trabalho, como no guia de anotações para dev junior, esse contexto fica mais fácil. Você copia tentativa, erro, hipótese e próximo passo em vez de depender da memória.

combine a regra da call

Pareamento ruim começa sem combinado.

Antes de compartilhar tela, alinhe:

• tempo disponível;
• objetivo da sessão;
• quem dirige o teclado;
• se a pessoa vai explicar ou só fazer perguntas;
• qual saída esperada.

Exemplo:

Tenho 20 min. Queria sair com o caminho validado, não necessariamente com código pronto.
Posso compartilhar minha tela e dirigir? Se eu for pelo caminho errado, você me interrompe.

Isso mostra maturidade. Você não está pedindo que a pessoa assuma sua tarefa. Está pedindo calibração.

Em alguns casos, faz sentido a pessoa sênior dirigir por poucos minutos para mostrar uma técnica: usar debugger, navegar logs, rodar teste específico, ler stack trace. Tudo bem. Só não vire plateia passiva. Peça para repetir depois com seu teclado.

durante o pareamento, fale seu raciocínio

O silêncio deixa a outra pessoa adivinhar se você está pensando, perdido ou só esperando instrução.

Narre o mínimo:

Vou começar pelo teste porque ele mostra o comportamento esperado.
Agora vou reproduzir pelo navegador para confirmar que é o mesmo erro.
Aqui eu esperava uma mensagem específica, mas veio fallback genérico.
Minha dúvida é se esse mapeamento já existe em outro fluxo.

Isso não é teatro. É debug compartilhado.

Também ajuda quem está te ajudando a corrigir o raciocínio, não só o código. Às vezes o problema não é a linha que você escreveu. É a ordem de investigação.

Se você não sabe o que fazer, diga exatamente isso:

Não sei qual próximo arquivo olhar. Eu olhei X por causa do nome, mas não encontrei chamada. Como você procuraria isso?

Pergunta boa pede método. Pergunta ruim pede resposta final.

anote sem virar secretária da call

Você precisa anotar, mas não pode passar a call inteira digitando.

Anote só quatro coisas:

• decisão tomada;
• comando ou arquivo importante;
• motivo da decisão;
• próximo passo.

Exemplo:

Pareamento - BUG-234

Decisão:
- mensagem específica fica no frontend porque backend já retorna código estável

Arquivo:
- src/errors/map-api-error.ts

Motivo:
- outros fluxos fazem mapeamento ali; evita duplicar regra no componente

Próximo passo:
- adicionar caso CPF_INVALIDO + teste unitário do mapper

Depois da call, isso vira comentário no ticket, descrição do PR ou nota para sua próxima 1:1.

saia com tarefa menor

Pareamento bom termina com próximo passo executável.

Não termine com:

Vou estudar melhor esse fluxo.

Isso é vago.

Termine com:

Vou adicionar o mapeamento do erro CPF_INVALIDO, criar o teste do mapper e abrir PR pequeno hoje. Se eu travar na mensagem do componente, aviso no canal com o contexto da call.

Agora existe ação.

Se a tarefa continua grande, reduza escopo:

• abrir PR só com teste reproduzindo o bug;
• ajustar só o caso mais simples;
• escrever nota técnica antes de codar;
• pedir review parcial;
• transformar descoberta em subtarefa.

Junior cresce muito quando aprende a sair de conversa com próximo movimento pequeno.

depois, devolva visibilidade

Quem te ajudou precisa saber que a ajuda virou progresso.

Mande uma atualização curta:

Valeu pelo pareamento de hoje.

Segui o caminho combinado: mapeei CPF_INVALIDO no frontend, adicionei teste do mapper e abri o PR #123.
Deixei na descrição o contexto que vimos na call.

Essa mensagem faz duas coisas: fecha o loop e mostra que você não dependeu da pessoa para cada passo seguinte.

Também melhora sua imagem em code review. O revisor vê que houve contexto, decisão e execução. O guia de code review como dev junior continua esse fluxo depois que o PR está aberto.

quando pareamento vira muleta

Pareamento é ferramenta. Muleta é quando você não tenta andar sem ela.

Sinais de alerta:

• você só trabalha quando alguém está em call;
• você pede pareamento para tarefas repetidas que já foram explicadas;
• você não anota decisões e pergunta a mesma coisa de novo;
• você sai da call sem conseguir explicar o que foi decidido;
• você usa “sou junior” para não formar hipótese.

Se isso está acontecendo, ajuste o formato. Peça que a pessoa faça mais perguntas e dê menos resposta pronta. Combine que você vai tentar sozinho depois da primeira orientação. Transforme cada pareamento em checklist para o próximo caso parecido.

Exemplo:

Da próxima vez que erro de API aparecer, vou seguir esta ordem:
1. reproduzir pelo navegador;
2. chamar endpoint direto;
3. localizar mapper de erro;
4. procurar teste parecido;
5. pedir ajuda só se a regra não estiver clara.

Autonomia não é nunca pedir ajuda. Autonomia é pedir ajuda cada vez melhor.

pareamento remoto

No remoto, pareamento precisa de mais higiene.

Antes da call:

• feche abas pessoais;
• deixe branch limpa;
• rode o projeto antes;
• abra ticket, terminal e arquivo provável;
• verifique microfone;
• compartilhe a janela certa, não a vida inteira.

Durante a call:

• mantenha zoom suficiente para a pessoa ler;
• repita em voz alta quando mudar de hipótese;
• não esconda erro de terminal passando rápido;
• se a conexão travar, cole comando e erro no chat.

Depois:

• registre a decisão no ticket ou PR;
• agradeça sem textão;
• execute o próximo passo antes de pedir nova sessão.

Se trabalho remoto ainda está te atropelando, o guia de rotina remota para junior ajuda a montar o ambiente onde pareamento não vira socorro de emergência todo dia.

checklist antes de pedir pareamento

Antes de chamar alguém, confira:

• li o ticket inteiro;
• rodei o projeto ou o teste relevante;
• tentei por tempo suficiente, sem virar teimosia;
• escrevi o que tentei;
• tenho uma hipótese, mesmo fraca;
• sei qual decisão preciso validar;
• consigo pedir 15 a 30 minutos, não “uma ajuda aí” infinita;
• vou anotar decisão e próximo passo.

Se você não consegue marcar nenhum item, talvez ainda seja hora de investigar sozinho por mais alguns minutos.

Se consegue marcar quase todos, pedir pareamento é profissional, não fraqueza.

o objetivo é voltar diferente

O melhor pareamento não é aquele em que a pessoa sênior resolve tudo em cinco minutos. Isso até pode salvar uma tarefa, mas não necessariamente te ensina.

O melhor pareamento é aquele em que você volta com um método:

• como procurar fluxo parecido;
• como reproduzir bug;
• como escolher onde a regra mora;
• como reduzir PR;
• como escrever pergunta melhor;
• como testar antes de pedir review.

No começo, você talvez precise de mais sessões. Normal. Mas cada sessão deve deixar rastro: nota, checklist, PR menor, pergunta melhor, decisão registrada.

Pareamento para dev junior não é prova oral. É ferramenta de transferência de contexto. Use bem e você deixa de ser a pessoa que “precisa de ajuda” para virar a pessoa que sabe destravar com método.