0x0C│
2026.05.01│
9 minutos de leitura
│
programação · educação · engenharia de software · opinião · carreira · aprendizagem · boas práticas · orientação
Um bootcamp pode ensinar a sintaxe de uma linguagem em seis semanas. A parte que leva uma década é todo o resto: para onde vão as costuras, para onde os dados fluem, quais decisões você terá durante toda a vida da base de código. Este é o argumento de um desenvolvedor sênior sobre o que os alunos deveriam realmente procurar, depois de trinta anos observando a diferença.
Alguns anos atrás, eu estava examinando uma solicitação de pull de um júnior em um idioma que nunca havia escrito profissionalmente. Eu não poderia ter lhe contado a biblioteca padrão de cabeça. Tive que procurar a sintaxe de um lambda. E eu sabia, sem executar o código, que a função estava errada.
Foram cinco linhas que deveriam ser uma. A forma estava errada. Os dados saíram, voltaram, foram remodelados, voltaram novamente e finalmente pousaram onde haviam começado, levemente machucados. Os nomes das variáveis estavam bem. A sintaxe estava boa. A função fez o que pretendia fazer. Ainda estava errado, porque o que estava fazendo não era o que deveria ter sido feito naquele ponto do programa.
Pude perceber isso porque já programo há muito tempo. O júnior não conseguia ver porque havia aprendido um idioma. Essas não são a mesma habilidade, e a lacuna entre elas é a parte deste trabalho que quase ninguém ensina no nível inicial.
A linguagem não é o gargalo
Quase todos os cursos introdutórios, vídeos e bootcamps do mercado ensinam a sintaxe de uma linguagem específica e chamam isso de programação. Não é. A programação é a parte que é a mesma em todas as linguagens: como um sistema funciona, onde estão as costuras, quais dados fluem para onde, quais decisões são baratas para mudar no próximo mês e quais decisões você ficará preso durante toda a vida da base de código.
Escrevi sobre a versão mais profunda deste argumento em outro lugar. O capítulo do livro sobre o declínio da compreensão fundamental na educação de programação moderna expõe o que realmente está sendo perdido: empatia mecânica, um modelo mental honesto da máquina subjacente, o contexto histórico que explica por que os sistemas são moldados da maneira que são. Esse ensaio é o argumento estrutural. Este post é o guia de campo que vem depois dele. Se você leu o capítulo e perguntou: “tudo bem, então o que um aluno deve fazer a respeito”, esta é a resposta.
O que eu acho que aconteceu em 1997
Por volta do segundo ano da era cmcweb, eu estava trabalhando em um aplicativo de linha de negócios Visual Basic 6 para um cliente cujo nome esqueci com honra. Eu tinha um júnior comigo. Ele já esteve em três projetos comigo, conhecia bem a sintaxe do VB e sabia escrever um For Each loop em seu sono. O código que ele produziu estava correto. Também era plano. Cada formulário era um procedimento gigante que corria de cima para baixo e era despachado para outros procedimentos gigantescos. A linguagem é orientada por eventos; ele o estava escrevendo como um programa em lote de mainframe dos anos 1970, com etapas extras.
Numa terça-feira de março, algo clicou. Eu não sei o que foi. Ele escreveu um pouco de cola entre dois formulários que usavam os eventos da maneira que o tempo de execução pretendia que fossem usados. A próxima coisa que ele escreveu foi melhor. A coisa depois disso foi ainda melhor. No final do mês, seu código tinha uma textura diferente. Parecia VB em vez de Pascal com janela anexada.
Nada na linguagem mudou. Ele estava escrevendo VB6 há dois anos antes daquela terça-feira. O que mudou foi que ele começou a entender em que tipo de sistema ele estava. Ele parou de traduzir suas ideias em VB e começou a pensar diretamente nos eventos. A mesma sintaxe, a mesma biblioteca padrão, o mesmo IDE. Um desenvolvedor diferente.
Essa é a parte que não cabe em um currículo de seis semanas. Você não pode colocá-lo em um slide. Você não pode dispensá-lo em um curta do YouTube. Acontece ou não, em seu próprio tempo, geralmente depois que o aluno envia código suficiente para ficar constrangido com parte dele.
O que “aprender uma língua” realmente abrange
Sintaxe. A biblioteca padrão. Estilo idiomático. O sistema de tipos. A ferramenta de construção. Como o gerenciador de pacotes funciona em um dia bom e o que fazer quando isso não acontece. Coisas úteis, todas elas. Necessário, até. Mas um desenvolvedor que possui apenas isso é um tradutor. Eles podem pegar uma instrução em linguagem humana e convertê-la em texto legível por máquina. Eles podem convertê-lo em diferentes textos legíveis por máquina em três ou quatro idiomas de destino, mediante referência. A tradução está correta. Se a instrução foi a instrução correta em primeiro lugar, isso é problema de outra pessoa.
Um programador é a pessoa que decide qual deveria ser a instrução.
O que “aprender a programar” cobre
A maior parte do que um desenvolvedor sênior realmente faz em um determinado dia não está em nenhum currículo para iniciantes. É a coisa nada sexy. Lendo código, principalmente. Rastreando dados através de cinco camadas de escolhas de design de outra pessoa. Formar uma hipótese sobre por que o bug está acontecendo, depois testar a hipótese e, em seguida, estreitar. Reconhecer que a função à sua frente é muito grande e perguntar que parte dela tem sua própria razão de existir. Reconhecer que o esquema à sua frente codifica uma decisão que alguém tomou em 2019 e que a decisão agora suporta coisas que eles não previram. Saber qual das cinco limpezas tentadoras do arquivo vai incomodar você na produção e qual é segura.
Nada disso está na linguagem. Está na cabeça de quem digita. A linguagem é o teclado.
A lista honesta do que bons desenvolvedores realmente têm, que falta na versão bootcamp deles:
- Um modelo mental de como um sistema se decompõe. Por que essa coisa quer ser uma classe e aquela coisa quer ser uma função e aquela outra coisa quer ser um processo totalmente separado
- Uma noção de onde os dados residem, para onde se movem e onde são transformados. A maioria dos bugs que se parecem com bugs lógicos são bugs disfarçados de fluxo de dados
- Uma noção de quais decisões são baratas para serem alteradas posteriormente e quais não são. A habilidade é reconhecer o segundo tipo antecipadamente, antes de você ter construído três meses de código em cima de um.
- O hábito de ler o código antes de escrevê-lo. Um desenvolvedor sênior lê dez vezes mais código do que escreve, a maior parte escrita por outras pessoas, grande parte escrita por versões anteriores de si mesmo que não estão mais acessíveis para comentários
- A depuração é uma disciplina e não uma indignidade. A depuração de instruções impressas é um método, não uma confissão de inadequação. Depuradores passo a passo, criadores de perfil, capturas de rede, mergulho em registros, tudo isso
- Uma tolerância funcional para a ambiguidade. A primeira versão de qualquer trecho de código não trivial é construída antes que alguém, incluindo o autor, entenda completamente o que deve fazer. Isso é normal. Esse é o trabalho
O multiplicador de IA
Eu uso o Código Claude todos os dias. Escrevi um post sobre isso há dois dias. A ferramenta é excelente. É também, para um aluno sem julgamento, um caminho mais rápido para uma base de código pior do que a que teria produzido sem ajuda.
Esta não é uma reclamação sobre IA. É o mesmo que venho defendendo há trinta anos, com um novo amplificador à sua frente. O modelo escreve código plausível. Se o prompter não conseguir distinguir o código plausível do código correto, o código plausível será enviado. Se o prompter puder dizer, o modelo é um multiplicador de força para um idoso que já sabia onde as costuras deveriam ir e agora tem uma maneira rápida de digitá-las.
O gargalo nunca foi “quão rápido você consegue escrever o código”. Sempre foi “você sabe qual código deve ser escrito, em que ordem, com quais contratos entre as partes”. O modelo não muda isso. Altera o custo de produção das linhas e deixa o custo de decidir as linhas exatamente onde sempre esteve.
Um júnior que aprende programação como “descreva o que você quer para um modelo e aceite o que volta” está aprendendo a ser um tradutor mais distante da máquina. Eles não estão se aproximando da programação. Eles estão cada vez mais longe disso, com resultados intermediários mais bonitos.
O que um aluno deve fazer em vez disso
Se você está no início e leu até aqui, aqui está a versão resumida do que eu diria ao meu eu de 25 anos.
Escolha um idioma e vá fundo. O tipo de profundidade em que você enviou algo não trivial, manteve-o por um ano e corrigiu bugs causados pelo passado – você estava errado sobre como o tempo de execução funcionava. O tutorial profundo não conta. Em seguida, escolha um segundo idioma que seja estruturalmente diferente do primeiro. C# e Python são um par útil. C e JavaScript são mais nítidos. O contraste é o ponto. O que você está procurando é a parte que é igual em ambos, porque essa é a parte que realmente está programando.
Leia o código. Código real, em uma base de código real, incluindo as partes feias. O código aberto está cheio disso. Leia os problemas e as discussões sobre solicitações pull, não apenas o código mesclado. O argumento interessante raramente está na diferença.
Construa algo de ponta a ponta. Uma coisa real, com um usuário real, mesmo que o usuário seja você. Qualquer coisa diferente de outro tutorial de lista de tarefas. Envie-o. Em seguida, mantenha-o por pelo menos um ano. Observe o que dói. A lista do que dói é o currículo que ninguém mais pode escrever para você.
Encontre um desenvolvedor sênior que permitirá que você observe o trabalho deles. A programação em pares com alguém quinze anos à sua frente é o aprendizado de maior largura de banda disponível nesta área, e quase ninguém o coloca no YouTube porque ninguém está pagando para isso. Perguntar. A maioria dos idosos que conheço dirá que sim, se você não se incomodar com isso.
Leia os livros que não são específicos do idioma. O Programador Pragmático, Código Completo, Uma Filosofia de Design de Software, Kernighan e Pike’s The Practice of Programming. Eles envelhecem da mesma forma que os bons livros envelhecem. O livro da moda sobre a estrutura que você está usando agora não o fará.
Ao assistir a tutoriais de idiomas, assista àqueles destinados a desenvolvedores experientes que estão aprendendo um novo idioma. A relação sinal-sintaxe é muito maior, porque o redator não para a cada dois minutos para explicar o que é uma variável.
Desconfie de qualquer curso que prometa que você poderá se tornar um desenvolvedor em doze semanas. Você pode ser um funcionário júnior cuja primeira contribuição útil será daqui a seis meses, claro. Essa é uma alegação diferente e não é a alegação que está sendo comercializada.
A pergunta a fazer
A área não precisa de mais pessoas que possam escrever um for loop em sete idiomas. Precisa de mais pessoas que possam olhar para um editor em branco e decidir o que deve ser construído, em que ordem, com quais costuras. Essa parte leva uma década. Quase ninguém o ensina no nível inicial, porque quase ninguém consegue ensiná-lo em um currículo fixo para uma sala cheia de estranhos.
Se você é um aluno, a questão não é “qual idioma devo aprender primeiro”. É “qual professor me mostrará como um sistema funciona”. A primeira pergunta tem respostas baratas em todos os lugares. O segundo é raro e vale o tempo que leva para ser encontrado.
Para uma versão mais profunda da razão pela qual esta lacuna existe, em primeiro lugar, e o que a compreensão fundamental realmente significa ao nível da memória, da abstração e do raciocínio computacional, o capítulo sobre o declínio da compreensão fundamental na educação de programação moderna é onde apresento esse argumento na íntegra.
Este post foi o guia de campo. Esse é o livro didático.
-EG
Fonte: theverge

