Lembro da minha primeira semana como dev. Tinha acabado de ganhar meu primeiro freela, estava terminando a faculdade, me sentindo pronta. Pensei: "agora sim, vou passar o dia inteiro escrevendo código bonito". Duas semanas depois, percebi que tinha passado mais tempo no Slack, no Figma e no Google Docs do que no VS Code. E isso me deixou meio perdida — será que eu estava fazendo algo errado?
Por que ninguém te prepara pra isso
Os bootcamps e a faculdade ensinam algoritmos, estruturas de dados, frameworks. Você sai achando que o trabalho é: pegar uma task, abrir o editor, codar, commitar, próxima task. Mas a realidade é outra. Você gasta tempo entendendo por que aquele botão precisa existir, discutindo se a API deve retornar um array ou um objeto, explicando pra PM por que aquela feature vai levar 3 sprints e não 2 dias. O código é quase uma consequência — a parte final de um processo que começa muito antes de você abrir o arquivo.
E não é que você esteja fazendo errado. É que o trabalho mudou, e ninguém atualiza a descrição da vaga.
A anatomia real de uma task
Pega uma feature qualquer. Vou usar um exemplo que vivi: "adicionar filtro de data no dashboard de vendas". Parece simples, certo? Aqui está o que realmente aconteceu:
// O código final foi isso aqui:
const [dateRange, setDateRange] = useState({ start: null, end: null });
const filteredSales = sales.filter(sale => {
if (!dateRange.start || !dateRange.end) return true;
return sale.date >= dateRange.start && sale.date <= dateRange.end;
});
Quinze linhas. Levou 8 horas. Por quê?
- 1h alinhando com o time de produto: o filtro reseta quando muda de página? Salva no localStorage? Funciona com timezone do cliente ou do servidor?
- 2h investigando por que o componente de datepicker da lib que a gente usa não funciona no Safari 15 (spoiler:
Intl.DateTimeFormatcom timezone UTC quebra em alguns casos) - 1h escrevendo testes (sim, até pra isso tem teste)
- 30min documentando no Notion o comportamento decidido
- 1h no code review explicando por que não usei a lib X (porque ela adiciona 40kb no bundle)
- O resto: escrevendo o código
O código foi 20% do tempo. O resto foi comunicação, investigação, decisão, documentação.
As habilidades invisíveis
Aqui está o que eu uso no dia a dia e que nenhum curso ensinou direito:
1. Ler contexto em threads do Slack
Você recebe uma task: "O botão de checkout não funciona". Aí você vai no canal, sobe 150 mensagens, descobre que na verdade funciona, mas só em produção, só pra usuários logados, só se o carrinho tem menos de 10 itens. Essa skill de garimpar contexto é essencial.
2. Traduzir tech pra não-tech (e vice-versa)
// PM: "Precisa ser em tempo real"
// Dev brain: WebSocket? SSE? Long polling? Qual a latência aceitável?
// O que eu respondo:
"Tempo real tipo chat (mensagem chega em 1s) ou tipo painel
(atualiza a cada 30s)? Isso muda bastante a arquitetura."
Saber fazer essa ponte economiza retrabalho.
3. Debugar o bug invisível
O código funciona na sua máquina. Quebra em staging. Você passa 2 horas descobrindo que é a versão do Node no Docker que trata BigInt diferente. O código que você escreve pra resolver:
// Antes
const total = sales.reduce((sum, sale) => sum + sale.amount, 0);
// Depois (pra garantir que funciona em Node 16 e 18)
const total = sales.reduce((sum, sale) =>
Number(sum) + Number(sale.amount), 0
);
Três caracteres de diferença. Duas horas de investigação.
4. Dizer não (com contexto)
"Dá pra adicionar essa feature até sexta?"
Não é só falar "não". É explicar: "Dá, mas vamos ter que adiar os testes automatizados, e isso significa que a cada nova feature vamos gastar mais tempo testando manual. Prefere assim ou deixa pra sprint que vem com testes inclusos?"
Os trade-offs que ninguém te conta
Agora a parte que dói: algumas dessas habilidades competem com escrever código.
- Quanto mais você participa de calls de alinhamento, menos tempo tem pra codar (mas menos retrabalho)
- Quanto mais você documenta decisões, menos features você entrega na sprint (mas menos gente te interrompe com dúvida)
- Quanto mais você revisa PR dos outros, menos avança no seu (mas o código da base melhora)
Não tem resposta certa. Depende do momento do projeto, do time, da senioridade. Mas é importante saber que esse trade-off existe. Quando você vê um dev senior que "não escreve tanto código", muitas vezes é porque ele está resolvendo os problemas antes de virarem código.
E quando você só quer codar?
Olha, eu entendo. Tem dias que eu só queria pegar uma task bem definida, colocar fone, e passar 4 horas refatorando aquele componente gigante. E tá tudo bem querer isso.
Algumas estratégias que funcionam pra mim:
- Blocos de deep work: combina com o time 2h de "não me chama" por dia
- Pegar tasks técnicas: refatoração, performance, migração de versão — geralmente exigem menos alinhamento
- Projetos paralelos: onde você controla 100% do escopo e só programa
Mas se você está num time, numa empresa, trabalhando em produto real, vai ter que aceitar: escrever código é uma parte do trabalho, não o trabalho inteiro.
TL;DR
- Desenvolvimento de software é 20% código, 80% contexto, comunicação e decisão
- As habilidades mais usadas no dia a dia: ler contexto, traduzir tech↔︎não-tech, debugar o invisível, negociar escopo
- Há trade-offs reais entre codar e outras atividades — e tá tudo bem
- Devs seniors "escrevem menos código" porque resolvem problemas antes deles virarem código
- Se você quer focar em código puro: negocie blocos de deep work ou escolha projetos/empresas que permitam isso
Top comments (0)