A Corrida Maluca pela Tecnologia e o Poder dos Fundamentos: Por que uma Segunda Graduação Fez Sentido (Back to Basic B2)

"Vamos, rapazes, não fiquem aí parados. É só um pombo e precisamos pegá-lo. Essas medalhas eu vou arrancar. Muttley, faça alguma coisa!"

Essa frase, ecoando das manhãs de desenhos animados da minha infância, nunca me pareceu tão relevante para o mundo da tecnologia como hoje. Estamos todos em uma versão moderna da Esquadrilha Abutre, pilotando nossas máquinas complexas em uma perseguição frenética. O "pombo" assume muitas formas: o framework do momento, a próxima linguagem de programação disruptiva, a certificação que promete um salário de seis dígitos, a vaga na Big Tech. Nós corremos, traçamos planos mirabolantes, e muitas vezes, como o próprio Dick Vigarista, acabamos caindo em nossas próprias armadilhas, enquanto o pombo segue seu voo, indiferente.

É nesse cenário de perseguição constante, de uma "corrida maluca" por novidades efêmeras que ganham proporções absurdas, que tomei uma decisão que para muitos pareceu contraintuitiva: em 2022, decidi voltar para a universidade e iniciar uma segunda graduação, um Bacharelado em Engenharia de Software

Eu já tinha um caminho trilhado. Sou Bacharel em Engenharia Elétrica, uma formação que me deu uma base analítica robusta, e completei um MBA em Administração de Empresas, que me forneceu a lente dos negócios para enxergar o mundo. Desde 2018, eu já vinha em um "side study" intenso sobre programação, uma paixão que detalhei em outro post, Why I Fell in Love with Programming. Então, por que se submeter novamente ao rigor acadêmico, às provas, aos trabalhos e às noites mal dormidas? Por que, em vez de apenas aprender a última versão do React ou me aprofundar em mais uma ferramenta de nuvem, eu escolhi voltar para o início e estudar Cálculo, Estruturas de Dados e Arquitetura de Computadores mais uma vez?

A resposta, que se tornou mais clara a cada semestre, é o tema central deste artigo: em meio à loucura da corrida, a minha maior vantagem competitiva não estava em aprender a pilotar o avião mais rápido, mas em entender profundamente os princípios da aerodinâmica. Em outras palavras, o básico funciona. E não apenas funciona para tarefas específicas, mas serve como a fundação que expande a nossa caixa de ferramentas para resolver problemas genuinamente complexos.

Agora, a menos de um ano de concluir essa jornada, sinto que é o momento certo para compartilhar algumas das descobertas mais interessantes que essa segunda imersão acadêmica me proporcionou.

Para entender a minha decisão, é preciso primeiro dissecar a natureza da corrida que eu decidi, em parte, abandonar. A indústria de tecnologia opera em ciclos de hype cada vez mais curtos e intensos. A cada semana, surge uma nova biblioteca, um novo paradigma, uma nova "bala de prata" que promete resolver todos os nossos problemas anteriores.

Essa dinâmica cria uma cultura de FOMO (Fear of Missing Out) crônico. Desenvolvedores sentem uma pressão imensa para estarem constantemente atualizados. O currículo se torna uma lista de palavras-chave da moda. O aprendizado se transforma em um checklist: "Sei Docker? Check. Kubernetes? Check. GraphQL? Check. Machine Learning? Hmm, preciso ver um tutorial sobre isso no fim de semana."

O problema dessa abordagem é sua superficialidade. Aprendemos o "como" usar uma ferramenta, mas raramente o "porquê" ela existe e quais problemas fundamentais ela resolve. É como um piloto que sabe apertar os botões do painel, mas não tem ideia do que acontece dentro do motor. Enquanto tudo funciona, ele é eficaz. No primeiro sinal de uma turbulência inesperada ou de um som estranho vindo da asa, ele está perdido.

1. Desenvolvimento Guiado por Hype (Hype-Driven Development): Equipes escolhem tecnologias não porque são a melhor solução para o problema de negócio, mas porque são novas, empolgantes ou porque "o Google usa". Isso leva a sistemas super-engenheirados, difíceis de manter e que, muitas vezes, falham em entregar valor real.
2. A Ilusão da Produtividade: Ferramentas e frameworks modernos oferecem ganhos de produtividade impressionantes para tarefas comuns. Com poucas linhas de código, você pode ter um servidor web funcionando. Isso é fantástico, mas também cria uma camada de abstração tão grossa que nos isola da complexidade real do que está acontecendo. Quando algo quebra dentro da abstração, a depuração se torna um pesadelo.
3. A Desvalorização da Experiência: Em uma corrida onde apenas a novidade importa, a experiência com tecnologias mais antigas ou com os princípios subjacentes é muitas vezes vista como obsoleta. Um engenheiro que passou anos otimizando queries em SQL pode ser preterido por alguém que sabe o ORM da moda, mesmo que o segundo não entenda de fato como um banco de dados funciona.

