O contexto

Passei quase uma década mexendo com código de um jeito muito empírico, quase acidental. Editava templates de Blogger e subia scripts para automatizar tarefas no Tibia sem nunca parar para pensar na estrutura por trás daquilo. Se funcionava, eu seguia em frente; se quebrava, eu tentava outra combinação de comandos até dar certo.

Essa abordagem "tentativa e erro" funciona até certo ponto, mas ela tem um teto muito baixo. Quando as demandas começaram a escalar e os problemas ficaram mais complexos, percebi que faltava um alicerce. Eu sabia escrever, mas não sabia o que estava tentando dizer para a máquina de forma estruturada.

A barreira da sintaxe vs. lógica

O erro mais comum de quem está começando — e eu cometi esse erro por muito tempo — é achar que o obstáculo é a linguagem. A gente gasta horas tentando decorar se o for leva ponto e vírgula ou se a função precisa de parênteses, quando o verdadeiro desafio é a lógica que precede o primeiro caractere digitado no VS Code.

Na faculdade, durante as aulas de algoritmos, entendi que o código é apenas a etapa final. O pensamento computacional é o que acontece antes. É a capacidade de olhar para uma tarefa complexa e enxergar padrões, ignorar o que não importa e definir uma sequência finita de passos para chegar ao resultado.

Os pilares no mundo real

Para mim, a ficha clicou quando parei de ver o código como um texto e comecei a ver como um processo de quatro etapas. Primeiro vem a decomposição: se eu preciso criar um sistema de inventário, não começo pelo banco de dados. Começo definindo o que é um item. Depois procuro padrões: como outros itens se comportam?

// A lógica bruta antes da implementação complexa
function adicionarItem(inventario, novoItem) {
  if (inventario.isFull()) {
    console.log("Sem espaço nas bolsas");
    return;
  }
  
  // Abstração: não importa o que o item faz, apenas que ele ocupa um slot
  inventario.push(novoItem);
}

A abstração é o que mais me custou a entender. É o filtro mental que permite focar no que é essencial para o problema atual. Se estou calculando a rota de um script, não importa a cor do cenário, importa apenas se a coordenada X é atravessável ou não. Reduzir a realidade a dados é o que separa o dev do hobbista.

O que isso muda na prática

Hoje, minha primeira ferramenta de desenvolvimento não é o terminal, é a decomposição de problemas. Antes de abrir o editor, eu desenho o fluxo. Se eu não consigo explicar a lógica para mim mesmo em português, escrever em JavaScript só vai gerar um código confuso que eu mesmo não vou conseguir dar manutenção daqui a duas semanas.

Isso tirou um peso enorme das costas. Não sinto mais a necessidade de saber todas as bibliotecas do mundo. Se eu entendo como resolver o problema logicamente, a sintaxe vira apenas uma pesquisa rápida na documentação. O esforço intelectual mudou de lugar: saiu do "como escreve" para o "o que deve ser feito".

O que fica

Pensamento computacional não é um dom, é um treino de paciência. É aceitar que o computador é extremamente burro e que qualquer erro na execução é, na verdade, uma falha na minha instrução. Aprender a pensar assim é cansativo no começo, mas é o que dá a liberdade de criar qualquer coisa depois.

Ainda tropeço em abstrações complexas e às vezes me perco em problemas que eu mesmo compliquei. Mas a diferença é que agora eu tenho um mapa. Se o código não funciona, eu não saio trocando vírgulas por pontos; eu volto para o papel e vejo onde a minha lógica quebrou.

Referências

Introduction to Computational Thinking (BBC) — A base clássica que me ajudou a entender os quatro pilares.
Aulas de Algoritmos na São Judas — Onde a teoria finalmente encontrou a minha prática de anos.