O gap entre o currículo de Ciência da Computação e o que eu já sabia fazer
Entrei na faculdade sabendo operar servidores Linux, configurar VPN, manter rede corporativa. O currículo de CC ensinava outra coisa. Os dois mundos levaram tempo para se encontrar.
Na primeira semana de Cálculo I eu entendia tudo.
Não porque eu era bom em cálculo — mas porque era o primeiro contato com uma matéria que não tinha nenhum paralelo com o que eu já conhecia. Nenhum atalho para pular. Nenhum conhecimento prévio me distraindo. Eu estava completamente presente.
Nas matérias de computação, era diferente. E diferente não era necessariamente melhor.
O currículo de Ciência da Computação não começa onde você espera que comece.
Antes de programação, tem Álgebra Linear. Antes de sistemas operacionais, tem Cálculo. Antes de banco de dados, tem Teoria dos Grafos. A estrutura é matemática primeiro, computação depois — porque a premissa do curso é que fundamentos teóricos sustentam tudo que vem depois.
O problema é que eu já tinha o "tudo que vem depois" sem os fundamentos.
Configurava servidor Linux sem entender formalmente o que é um processo. Usava DNS sem saber que era uma árvore distribuída. Gerenciava roteamento sem ter estudado grafos. As coisas funcionavam — e eu entendia como operar, mas não entendia por que funcionavam da forma que funcionavam.
Isso criou um efeito estranho: eu me saía bem em matérias que todo mundo achava difícil, e tinha dificuldade em matérias que os colegas achavam tranquilas.
Sistemas Operacionais: fácil para mim, porque eu conhecia a prática. Schedulers, gerência de memória, processos — eu tinha operado isso. A teoria conectava com algo real que eu já tinha visto.
Programação Orientada a Objetos: mais difícil do que eu esperava. Eu não tinha background de desenvolvimento. Sabia Python básico para automação, mas não tinha construído sistemas. Herança, polimorfismo, design patterns — eram conceitos sem contexto prático para eu ancorar.
O currículo assumia que os alunos chegavam sem prática. Eu chegava com prática errada — ou pelo menos incompleta.
O gap mais concreto: eu sabia o o que mas não o por que.
Por que TCP precisa de handshake de três vias? Eu sabia que precisava — mas não sabia articular o que exatamente o handshake estava garantindo, o que acontecia se fosse omitido, quais propriedades do protocolo dependiam disso.
Por que RAID 5 distribui paridade entre discos em vez de dedicar um disco para paridade? Eu tinha configurado RAID. Nunca precisei justificar o design.
Faculdade me forçou a responder essas perguntas. E descobri que algumas das minhas "respostas" eram incompletas — eu tinha o hábito de operar sem ter entendido o princípio.
A matéria que mais me pegou de surpresa foi Algoritmos e Estruturas de Dados.
Eu nunca tinha tido formação em lógica de programação estruturada. Sabia fazer scripts que resolviam problemas específicos. Mas pensar em complexidade — O(n), O(n log n), tradeoffs entre tempo e espaço — era vocabulário completamente novo.
No começo achei abstrato demais. Depois entendi: quando você escreve um script que processa arquivo com um milhão de linhas e o script leva 40 minutos, o problema é de algoritmo. Eu tinha resolvido esse problema no passado por instinto — usando ferramentas mais rápidas, quebrando em lotes, paralelizando. Nunca tinha nomeado o que estava fazendo.
Algoritmos me deu o vocabulário para o instinto que eu já tinha.
O ponto de virada foi quando parei de tratar o currículo como obstáculo e comecei a tratar como complemento.
O que eu sabia: operar sistemas em produção, diagnosticar falhas, trabalhar em ambiente com restrições reais. O que o currículo dava: formalização, vocabulário, fundamentos que explicavam por que as coisas funcionavam como funcionavam.
Os dois juntos eram mais úteis do que qualquer um separado.
Essa semana: qual é o conhecimento que você tem na prática mas nunca formalizou? O que mudaria se você entendesse o por que além do o que?