O Problema XY e perguntar sobre a sua tentativa de solucao (Y) em vez do seu problema real (X) – por isso as pessoas acabam a ajuda-lo com a coisa errada.
Voce Tem Um Problema. Mas Nao Esta Perguntando Sobre Ele.
Voce quer fazer X. Voce acha que Y pode ser o caminho para fazer isso. Voce nao sabe como fazer Y, entao pede ajuda com Y. Alguem gasta 20 minutos te ajudando com Y. Ai descobre que Y nunca ia resolver X.
Esse e o Problema XY. E acontece o tempo todo – em servidores do Discord, threads do Stack Overflow, canais do Slack, grupos de WhatsApp e qualquer outro lugar onde as pessoas pedem ajuda.
A pior parte? Voce nao percebe que esta fazendo isso. Voce genuinamente acha que esta fazendo a pergunta certa. So esta tao focado na solucao que ja escolheu que esqueceu de mencionar o problema real.
Como Ele Se Parece na Pratica
Programacao: A Armadilha da Extensao de Arquivo
Alguem pergunta em um chat:
Como eu pego os ultimos 3 caracteres de um nome de arquivo em Python?
As pessoas comecam a ajudar. Sugerem fatiamento de string, filename[-3:], padroes regex. Quinze minutos de ida e volta. Ai alguem finalmente pergunta: “Por que voce precisa dos ultimos 3 caracteres?”
Eu quero verificar se um arquivo e
.csv.
A resposta real? filename.endswith('.csv') ou pathlib.Path(filename).suffix. Pegar os ultimos 3 caracteres teria falhado com .json, .xlsx ou qualquer extensao que nao tenha exatamente 3 caracteres.
O problema era X (verificar o tipo do arquivo). A pessoa perguntou sobre Y (pegar os ultimos 3 caracteres).
Programacao: A Toca do Coelho do Regex
Como eu escrevo um regex para validar um endereco de email?
Esse e um dos Problemas XY mais comuns na programacao. O problema real quase sempre e “preciso verificar se o usuario digitou um email valido.” A resposta para isso e: nao use regex. Envie um email de confirmacao. Ou use uma biblioteca de validacao bem testada. Criar seu proprio regex de email e uma ideia notoriamente ruim que ja queimou milhares de desenvolvedores.
Mas a pessoa que pergunta ja decidiu que regex e a solucao. Entao pergunta sobre regex, e o problema real nunca aparece.
Fora da Programacao: A Furadeira e o Buraco
Uma pessoa entra em uma loja de materiais de construcao:
Qual a melhor broca de 6mm para drywall?
O vendedor poderia simplesmente apontar para as brocas. Mas um bom vendedor pergunta: “O que voce esta tentando fazer?”
Eu quero pendurar um quadro.
Descobre-se que a pessoa nao precisa de broca nenhuma. Fitas adesivas de comando ou um preguinho resolveriam melhor, causariam menos dano e levariam uma fracao do tempo. A pessoa nao precisava de uma broca – precisava de um quadro na parede.
Fora da Programacao: O Horario de Trabalho
Alguem pede ao gerente:
Posso trocar para o turno de terca/quinta?
O gerente comeca a analisar conflitos de agenda, requisitos de cobertura e logistica de equipe. Depois de uma longa discussao, ele pergunta por que.
Preciso buscar meu filho na escola as segundas, quartas e sextas.
Agora o gerente ve o problema real e oferece uma solucao mais simples: adiantar o horario de entrada em uma hora nesses tres dias. Sem necessidade de reorganizar toda a escala. O funcionario estava tao fixado em uma solucao especifica que nunca mencionou o que realmente precisava.
Como Reconhecer Quando Voce Esta Fazendo Isso
Voce provavelmente esta no territorio do Problema XY quando:
Voce esta perguntando sobre uma ferramenta ou metodo especifico em vez de um objetivo. Se sua pergunta comeca com “Como eu uso X para…” ha uma boa chance de que voce deveria estar perguntando “Como eu consigo Z?” em vez disso.
Sua pergunta exige muita explicacao de contexto. Se voce se ve escrevendo tres paragrafos de contexto para justificar por que esta tentando fazer algo incomum, de um passo atras. A abordagem incomum pode ser a abordagem errada.
As respostas que voce recebe nao resolvem seu problema. Se as pessoas continuam respondendo sua pergunta corretamente mas as respostas nao estao ajudando, voce pode estar fazendo a pergunta errada.
Voce esta lutando contra as ferramentas. Quando sua abordagem exige contornar a forma normal de fazer as coisas, isso e um sinal. Voce pode estar forcando uma solucao onde existe uma melhor.
Alguem pergunta “O que voce realmente esta tentando fazer?” Quando alguem que esta ajudando pergunta isso, nao esta sendo dificil. A pessoa reconheceu o Problema XY. Responda honestamente – ela esta tentando te economizar tempo.
Como Evitar
A solucao e direta: compartilhe o problema original, nao apenas sua tentativa de solucao.
Isso nao significa que voce nao deva mencionar o que tentou. Voce absolutamente deve – mostra esforco e ajuda as pessoas a entender seu raciocinio. Mas comece pelo problema, nao pela tentativa de solucao.
Antes (Problema XY):
Como eu faco parse de HTML com regex em Python?
Depois (Problema Real):
Preciso extrair todos os links de uma pagina web. Comecei tentando usar regex para fazer parse do HTML, mas nao tenho certeza se esta funcionando corretamente. Existe uma abordagem melhor?
Agora quem esta ajudando ve o objetivo real (extrair links) e a abordagem que voce tentou (regex). Podem te direcionar para BeautifulSoup ou lxml em vez de te ajudar a escrever um regex que vai quebrar na proxima pagina HTML ligeiramente diferente.
Antes (Problema XY):
Como eu defino uma variavel de ambiente de dentro de um Dockerfile CMD?
Depois (Problema Real):
Minha aplicacao precisa de um valor de configuracao diferente em producao vs. staging. Pensei em setar uma env var na instrucao CMD, mas nao parece funcionar do jeito que eu esperava. Qual e a forma correta de lidar com configuracao por ambiente no Docker?
A segunda versao convida respostas sobre Docker env files, build args, overrides do docker-compose e outras solucoes apropriadas. A primeira versao prende quem esta ajudando a debugar uma abordagem ruim.
A Conexao Com Fazer Perguntas Melhores
O Problema XY e na verdade um caso especifico de um problema maior: pedir para perguntar sobre a coisa errada. Quando voce pula o contexto real e vai direto para sua solucao presumida, voce esta escondendo a informacao que quem ajuda mais precisa.
A formula do Skip The Ask resolve isso naturalmente:
- Sua situacao – Com o que voce esta trabalhando e o objetivo real que esta tentando alcancar
- Sua pergunta especifica – Com o que voce precisa de ajuda, enquadrada em torno do objetivo, nao apenas de uma solucao possivel
- Detalhes relevantes – O que voce ja tentou (incluindo a abordagem que te levou pelo caminho Y) e por que nao esta funcionando
Quando voce descreve sua situacao partindo do problema real, voce da a quem ajuda o panorama completo. Eles podem avaliar sua abordagem e sugerir alternativas que voce nao considerou. E assim que voce recebe respostas que realmente resolvem seu problema em vez de respostas que tecnicamente respondem sua pergunta mas te deixam travado.
Da proxima vez que for pedir ajuda, pare por cinco segundos e pergunte a si mesmo: estou perguntando sobre o que realmente preciso, ou estou perguntando sobre uma abordagem especifica que ja escolhi? Se for a segunda opcao, volte atras. Comece pelo X, nao pelo Y.
Para uma visao mais ampla sobre como fazer perguntas melhores em qualquer plataforma, veja o nosso guia completo para fazer perguntas melhores online.