Eu passei anos estudando, lendo, quebrando sistemas e reconstruindo. Em algum momento, cheguei numa arquitetura que fazia sentido pra mim. Separação clara de responsabilidades. Regras de negócio isoladas. Dependências apontando pra dentro, nunca pra fora. Não era nada revolucionário. Era o que sobrou depois de eliminar tudo que dava problema.
Aí eu descobri um cara chamado Robert C. Martin. E a Clean Architecture dele.
Quando eu fui estudar, levei um susto. A estrutura era assustadoramente parecida com o que eu já usava. Obviamente, a dele era muito mais robusta, mais evoluída, formalmente documentada. A minha ainda era embrionária. Mas o esqueleto era o mesmo.
Eu não copiei. Eu não tinha lido. Eu cheguei ali sozinho.
E isso me intrigou por anos. Até eu entender que não era coincidência.
Convergência cognitiva
Isso tem nome. Convergência cognitiva. É o fenômeno onde indivíduos com trajetórias distintas, expostos a desafios parecidos, chegam em padrões parecidos. Não porque combinaram. Porque as restrições do problema empurram todo mundo na mesma direção.
Quando você enfrenta os mesmos problemas por tempo suficiente, o espaço de soluções viáveis vai encolhendo. E o que sobra se parece muito com o que sobra pra qualquer outra pessoa que tenha enfrentado os mesmos problemas pelo mesmo tempo.
Eu vejo isso acontecer o tempo todo. Coloca dois desenvolvedores seniores na mesma sala. Experiências diferentes. Empresas diferentes. Stacks diferentes. Um veio do Java enterprise, o outro do mundo startup com Node. Um passou por banco, o outro por e-commerce.
Faz uma pergunta sobre arquitetura. Sobre como organizar código. Sobre quando usar um monolito e quando partir pra microsserviços.
Eles vão discordar nos detalhes. Vão usar vocabulários diferentes. Mas a essência da resposta vai ser assustadoramente parecida.
A estrada em perspectiva
A melhor forma que eu encontrei de explicar isso é com uma imagem.
Imagina uma estrada longa em perspectiva. Aquelas que vão afunilando no horizonte. Se você olhar perto de você, duas pessoas caminhando, cada uma em um lado da estrada, parecem distantes uma da outra. Mas lá na frente, elas estão juntas. Quase no mesmo ponto.
É exatamente isso que acontece com experiência.
Quando você é júnior, o espaço de possibilidades parece infinito. Frameworks, padrões, arquiteturas. Tudo parece viável. Tudo parece questão de preferência. Você e o dev do lado podem discordar sobre absolutamente tudo.
Mas conforme vocês avançam, as restrições vão aparecendo. Não as restrições que alguém te conta. As que você sente. Sistemas que quebraram às 3 da manhã. Abstrações elegantes que ninguém conseguia manter. Decisões que pareciam simples e custaram meses de refatoração.
Cada cicatriz dessas elimina possibilidades. Cada fracasso fecha uma porta.
E o que sobra, quando você fecha portas suficientes, é surpreendentemente parecido com o que sobra pra qualquer outro dev que tenha fechado portas suficientes.
A gravidade da engenharia de software
A estrada afunila. Mas por quê?
Porque o problema tem forma. E a forma tem menos soluções do que parece.
Humanos precisam ler código. Sistemas precisam escalar de forma previsível. Complexidade tem custo composto. Times mudam. Requisitos mudam. Essas forças são constantes.
São a gravidade da engenharia de software. E a gravidade não negocia.
Martin Fowler, Kent Beck, Uncle Bob. Backgrounds diferentes, épocas diferentes, contextos diferentes. Mas quando falam sobre design de software, as ideias se sobrepõem de um jeito que não pode ser coincidência. Separação de responsabilidades. Favorecer composição. Código que comunica intenção. Testes como rede de segurança.
Ninguém combinou. O problema combinou.
Não é que seniores são iguais. É que a gravidade é a mesma. E quem respeita a gravidade por tempo suficiente acaba construindo estruturas parecidas.
A meta-teoria
Mas tem uma segunda camada aqui que me fascina ainda mais.
Não é só que profissionais experientes convergem nas mesmas soluções. É que pessoas chegam em ideias que já foram pensadas, documentadas e nomeadas por outras, sem nunca ter tido contato com elas.
Foi o que aconteceu comigo e a Clean Architecture. E acontece o tempo todo na história.
Newton e Leibniz inventaram o cálculo diferencial de forma independente, quase ao mesmo tempo. Darwin e Wallace chegaram na teoria da evolução por seleção natural sem um saber do trabalho do outro. O sociólogo Robert K. Merton estudou esse fenômeno e deu um nome: multiple independent discovery. Ele mostrou que quando o ambiente está maduro o suficiente, quando o conhecimento acumulado chega num certo ponto, as mesmas ideias emergem em lugares diferentes, de pessoas diferentes, quase simultaneamente.
Não é mágica. É que o problema estava maduro. E pessoas imersas no mesmo problema, com ferramentas parecidas, chegam nas mesmas respostas.
E isso leva a uma pergunta que eu fiz pra mim mesmo, e que talvez seja a mais desconfortável desse texto: quantas vezes eu pensei em algo que já tem nome, já tem teoria, já tem documentação formal, e eu simplesmente não sabia?
Provavelmente mais vezes do que eu imagino. Provavelmente mais vezes do que qualquer um de nós imagina.
Quando os mapas se sobrepõem
Na última edição dessa série, falei sobre a construção da consciência. Sobre como avançar na carreira expande o mapa do que você sabe que não sabe. Sobre o fog of war que vai recuando conforme você ganha experiência.
A convergência cognitiva é o que acontece depois.
Quando duas pessoas limpam fog of war suficiente, elas começam a ver a mesma paisagem. Não porque estão no mesmo lugar, mas porque o terreno debaixo da névoa sempre foi o mesmo.
É por isso que um dev sênior brasileiro e um dev sênior finlandês, que nunca se falaram, vão concordar sobre princípios de software. Os dois navegaram terrenos diferentes. Mas o território que descobriram é, em grande parte, compartilhado.
Júniores divergem muito. Porque cada um tem um pedaço diferente do mapa. Seniores convergem. Porque, quando o mapa é grande o suficiente, a geografia começa a se repetir.
Convergência não é conformidade
Tem uma diferença importante aqui. E eu quero fechar com ela.
Convergir nos princípios não significa concordar em tudo. Dois seniores podem concordar que acoplamento é o inimigo. E discordar violentamente sobre como reduzir acoplamento naquele sistema específico. Podem concordar que testes são essenciais. E ter filosofias opostas sobre o que testar e como.
A convergência está nos princípios. A divergência criativa está na aplicação.
E é justamente essa tensão que produz boas soluções. Não a concordância cega. Mas a concordância sobre os fundamentos, combinada com a disputa honesta sobre a implementação.
Se você está em início de carreira, isso é bom. Significa que você não precisa inventar tudo do zero. Os princípios já existem. Foram descobertos e redescobertos por milhares de pessoas antes de você, em contextos que você nem imagina. Seu trabalho não é ser original nos fundamentos. É aplicar esses fundamentos no seu contexto, com as restrições do seu problema.
E se você é sênior e se sente frustrado quando um júnior sugere algo que “obviamente” não funciona, lembre: ele ainda está no começo da estrada. Onde tudo parece distante. Onde tudo parece possível. Dê tempo. As restrições vão fazer o trabalho.
A convergência é inevitável. A paciência com quem ainda não convergiu é uma escolha.
Até a próxima, Bruno
P.S. Se você curtiu essa reflexão, responde esse email com uma palavra: “convergiu”. Eu leio todas as respostas. E se tiver uma história parecida com a minha da Clean Architecture, onde você chegou numa conclusão que já existia, quero ouvir.