O que ninguém te conta sobre trabalhar para fora: o problema não é o inglês

Quando entrei na Joyjet, uma fábrica de software francesa atendendo clientes de vários países, meu inglês estava longe do ideal. Meu francês era zero. E mesmo assim, as reviews de código não eram o meu problema. A arquitetura das entregas não era o meu problema.

O meu problema era explicar por que eu tinha tomado uma decisão.

Não a decisão em si. O raciocínio por trás dela.

Existe uma crença muito comum entre engenheiros brasileiros que querem atuar em times internacionais: o gargalo é o inglês. E eu também acreditei nisso por um tempo. Fiz curso, melhorei a pronúncia, ampliei vocabulário técnico.

Mas quando comecei a trabalhar de verdade com times na França, nos Estados Unidos e depois de forma remota com empresas americanas, percebi que o idioma era o problema mais fácil de resolver.

O problema real era outro.

O que times internacionais esperam que ninguém te ensina

Em times internacionais bem estruturados, a expectativa não é que você escreva código melhor. A expectativa é que você seja capaz de rastrear o seu próprio raciocínio em público.

Não basta decidir bem. Você precisa conseguir articular a decisão de forma que alguém em outro fuso, com outro contexto cultural e técnico, consiga entender o trade-off que você fez, sem precisar te perguntar nada.

Isso parece óbvio quando você lê. Mas é muito mais raro do que parece.

Na Photozig, trabalhando com um time em San Francisco, a primeira vez que abri um PR com uma migração de AVFoundation para FFmpeg em um fluxo de edição de vídeo, a descrição estava tecnicamente correta. Explicava o quê. Não explicava o porquê, não documentava o que eu tinha descartado, não mencionava o custo de manutenção que a abordagem trazia.

O feedback que recebi não foi sobre o código. Foi sobre a ausência de contexto.

"Why FFmpeg over AVFoundation natively?" Uma pergunta simples que revelou um problema que eu carregava há anos sem saber.

Eu tomava decisões boas mas não as comunicava. E num time distribuído, uma decisão que não está comunicada não existe.

A Síndrome do Código que se Explica Sozinho

Engenheiros formados em ambiente brasileiro muitas vezes carregam uma crença implícita de que código bom se explica sozinho. Que se a arquitetura está bem feita, o revisor vai entender.

Eu também pensava assim.

O problema é que isso funciona quando você trabalha com alguém que está sentado ao seu lado, que participou das mesmas reuniões, que conhece as mesmas restrições de negócio, que ouviu a mesma conversa com o produto na semana passada.

Em times distribuídos, ninguém compartilha esse contexto por osmose. Ninguém ouviu a reunião. Ninguém sabe que você descartou a opção A porque o time de infra bloqueou a dependência. Ninguém sabe que a abordagem atual é temporária.

E o custo disso não aparece no PR. Aparece três meses depois quando alguém refatora algo "errado" porque não sabia que estava correto por uma razão específica.

O problema real da carreira internacional não é idioma, é registro

O que times internacionais treinam, conscientemente ou não, é a capacidade de registrar raciocínio.

RFC antes de implementar. ADR depois de decidir. Descrição de PR que explica o contexto, não só o diff. Comentário no código que explica o porquê, não o quê.

Isso não é burocracia. É o mecanismo que permite que um time distribuído, com pessoas em três fusos e rotatividade natural, continue tomando decisões coerentes ao longo do tempo.

Quando migrei de VIPER para MVVM num módulo de reputação numa base com múltiplos times em paralelo, a decisão precisava estar documentada de forma que qualquer engenheiro novo pudesse entender a motivação sem me perguntar. Porque eu não estaria disponível. Porque o time ia mudar. Porque em seis meses ninguém lembraria da reunião onde discutimos isso.

Registro de raciocínio não é habilidade de escrita. É habilidade de engenharia.

O que isso tem a ver com senioridade

Senioridade em contexto internacional não é só profundidade técnica. É a capacidade de operar de forma assíncrona sem perder coerência.

Um engenheiro sênior brasileiro pode ter arquitetura impecável e ainda assim parecer júnior num time americano porque não consegue se fazer entender de forma escrita, sem sincronia, sem o benefício da dúvida cultural que existe quando você está no mesmo escritório.

E o inverso também existe. Engenheiros internacionais medianos que parecem muito mais sênior porque comunicam bem, registram bem, criam contexto antes de precisar dele.

Isso desequilibra o jogo de uma forma que ninguém gosta de admitir.

O que eu mudei

Comecei a tratar a descrição do PR como parte do código. Não como formalidade.

Comecei a escrever o motivo de cada decisão relevante antes de implementar, mesmo que fosse só um parágrafo numa issue.

Comecei a perguntar, quando revisando código de outras pessoas: "por que não X?" Não para questionar. Para criar o hábito de articular o descarte de alternativas.

Parece simples. Levou mais tempo do que deveria para eu perceber que era isso.

O trade-off honesto

Isso tem um custo real. Registrar raciocínio leva tempo. Escrever boa documentação de decisão é mais difícil do que escrever código. E em times com pressão de entrega alta, esse hábito é o primeiro a ser sacrificado.

O problema é que o custo de não registrar não aparece agora. Aparece quando o time cresce, quando o engenheiro que tomou a decisão sai, quando a base começa a acumular decisões sem memória.

E aí você para de entender o próprio sistema que você construiu.

O que a carreira internacional me ensinou de verdade

Depois de trabalhar com times no Brasil, na França e nos Estados Unidos, a diferença mais consistente que observei não estava na stack, não estava nos processos, não estava no nível técnico.

Estava na proporção de engenheiros capazes de comunicar raciocínio técnico por escrito, de forma clara, para alguém que não estava lá quando a decisão foi tomada.

E essa habilidade não é ensinada em curso de inglês. Não vem de certificação. Não aparece no currículo.

Ela aparece na primeira vez que alguém do outro lado do mundo lê o seu PR e entende, sem precisar te perguntar nada, por que você fez o que fez.

Ou não entende. E aí você percebe que tem trabalho a fazer.