O vocabulário que realmente importa no dia a dia
Muita gente entra na programação achando que vai aprender código primeiro e que as palavras vão aparecer sozinhas. Na prática, o contrário costuma acontecer. Você já se deparou com uma documentação em inglês técnico, um erro dizendo "deadlock detected", ou um colega pedindo para fazer um "commit squash" e não fez ideia do que estava sendo falado? Isso é normal. O problema é que esses termos não são ensinados de forma organizada. Você vai acumulando palavras para começar o desenvolvimento de trás pra frente, conforme os problemas aparecem. Aqui vai uma lista mais ou menos completa, mas organizada por relevância prática, não por ordem alfabética. O que vem primeiro são os termos que você vai ouvir todo santo dia. O que vem depois são os que aparecem nos momentos complicados.
palavras para começar o desenvolvimento: o essencial
Commit — registrar uma mudança no repositório. Não é salvar. É criar um ponto de non-retorno no histórico. Um commit mal feito com mensagem genérica tipo "fix" vai te custar horas para entender o que mudou três meses depois. Pull / Push — buscar mudanças do repositório remoto ou enviar as suas. Parece óbvio até você esquecer de dar push e perder um dia inteiro de trabalho porque o arquivo só existia na máquina local.
Branch — uma linha paralela de desenvolvimento. O branch principal é onde o código estável vive. Todo desenvolvedor que já mesclou código quebrado direto no main sabe que branch existe exatamente para evitar isso. Merge — juntar branches. A parte chata é o conflito de merge, que acontece quando duas pessoas modificam a mesma linha de código e o sistema não sabe qual versão manter.
Repository (repo) — o diretório onde tudo isso mora. Contém o código-fonte, o histórico de mudanças, e as configurações do projeto. IDE — Integrated Development Environment. O editor onde você escreve código. VS Code, JetBrains, Vim. A escolha afeta sua produtividade diária, mas nenhum deles vai te salvar de lógica ruim.
API — Application Programming Interface. É a forma como sistemas diferentes conversam entre si. Entender o que é uma API e como consumir uma REST API é tão importante quanto saber escrever um loop. Bug — defeito no código. Sim, é isso mesmo. A palavra veio de um inseto real que causou um problema num computador da IBM nos anos 1940, mas hoje ninguém fala disso.
Debug — o ato de caçar bugs. Incluir pontos de interrupção, inspecionar variáveis, passo a passo. Debugar é onde você passa mais tempo do que gostaria de admitir. Deploy — colocar o código em produção. Esse é o momento em que o código que funcionava no seu computador local pode simplesmente parar de funcionar porque o servidor de produção tem configuração diferente.
Framework — uma estrutura pré-construída que acelera o desenvolvimento. React, Django, Spring. Frameworks economizam tempo, mas criam dependência. Quando o framework muda de versão de formabreaking, você aprende isso na pior parte. Library — conjunto de funções reutilizáveis. Diferente de framework, a library obedece a você. Você decide quando e como chamar. Framework por outro lado te chama de volta via inverted control.
Version Control — controle de versão. Git é o padrão. Sem version control, você está basicamente trabalhando sem rede de segurança.
👉 Clique no botão abaixo para saber mais sobre o assunto!
termos que aparecem quando as coisas ficam difíceis
Refactor — melhorar a estrutura do código sem mudar o comportamento externo. Você faz refactor quando percebe que aquele trecho de 200 linhas pode virar 50 linhas bem organizadas. O risco é transformar um código que funciona em um código que não funciona durante o processo. Scalability — capacidade de crescer sem quebrar. Um sistema que funciona com 10 usuários pode desmoronar com 10 mil. Pensar em escalabilidade desde o início evita dor de cabeça, mas excesso de abstração prematura também é problemático.
Latency — tempo de resposta. O delay entre uma requisição e a resposta. Latência alta mata a experiência do usuário mais rápido do que qualquer bug de lógica. Throughput — quantidade de trabalho processado num intervalo de tempo. Latência e throughput são coisas diferentes e ambos importam. Otimizar um sem olhar o outro é erro comum.
Concurrency vs Parallelism — concorrência é lidar com várias coisas ao mesmo tempo de forma interleaved. Paralelismo é executar várias coisas simultaneamente de fato. A diferença é sutil mas faz diferença na hora de escolher a abordagem certa para um problema de performance. Deadlock — dois processos travam um ao outro esperando recursos que o outro já tem. É um dos bugs mais difíceis de reproduzir porque depende de timing exato. Eu já passei duas semanas caçando um deadlock num sistema distribuído. A solução foi adicionar timeouts em todas as chamadas de lock e logging detalhado de estado, o que reduziu o tempo de debugging de semanas para horas.
Memory leak — memória que é alocada mas nunca liberada. Em linguagens com garbage collector como Java e Go, memory leaks ainda existem, só que de formas mais sutis. Referências mantidas em coleções globais que nunca são limpas são o culpado mais comum. CI/CD — Continuous Integration e Continuous Delivery. Automatizar testes e deploy toda vez que um commit é feito. Configurar um pipeline CI/CD leva tempo inicial, mas economiza horas toda semana evitando que código ruim chegue em produção.
Container — isolamento de software. Docker é o padrão. Containers resolvem o problema clássico "funciona na minha máquina" porque empacotam dependências, configurações e código juntos. Monorepo vs Multirepo — todos os projetos num único repositório ou separados. Monorepo facilita refatorações cross-project. Multirepo facilita permissões granulares. Não existe resposta certa, mas a escolha define como seu time vai trabalhar por anos.
a verdade que ninguém conta sobre aprender vocabulário técnico
Vocabulário técnico não se aprende lendo listas. Se aprende errando. Eu lembro de uma vez em que um collega pediu para fazer um "hot reload" numa aplicação React e eu simplesmente reiniciei o servidor manualmente, achando que era a mesma coisa. Hot reload é diferente de restart. Um preserva o estado da aplicação, o outro não. A diferença importava porque estávamos testando um fluxo de login e todo reinício significava logar de novo. O outro problema é que muitos termos têm significados diferentes dependendo do contexto. "Deploy" para um desenvolvedor backend pode significar subir um serviço numa instância EC2. Para um desenvolvedor frontend, pode significar rodar um build e fazer upload dos arquivos estáticos num CDN. O conceito é o mesmo, a execução é completamente diferente.
Uma coisa que pouca gente explica: a maioria dos termos que você vai usar no dia a dia vêm do inglês porque a indústria de software nasceu e cresceu anglofona. Isso cria uma barreira desnecessária para quem pensa melhor na língua materna. Não adianta forçar. O termo técnico em português muitas vezes é menos preciso ou simplesmente não existe. Aprender os termos em inglês faz parte do trabalho. Outro ponto prático: documentação técnica é escrita de forma densa propositalmente. Cada palavra carrega significado. Ler documentação de forma linear, palavra por palavra, é lento e ineficiente. A habilidade é saber escanear, encontrar a seção relevante, e depois ler com atenção só aquele trecho. Eu gastava horas lendo docs inteiras no início. Hoje leio três parágrafos e já sei se aquilo resolve o problema ou se preciso procurar outra coisa.
A limitação mais honesta que posso citar é que nenhuma lista de palavras substitui a experiência. Você pode decorar todos os termos acima e ainda assim se perder num problema real de integração. O vocabulário te dá o mapa, mas o terreno você percorre errando. O caminho mais eficiente é começar construindo algo simples, encontrar os problemas, e deixar que os termos entrem naturalmente pelo besoin. O que acontece frequentemente é o oposto também. As pessoas tentam aprender termos antes de precisar deles, acumulam vocabulário teórico, e quando finalmente entram num projeto real não conseguem conectar nada. A sequência inversa funciona melhor: construir primeiro, nomear depois. O termo fica gravado porque está associado a um problema concreto que você resolveu, não a uma definição abstrata que dechou.
