O Que Faz Programador

O que realmente se faz o dia inteiro

Programador passa mais tempo lendo código do que escrevendo. Isso já era pra ser óbvio, mas não é. A maior parte do trabalho é entender o que alguém — às vezes você mesmo, seis meses atrás — fez num sistema que já tá rodando há anos e que ninguém documentou direito. O processo funciona assim na prática: você recebe uma tarefa, tenta entender onde ela se encaixa no codebase, encontra os pontos de entrada, faz mudanças pequenas e testa. Repete isso dezenas de vezes por dia. A coisa mais comum é abrir um arquivo, procurar uma função, rastrear chamadas, abrir outro arquivo, repetir.

O que faz programador no dia a dia

Reuniões, claro. Stand-ups, alinhamentos, discussões sobre prazos. Depende muito da empresa. Em lugares bons, menos reunião e mais código. Em lugares ruins, quase nada de código. O ideal é uma proporção que varie conforme a fase do projeto, mas raramente é equilibrado. Depurar também consome um tempo absurdo. Um bug pode levar três horas ou três dias. Às vezes é um ponto de interrogação mal colocado. Às vezes é uma variável que foi sobrescrita por uma biblioteca que ninguém atualiza há dois anos. Já perdi uma tarde inteira num problema onde o servidor devolvia status 200 mas o JSON vinha cortado no meio. Descobri que era um limite de memória no Nginx configurado como 4k. Setei pra 64k e o problema foi embora. Ninguém sabia desse limite existia. Código novo é a minoria. Majority é manutenção, ajuste, migração, refatoração pontual. Se você gosta de criar coisas do zero todo dia, vai se frustrar rápido na maioria dos trabalhos reais.

A gente also passa tempo entendendo requisitos. Às vezes o que o negócio pede não é o que o negócio precisa. A primeira versão do que eu pensei que era uma solicitação simples já tinha duas ressalvas que eu não tinha percebido porque não tinha perguntado. Perguntar antes de implementar economizahoras de retrabalho. Recomendo fazer isso mesmo quando a tarefa parece óbvia. Geralmente não é. Review de código também faz parte. Ler o código dos outros, dar feedback, receber feedback. Isso melhora a qualidade geral e ainda serve como aprendizado indireto, porque você vê como outra pessoa resolve problemas parecidos.

Ferramentas que todo mundo usa (e as que não usam)

Git é obrigatório. Sem versionamento de código, virou pedra fundamental. Se a equipe não usa branch strategy decente, você vai sofrer. Git flow, trunk-based, feature flags. Escolha uma e siga. O pior cenário é cada um comendo folhinha sozinho sem merge request. IDE ou editor. VS Code domina o mercado, mas tem quem prefira IntelliJ, Vim, Emacs. Não importa tanto qual, mas o importante é saber usar os atalhos. Quem não usa atalhos perde minutos por hora que somam horas por semana. Terminal é seu segundo lar. Aprende a usar grep, awk, sed, curl, jq. Essas ferramentas economizam mais tempo do que qualquer IDE nova. Já vi colega gastar vinte minutos caçando informação num debugador quando um grep bem colocado resolvia em trinta segundos.

Lembre-se de verificar logs. Log de aplicação, log de servidor, log de erro. A maioria dos problemas tem rastros ali. O problema é que muita gente não lê log com frequência e perde esse recurso barato.

A parte que ninguém conta

Aprender a lidar com ambiguidade. Nem sempre tem resposta certa. Às vezes a escolha entre duas abordagens é pura preferência técnica com Trade-offs pequenos. Às vezes é escolher entre entregar agora com gambiarra ou entregar depois com algo limpo. Ambas as opções têm custo. O trabalho é medir esse custo. Documentação é outra. Pouca gente gosta de escrever, mas documentar decisões técnicas (ADR — Architecture Decision Record) evita que você ou outra pessoa perca tempo refazendo o mesmo raciocínio seis meses depois. Um arquivo README mal escrito é melhor que nenhum. Um arquivo de decisões com três parágrafos vale mais que meia manhã de reunião explicando o mesmo problema. Automatizar repetição é talvez a habilidade mais subestimada. Script simples de deploy, script de build, script de teste. Qualquer coisa que você faz mais de duas vezes e leva mais de cinco minutos vale a pena automatizar. Eu tenho um script que sobe o ambiente de desenvolvimento local em doze minutos, antes levava cerca de quarenta e cinco porque tinha que rodar passos manuais esquecidos.

Quando isso não funciona

Esse caminho funciona bem em times com código existente, processes definidos e espaço pra aprender. Não funciona tão bem em startups extremamente caóticas onde tudo muda todo dia, ou em empresas onde a pressão por velocidade elimina qualquer tempo de reflexão. Nesses casos, a qualidade do código cai rápido e o débito técnico acumula. Também não é ideal para quem gosta de ritmo constante de criação sem interrupções. Programação exige concentração profunda, e cada interrupção custa caro. Uma pesquisa clássica mostra que leva em média quinze minutos pra recuperar o foco após uma interrupção. Em open office com chat constante, isso destrói a produtividade. Se o objetivo é apenas mudar de área sem vontade de estudar continuamente, vai sofrer. Tecnologia muda todo dia. O que funcionava ano passado pode não funcionar hoje. Manter-se atualizado não é opcionalem setores.