Git em software house vs. universidade — e o que pair programming muda nisso tudo
Usava git em time desde a universidade. Achei que estava pronto para uma software house. Não estava. Pair programming, code review comercial e cliente real revelaram camadas que a faculdade não ensina.
Desde 2017 eu usava git em time na universidade.
Branches, PRs, merge conflicts, code review. Não era novidade. Então quando entrei na POA Software em 2019 achei que a parte de colaboração estava resolvida.
Não estava.
Git em projeto de faculdade e git em software house com cliente real são a mesma ferramenta com pressão completamente diferente.
Na universidade, o pior que acontecia com um PR ruim era nota baixa ou comentário do professor.
Na POA Software, PR ruim atrasava entrega para cliente. A pressão era real de uma forma que projeto acadêmico não consegue simular. Mudou a forma como eu encarava cada commit:
Na uni: "funcionou, commita."
Na software house: "funcionou para mim agora — mas vai funcionar em produção, na máquina do cliente, daqui a 3 meses quando alguém precisar fazer manutenção sem meu contexto?"
Essa pergunta muda tudo.
Na POA Software comecei a trabalhar em par com um dev sênior.
O que me surpreendeu não foi a mecânica — driver/navigator, você alterna. Foi o quanto eu aprendi mais rápido do que em qualquer tutorial. Os erros eram capturados em tempo real, pelo ponto de vista de alguém com mais experiência, enquanto o código estava sendo escrito.
Em git, pair programming muda como você commita. Alguns times usam co-authorship no commit:
git commit -m "feat: add lead deduplication logic
Co-authored-by: Nome Colega <[email protected]>"
Não é formalidade. É rastreabilidade. E reconhecimento de que o trabalho foi conjunto.
Meu primeiro PR na software house voltou com 12 comentários.
Nenhum era "isso está errado". Eram todos "o que acontece quando...?" ou "por que você escolheu X em vez de Y?" ou "esse nome de variável vai fazer sentido daqui a 6 meses?" Aprendi que bom code review não aponta erros — faz as perguntas que revelam suposições não documentadas.
E aprendi que PR bem descrito recebe review melhor. Quando você explica o que muda, por que você fez dessa forma, e o que considerou mas descartou, o revisor pode focar nas decisões — não em reconstruir o contexto.
Git na faculdade te ensina os comandos. Software house com cliente te ensina commit como comunicação, PR como proposta, review como conversa, e que o histórico é documentação viva.
Essa semana: olha o último PR que você abriu. A descrição explica por que a mudança foi necessária, não só o que mudou? Se não, reescreve. O revisor vai agradecer — mesmo que seja você mesmo daqui a 3 meses.