Programação vs. TI: quando percebi que eram mundos completamente diferentes
Entrei na faculdade achando que TI e desenvolvimento eram a mesma coisa. Não eram. A descoberta mudou o que eu queria aprender e como eu me via na área.
No meu primeiro emprego em TI, programação não era parte do trabalho.
Eu configurava switches, mantinha servidor de email Linux, resolvia problema de VPN, ia até a casa do cliente resolver internet caindo. O computador era ferramenta de trabalho. Não era o que eu construía.
Quando entrei na faculdade de Ciência da Computação, encontrei pessoas cujo objetivo era o oposto: construir o software. O computador era o que elas queriam modificar, não operar.
Passei os primeiros meses percebendo que esses dois mundos eram muito mais diferentes do que eu imaginava.
A confusão começa com o nome: "área de TI" cobre coisas muito diferentes.
Infraestrutura e operações: manter sistemas funcionando. Rede, servidor, backup, segurança, monitoramento. O trabalho é preventivo quando vai bem, e reativo quando quebra. Sucesso é invisível — ninguém comenta quando a rede está funcionando.
Desenvolvimento de software: construir sistemas novos. Especificação, design, código, teste, deploy. O trabalho é construtivo — algo que não existia passa a existir. Sucesso é visível — o sistema está lá, funcionando, entregando valor.
Eu vinha do primeiro mundo. A faculdade ensinava o segundo.
A diferença de mindset é maior do que parece na superfície.
Infra pensa em estabilidade: como garantir que o que existe continua funcionando? O risco é mudança não planejada. O objetivo é controle.
Desenvolvimento pensa em mudança: como entregar valor novo? O risco é entregar coisa errada ou lenta. O objetivo é progresso.
São tensões reais — e em empresas, são frequentemente tensões entre times diferentes. Dev quer deploy rápido. Ops quer estabilidade. A solução que emergiu na última década — DevOps, SRE — é sobre reconciliar essas perspectivas. Mas a tensão original é genuína.
Eu a entendia de ambos os lados porque tinha vivido num lado e estava aprendendo o outro.
O que me pegou de surpresa foi descobrir que programar é uma habilidade que precisa ser construída do zero — não é consequência natural de entender sistemas.
Eu entendia como sistema operacional gerencia processos. Mas escrever um programa que usa threads corretamente — com locks, sem race condition, sem deadlock — era outro nível. O conhecimento teórico ajudava, mas não substituía prática de programação.
Minha primeira estrutura de dados implementada do zero foi uma fila. Parecia simples. Não era. Aprendi o que é ponteiro nulo, o que acontece quando você remove de uma fila vazia, como testar borda.
Escrever código que funciona é diferente de entender código que funciona.
O que ajudou foi reconhecer que minha experiência de infra era vantagem real em alguns contextos.
Quando a turma aprendia sobre sistemas distribuídos e falava sobre falhas de rede como teoria, eu sabia como essas falhas se manifestavam na prática. Sabia o que "rede não confiável" significa quando você está debugando problema de VPN às 22h com usuário esperando.
Isso me dava contexto que colegas sem experiência operacional levavam tempo para construir. Mas não me dispensava de aprender a programar.
A virada foi aceitar que eu precisava ser iniciante em desenvolvimento da mesma forma que qualquer outro aluno — com a vantagem de entender o ambiente onde o software vai rodar.
Anos depois, trabalhar em SRE fez sentido porque o papel era exatamente na interseção: engenharia de software aplicada a problemas de operações. A tensão que eu vivi como confusão em 2017 virou especialização.
O contexto que parecia conflito era, na prática, diferencial.
Essa semana: qual é o mundo que você vem que dá contexto para o mundo onde você quer chegar?