Albert Einstein, at the blackboard in the Hale Library, Pasadena. Image courtesy of the Observatories of the Carnegie Institution for Science Collection at the Huntington Library, San Marino, California.

Existe uma frase que circula há décadas entre designers, engenheiros e empreendedores:

“Apaixone-se pelo problema, não pela solução.”

Ela costuma soar como frase de efeito. Quase um mantra de palestra. Mas, vista com mais cuidado, ela aponta para algo muito mais profundo — e cientificamente sólido.

De outra forma, essa frase diz o seguinte:

Entender o problema é metade da solução.

Isso é ciência.

O que a ciência da computação tem a dizer sobre isso

Na ciência da computação, especialmente no estudo de algoritmos, existe um conceito central chamado corretude.

Provar que um algoritmo é correto não significa apenas mostrar que ele “funciona na prática”. Significa demonstrar, de forma rigorosa, que ele resolve exatamente o problema proposto — para todos os casos válidos.

E aqui está o ponto crucial:

Não existe prova de corretude para um problema mal definido.

Antes de qualquer linha de código, qualquer estrutura de dados ou qualquer otimização, é preciso responder duas perguntas fundamentais:

  • Quais entradas são permitidas?
  • Quais propriedades a saída precisa satisfazer?

Essas duas coisas formam o que chamamos de especificação do problema.

Sem isso, não existe algoritmo correto. Apenas comportamentos acidentais.

Como fica claro na seguinte passagem:

Problems specifications have two parts: (1) the set of allowed input instances, and (2) the required properties of the algorithm's output. It is impossible to prove the correctness of an algorithm for a fuzzily-stated problem. Put another way, ask the wrong question and you will get the wrong answer (Steven Skiena, 2020).

Não importa o quão elegante seja o código. Não importa o quão avançado seja o modelo. Se o problema estiver errado, a solução também estará.

O erro clássico: correr para a solução

Na prática profissional, o que mais vemos é o oposto disso.

  • Empresas apaixonadas por ferramentas
  • Times apaixonados por arquiteturas
  • Profissionais apaixonados por frameworks
  • Startups apaixonadas por features

Tudo isso antes de compreender profundamente o problema.

O resultado?

Soluções tecnicamente sofisticadas resolvendo a pergunta errada.

Na computação, isso gera algoritmos incorretos. No mundo real, gera produtos inúteis, métricas vazias e sistemas caros de manter.

Entender o problema é um trabalho ativo

Compreender um problema não é algo passivo. Não é “ouvir o briefing” e seguir em frente.

É um trabalho ativo de:

  • delimitar fronteiras
  • eliminar ambiguidades
  • explicitar hipóteses
  • fazer perguntas desconfortáveis
  • recusar soluções prematuras

É por isso que bons engenheiros, cientistas e estrategistas demoram mais no início — e aceleram depois.

Eles sabem que cada minuto mal gasto entendendo o problema vira semanas de retrabalho tentando corrigir a solução.

Por isso, “apaixone-se pelo problema” não é poesia

É método.

É disciplina intelectual.

É reconhecer que a parte mais difícil — e mais valiosa — do trabalho não é construir a resposta, mas formular a pergunta certa.

Na ciência da computação, isso define a corretude de um algoritmo. Nos negócios, define a relevância de um produto. Na estratégia, define a clareza das decisões.

No fim das contas, soluções são substituíveis. Frameworks envelhecem. Tecnologias mudam.

Mas a capacidade de entender profundamente um problema continua sendo uma das habilidades mais raras — e mais valiosas — que alguém pode desenvolver.

Referências