É uma perseguição incessante pelo pombo da "relevância", onde o verdadeiro prêmio — a capacidade de resolver problemas de forma duradoura e elegante — é esquecido. Foi a percepção dessa armadilha que me fez apertar o freio e recalcular a rota.

Muitos me perguntam sobre o desafio de uma segunda graduação. E a resposta é simples: sim, fazer a segunda graduação é puxado. Conciliar o curso com trabalho, vida pessoal e a necessidade de sono é um exercício constante de gerenciamento de tempo e energia. E, para ser honesto, sim, muitas das coisas que eu vi na faculdade eu já conhecia por ter pesquisado ou trabalhado com elas.

Então, qual é a vantagem? A grande revelação para mim foi que a forma de absorver o conteúdo na segunda graduação foi completamente diferente da primeira. Foi como assistir a um filme pela segunda vez, mas agora com os "comentários do diretor" ligados na minha própria mente.

Na minha primeira graduação em Engenharia Elétrica, o aprendizado era, em grande parte, abstrato. Eu aprendia sobre transformadas de Fourier, equações de Maxwell e circuitos lógicos. Eu entendia a matemática e a teoria, mas a aplicação prática parecia distante, algo que eu só veria "no mercado". Era um conhecimento armazenado para uso futuro, sem um gancho imediato na realidade.

Na Engenharia de Software, com anos de experiência profissional nas costas, cada aula, cada conceito, cada teoria aterrissava em um terreno fértil de problemas reais que eu já havia enfrentado.

1. Estruturas de Dados e Algoritmos: Da primeira vez, seria uma disciplina sobre árvores, grafos e complexidade de tempo. Desta vez, ao estudar a complexidade O(n²), minha mente não via apenas uma fórmula, mas lembrava daquela API específica que ficava insuportavelmente lenta à medida que os dados cresciam, e eu finalmente entendia exatamente o porquê. A discussão sobre a diferença entre um ArrayList e um LinkedList não era teórica; era sobre a escolha que fiz em um projeto passado e as implicações de performance que ela teve.
2. Redes de Computadores: O modelo OSI e a pilha TCP/IP deixaram de ser um diagrama em um livro para se tornarem a explicação para cada requisição HTTP lenta, para cada problema de conectividade que já enfrentei. Quando entendi o OSPF pela perspectiva do algorítimo de de Dijkstra para encontrar o caminho mais curto.
3. Engenharia de Software e Padrões de Projeto: Conceitos como SOLID, Inversão de Dependência ou o padrão Strategy não eram apenas nomes a serem memorizados. Eram soluções elegantes para os "cabelos de código" que eu mesmo já tinha criado ou herdado. Cada padrão era um "aha!" que iluminava uma cicatriz de um projeto anterior.

Essa segunda passagem não era sobre aprender algo novo, mas sobre organizar o conhecimento tácito em uma estrutura formal. A experiência profissional me deu o "o quê" e o "onde" dos problemas; a faculdade me deu o "porquê" e o "como" de forma estruturada. Foi a diferença entre saber que um carro anda e entender como funciona um motor de combustão interna.

Chegamos ao cerne da questão. Eu acredito que o principal valor da graduação, especialmente em uma área tão dinâmica como a tecnologia, é que ela te força ao aprendizado do básico, ela te ensina o fundamento da resolução de problemas.

Enquanto a corrida maluca foca em colecionar ferramentas específicas (aprender Martelo Framework v3.2), a formação fundamental foca em construir a sua caixa de ferramentas (entender os princípios da alavancagem, da fixação e da distribuição de força). Com a primeira abordagem, você é ótimo com um martelo. Com a segunda, você pode não apenas usar qualquer martelo, mas também entender quando um pé de cabra, uma furadeira ou até mesmo um adesivo é a solução mais apropriada. E, se necessário, você tem os princípios para construir uma ferramenta nova.

