Confissões de um Graduado em CS com Base Fraca
Na época da faculdade, eu me achava ‘o cara’. Sem saber o quão cruciais eram os fundamentos de Ciência da Computação (CS), eu só me preocupava em garantir boas notas no boletim.
Frequentava as aulas, participava de maratonas de programação e até ganhei prêmios no TCC (Trabalho de Conclusão de Curso). Quando meus colegas sofriam com erros de código, eu dava palpites e sentia uma certa superioridade. Mas, confessando agora: o que eu produzia naquela época era brincadeira de criança.
Achava difícil conectar um banco de dados (DB) real, então salvava dados em arquivos .txt separados por vírgula. Em vez de usar um Raspberry Pi que exigiria controle de sistema operacional, eu resolvia tudo com Arduino, que funcionava com meia dúzia de linhas de código. Os professores elogiavam o resultado que ‘aparentemente funcionava’, e eu me iludia achando que aquilo era minha habilidade real.
A Tragédia da Entrevista Baseada em ‘Decoreba’
No entanto, assim que fui jogado no mercado de trabalho, essa confiança infundada se estilhaçou. Foi uma sequência de rejeições em currículos. O título de ‘premiado em competições’ não conseguia esconder minha base fraca em CS.
Quanto mais ansioso eu ficava, mais obcecado eu me tornava em acumular conhecimento superficial. O entendimento real ficava em segundo plano; eu decorava respostas modelo como uma máquina apenas para passar nas entrevistas. Minha bíblia era o post “Top 100 Perguntas de Entrevista” copiado de blogs técnicos.
Quando o entrevistador perguntava: “Qual a diferença entre TCP e UDP?”, eu respondia como uma vending machine: “TCP é orientado a conexão e garante confiabilidade, mas é lento. UDP não é orientado a conexão, é rápido, mas tem baixa confiabilidade.”
Na verdade, eu não fazia ideia do que era um ‘pacote’ ou como o ‘3-way handshaking’ acontecia na prática. Ironicamente, graças a essa capacidade de memorização mecânica (a famosa ‘decoreba’), enganei os entrevistadores e consegui um emprego. Achei que fosse sorte. Mal sabia eu que era o início de uma tragédia onde eu pagaria, de uma só vez, o preço pelos 4 anos negligenciados.
Sobrevivência Full Stack em uma Startup Enxuta
O lugar onde entrei era uma equipe pequena. Lá, não existia essa gentileza de separar ‘Frontend’ de ‘Backend’.
Desde o primeiro dia, tive que enfrentar um tsunami de tecnologias. Achei que bastava ser bom apenas em Java ou JavaScript. Mas a realidade me atacou de todos os lados: a tela preta do terminal SSH do Linux, contêineres Docker de origem desconhecida, pipelines de CI/CD no GitLab, Spring Boot, Vue.js e até Redis… Tecnologias que eu adiei na faculdade dizendo “depois eu vejo” ou ignorei pensando “não preciso saber disso”, agora voltavam para me assombrar.
Aquele conhecimento que recitei na entrevista não tinha utilidade prática. Ou melhor, eu não sabia como ‘aplicar’. Para entender por que meu contêiner Docker continuava morrendo (OOM) ou por que o Redis estava devorando a memória, eu precisava desesperadamente daquele conhecimento base de CS que eu tinha apenas decorado.
Um Castelo Construído na Areia
No fim das contas, me tornei um ‘Desenvolvedor Ctrl+C, Ctrl+V’, colando códigos desesperadamente. As funcionalidades rodavam de algum jeito, mas eu não sabia o porquê.
- CORS Error: Por que meu navegador rejeita a resposta do servidor? (Ignorância sobre Headers HTTP)
- OOM (Out Of Memory): Por que o servidor que estava rodando bem de repente morre? (Ignorância sobre Memory Leak e Garbage Collection)
- Connection Refused: Funciona no local, mas por que falha no deploy? (Ignorância sobre Port Forwarding e Firewall)
Sem conhecer os princípios por trás da conveniência dos frameworks, eu não tinha capacidade de resolver problemas quando eles surgiam. Eu estava construindo um castelo precário com frameworks vistosos sobre um terreno de CS instável.
Re: Booting, De Volta ao Ponto de Partida
Por isso, decidi voltar ao início. Senti que resolver a questão fundamental de “como diabos o computador entende e executa meu código” era mais urgente do que criar mais um portfólio vistoso agora.
Este blog é o registro de uma revisão intensa (“Re: Booting”) de um graduado que possui apenas o diploma, reconstruindo a base de CS do zero. Não vou apenas listar comandos Linux ou tutoriais de instalação do Docker. Em vez disso, pretendo lançar perguntas e buscar as respostas:
- Language & OS: O que acontece desde que o código Java é compilado até chegar à CPU?
- Network: Quando dou Enter na barra de endereços, por qual caminho viajam os pacotes?
- Virtualization: Qual a diferença entre meu notebook e o computador no data center, e por que precisamos de virtualização?
- DevOps: Como faço o deploy do meu código de forma segura e automatizada?
Além do Localhost
Meu objetivo final é construir e controlar pessoalmente ambientes de Linux, Docker, CI/CD e Nuvem. Peço que acompanhem meu processo de me tornar um engenheiro capaz de sobreviver na selva dos servidores, saindo da estufa segura chamada localhost.
Para aqueles que, como o meu ‘eu’ do passado, dizem “aprendi na faculdade, mas não lembro”, espero que este registro sirva como um pequeno marco que faça vocês baterem na testa e dizerem: “Ah, então era isso que o professor queria dizer naquela época!”