Primeiro projeto em grupo na faculdade: o que não aprendi em nenhum tutorial
Trabalhar em grupo num projeto de faculdade parece simples. Na prática é onde você aprende divisão de trabalho, conflito de código, e por que comunicação é parte do trabalho técnico.
O primeiro projeto em grupo foi um sistema de biblioteca — cadastro de livros, empréstimos, devoluções.
Nada sofisticado. Mas era o primeiro projeto onde código de pessoas diferentes precisava funcionar junto. E foi onde aprendi que código colaborativo é diferente de código solo de formas que nenhum exercício individual prepara você.
A primeira decisão que ninguém havia tomado: quem faz o quê.
Em exercícios individuais, você define o escopo, você divide as partes, você decide o ritmo. Em grupo, essas decisões precisam ser negociadas. E sem processo explícito — sem ninguém que já tivesse feito isso antes — o padrão emergente foi: quem pegou a tarefa primeiro fez; o que sobrou ficou para quem estava disponível.
Isso funcionou até o segundo sprint, quando dois colegas tinham editado o mesmo arquivo sem saber. Os arquivos eram incompatíveis. A solução foi um dos dois refazer a parte que conflitava.
Aprendi git diff antes de aprender git flow.
O que complica não é o código. É a interface entre o código de pessoas diferentes.
Meu colega criou uma função que retornava null quando livro não era encontrado. Minha parte chamava essa função e assumia que retornava o livro ou lançava exceção. Quando a integração aconteceu, metade dos fluxos quebrava silenciosamente.
Não era bug de lógica. Era contrato de interface não combinado.
Esse problema — duas partes do sistema com premissas diferentes sobre o que acontece em caso de erro — é o problema central de sistemas distribuídos. Aprendi na versão pequena, em Python, num projeto de faculdade. A escala muda. O problema é o mesmo.
O que me ajudou: experiência de comunicação de operações.
No suporte de TI, quando você vai ao cliente resolver problema, você precisa entender o que o outro espera antes de começar a trabalhar. Chegei ao projeto com esse hábito — de perguntar "o que você espera receber?" antes de sair escrevendo código.
Os colegas sem experiência de trabalho tendiam a começar a implementar imediatamente. A integração depois era mais difícil porque as premissas haviam divergido durante o desenvolvimento.
A reunião de alinhamento antes de começar não é reunião desnecessária — é a que evita a reunião de "como integramos isso agora" no final.
O que aprendi sobre trabalho em grupo que não estava em nenhum tutorial:
Dividir por camada é perigoso sem interface clara. "Você faz o banco, eu faço o front" funciona se vocês concordam sobre o contrato entre as camadas antes. Sem isso, a integração é um projeto separado.
Código que funciona isolado não garante que funciona junto. Testei minha parte o tempo todo. Na integração, coisas quebravam. O sistema é mais do que a soma das partes.
Decisões técnicas são decisões de time. Quando mudei o nome de uma variável que outro colega estava usando, quebramos a build. Sem comunicação, refatoração local vira conflito global.
Velocidade individual não é velocidade de time. O colega mais rápido acabou bloqueado esperando a parte mais lenta. O gargalo não era habilidade técnica — era dependência não mapeada.
Esse projeto foi a primeira vez que percebi que engenharia de software em time é uma disciplina diferente de programar sozinho.
Não é só escrever código melhor. É criar condições para que código de pessoas diferentes funcione junto — com coordenação, contratos claros, comunicação contínua.
Aprendi isso num projeto de biblioteca em Python no primeiro ano de faculdade. A lição ficou para muito além.
Essa semana: qual é a interface do seu código que você assumiu que estava clara mas nunca combinou explicitamente com quem usa?