
Tive um professor na pós-graduação que costumava dizer: “Na hora da prática, a boa teoria resolve.” Confesso que a frase me soava pretensiosa no início: quem nunca viu uma teoria linda no papel virar um desastre na implementação? Mas com o tempo, entendi a profundidade dessa afirmação: uma teoria bem construída, nascida da observação cuidadosa ou do raciocínio claro, pode ser um verdadeiro mapa confiável quando chega a hora de agir. O problema não está em escolher entre teoria ou prática, mas sim em entender como elas se alimentam mutuamente. O artigo Teoria versus Prática explora essa questão.
Mas, além desse artigo, aqui no blog também temos diversos outros artigos sobre kubernetes, desenvolvimento, gestão, devops, etc. Veja alguns exemplos: Diferenças entre Paradigmas, Axiomas e Hipóteses, Desenvolver na empresa ou comprar pronto, Fuja da otimização prematura, entre outros.
Sumário
- Teoria que vem da prática
- Prática que vem da teoria
- Prática puramente experimental
- Externalização do Conhecimento
- Conclusão de Teoria versus Prática
- Bounded Contexts: Upstream-Downstream
- OKR na prática
- Diferenças entre Paradigmas, Axiomas e Hipóteses
- Specification Pattern no Domain Driven Design
- O Essencial do Hadoop
- O que são Ativos e Passivos Financeiros?
- Não confio em quem não erra
- Estrutura de camadas e Domain Driven Design
Teoria que vem da prática
A teoria que surge da prática é o que poderíamos chamar de “conhecimento destilado”, parafraseando Eric Evans. Ela nasce da observação do mundo real, da consolidação de padrões e do refinamento progressivo de experiências empíricas. Um exemplo marcante é o ITIL. Antes de ser um framework, o ITIL foi uma coleção informal de boas práticas que diferentes empresas britânicas já utilizavam na gestão de seus serviços de TI. A sistematização veio bem depois. E justamente por isso ela resiste ao tempo: está enraizada em problemas reais e soluções validadas.
Outro exemplo riquíssimo são os Design Patterns. Eles não foram inventados do zero em uma sala de aula, mas surgiram da observação de soluções recorrentes para problemas semelhantes encontrados por desenvolvedores experientes ao longo de muitos projetos. O famoso livro Design Patterns: Elements of Reusable Object-Oriented Software, dos Gang of Four, não criou novas estruturas, apenas formalizou e deu nome a elas.
Prática que vem da teoria
Já a prática que vem da teoria segue um caminho mais complicado. Neste caso, parte de uma abstração: um modelo mental, uma hipótese sobre como as coisas deveriam funcionar. Em seguida, esse modelo é testado na realidade. Só que aqui entra uma armadilha: toda teoria é uma simplificação. Ela recorta a complexidade do mundo e, por isso, nunca alcança integralmente a prática. Quando a prática nasce da teoria, ela é mais frágil por ser um ensaio ou experimento.
Um exemplo claro é o das criptomoedas. A ideia nasceu de um whitepaper técnico — uma teoria sobre confiança distribuída, consenso descentralizado e economia digital sem intermediários. Só depois vieram as implementações práticas: blockchains, carteiras digitais, mecanismos de mineração, exchanges, tokens, etc. Algumas dessas práticas funcionaram, outras colapsaram. Por isso, práticas derivadas diretamente da teoria costumam ser mais instáveis: elas ainda estão sendo testadas. Em compensação, quando bem-sucedidas, podem provocar saltos disruptivos. E note, tudo software desenvolvido é uma prática que vem da teoria, portanto todo software é um experimento.
Prática puramente experimental

Existe ainda uma terceira via: a prática que surge sem qualquer teoria por trás, é pura experimentação. É a prática improvisada, instintiva, motivada por tentativa e erro. Ela acontece quando não há tempo, recursos, interesse ou até organização para estruturar uma base teórica antes. Um vendedor de rua que muda sua abordagem de atendimento com base na reação dos clientes está aplicando esse tipo de prática. Startups que pivotam repetidamente sem seguir uma metodologia clara também operam nesse modo, apostando tudo em validação empírica imediata.
Essa prática é valiosa, especialmente em contextos voláteis ou inexplorados. Pode gerar soluções criativas, inovadoras e inesperadas. No entanto, ela tem um limite: dificilmente é replicável em larga escala ou transferível para outros contextos sem perdas. Como não foi sistematizada, ela depende muito de quem a aplica e das circunstâncias específicas em que surgiu. Só quando essa prática é observada, documentada e compreendida, ela pode dar origem a uma teoria — e aí entrar no ciclo virtuoso do aprendizado organizacional e coletivo.
Externalização do Conhecimento
Para que essas dinâmicas entre teoria e prática funcionem de maneira evolutiva, é fundamental haver externalização do conhecimento. O modelo SECI, desenvolvido por Nonaka e Takeuchi, mostra como o conhecimento circula entre quatro estados: socialização, externalização, combinação e internalização. A externalização é, talvez, o mais crítico. Ele trata da transição do conhecimento tácito (intuitivo, pessoal, difícil de expressar) para o conhecimento explícito (documentado, compartilhável, transmissível). É quando a experiência individual vira aprendizado coletivo.
Conclusão de Teoria versus Prática
Em resumo, a tensão entre teoria e prática não deve ser encarada como uma disputa, mas como um diálogo. Então, a boa teoria, como dizia meu professor, é aquela que sobrevive ao teste da prática — e a prática, por sua vez, evolui quando é iluminada por boas teorias. Assim, é nesse vai e vem que o conhecimento se refina, que o improviso vira método, e que a intuição se transforma em estrutura. Não é uma questão de dizer que um lado é melhor do que o outro, mas de reconhecer que agir sem pensar é perigoso, e pensar sem agir é inútil.
Ele atua/atuou como Dev Full Stack C# .NET / Angular / Kubernetes e afins. Ele possui certificações Microsoft MCTS (6x), MCPD em Web, ITIL v3 e CKAD (Kubernetes) . Thiago é apaixonado por tecnologia, entusiasta de TI desde a infância bem como amante de aprendizado contínuo.