• Arquitetura de Computadores e Sistemas Operacionais: Por que um desenvolvedor web precisa saber sobre hierarquia de memória (cache L1, L2, L3, RAM, SSD) ou sobre como o sistema operacional gerencia processos e threads? Porque cada linha de código que escrevemos eventualmente é executada por um processador e manipula dados na memória. Entender esses fundamentos permite escrever um código mais performático, diagnosticar gargalos de performance (o problema é CPU-bound ou I/O-bound?) e compreender as nuances de concorrência e paralelismo que são cruciais em sistemas modernos.
• Análise de Algoritmos (Notação Big O): Isso vai muito além de passar em entrevistas de codificação. É a linguagem universal para discutir a eficiência. É o que permite olhar para duas soluções que produzem o mesmo resultado e dizer, com base em princípios matemáticos, qual delas vai escalar de forma sustentável e qual vai derrubar o servidor quando o número de usuários dobrar. É a diferença entre uma solução que funciona para 100 usuários e uma que funciona para 10 milhões.
• Teoria de Banco de Dados: A explosão de bancos de dados NoSQL levou muitos a acreditar que a teoria relacional estava morta. Entender os princípios do modelo relacional, consistência, atomicidade (ACID) e normalização é essencial para fazer escolhas informadas. Você entende os trade-offs que um banco de dados NoSQL está fazendo (por exemplo, trocando consistência por disponibilidade) e pode decidir conscientemente se esse trade-off faz sentido para o seu caso de uso.
• Princípios de Engenharia de Software: O campo está repleto de metodologias (Agile, Scrum, Kanban) e princípios de design (SOLID, DRY, KISS). A corrida maluca nos ensina a seguir as cerimônias do Scrum. A abordagem fundamental nos ensina por que o Agile surgiu como uma resposta aos problemas do modelo Waterfall, quais são os valores por trás do manifesto e como adaptar as práticas para a realidade da sua equipe, em vez de segui-las cegamente. O mesmo vale para os princípios de design, que são guias heurísticos para escrever código manutenível, testável e extensível, independentemente da linguagem ou do framework.

Essa base sólida não te torna obsoleto; ela te torna antifrágil. Quando o próximo framework surgir, você não precisará começar do zero. Você o analisará através das lentes dos fundamentos: "Como ele lida com o gerenciamento de estado? Qual padrão de design ele implementa? Quais trade-offs de performance ele está fazendo?". O aprendizado se torna mais rápido, profundo e crítico.

Essa jornada também reforçou um hábito pessoal que considero vital. Adoro ler e tenho o costume de intercalar leituras técnicas, mais densas, com leituras sobre negócios, metodologias, comportamento, história e soft skills. Pode ser uma percepção pessoal, mas sinto que a densidade dos livros técnicos me demanda mais tempo e energia. Não é uma leitura passiva; é um estudo ativo, que envolve anotações, reflexão e, por vezes, a implementação de exemplos.

Esse balanceamento é crucial. O conhecimento técnico profundo (vertical) te dá a capacidade de construir. O conhecimento amplo (horizontal) te dá a sabedoria para saber o que construir e para quem.

Ler sobre história te ajuda a entender que os ciclos de hype tecnológico não são novidade. Ler sobre psicologia e comportamento te ajuda a criar interfaces melhores e a se comunicar de forma mais eficaz com sua equipe. Ler sobre negócios e estratégia te permite alinhar suas decisões técnicas com os objetivos da empresa.

Um engenheiro de software excepcional não é apenas um codificador com alta produtividade. É um comunicador, um negociador, um pensador sistêmico e um resolvedor de problemas que entende o contexto humano e de negócios no qual seu código irá operar. A corrida maluca muitas vezes negligencia esse lado da equação, focando apenas na ferramenta e esquecendo o artesão e o propósito da obra.

Essa imersão nos fundamentos durante a segunda graduação foi reveladora. O processo de reaprender e solidificar esses conceitos me deu uma clareza que eu não tinha antes.

Por isso, decidi que, durante essa reta final do curso e além, enquanto reviso os principais e mais básicos assuntos da área de Engenharia de Software, vou registrar essas reflexões e aprendizados em outros artigos aqui no blog. Será uma série dedicada a desmistificar os fundamentos, a conectar a teoria à prática e a mostrar como esses conceitos "antigos" são, na verdade, as ferramentas mais poderosas que temos para navegar no futuro da tecnologia.

A corrida maluca do Dick Vigarista é divertida de assistir, mas raramente leva à vitória. A perseguição constante pelo pombo é exaustiva e, no final, talvez o pombo nem fosse o prêmio mais valioso.

Minha aposta, validada por essa jornada dupla na academia e no mercado, é que o verdadeiro poder não está em ter o mapa mais recente para a corrida, mas em entender os princípios de cartografia. Em vez de apenas perseguir o pombo, talvez seja a hora de focarmos em como construir uma máquina voadora melhor, mais robusta e mais confiável, com base em um conhecimento que o tempo não torna obsoleto. A corrida é infinita, mas os fundamentos são eternos.