Pare Um Pouco de Escrever Código. Comece a Fazer Perguntas Antes.

Por que dedicar um artigo inteiro para falar sobre algo tão aparentemente básico como "fazer perguntas"?

Bom, vou ser sincero com você. Nos últimos anos, venho notando uma tendência que me preocupa: a capacidade de algumas equipes de engenharia de software de realmente questionar as coisas parece estar diminuindo. O silêncio em reuniões de planejamento, a aceitação passiva de tarefas mal descritas, o foco total na velocidade da entrega... tudo isso tem um custo, e ele costuma chegar na forma de retrabalho, frustração e bugs em produção.

E eu fico me perguntando: por que será que isso acontece? 🤔

Será que o ambiente da empresa ou da equipe é tóxico, e as pessoas têm medo de falar? Será falta de maturidade do time? Ou talvez a equipe seja muito nova de carreira? Será que não estão engajados o suficiente com o produto para se importarem com o "porquê"?

Ou será que caímos numa armadilha mais sutil? A de que, na nossa busca incessante por "agilidade" e "entrega contínua", simplesmente nos esquecemos de ensinar — e de valorizar — a pausa para a pergunta certa. Aquela pergunta que valida um comportamento, que desafia uma premissa, que evita um erro 500 numa sexta-feira à noite.

É por isso que estamos aqui. Este artigo é um convite para resgatar essa habilidade que considero essencial. Juntos, vamos explorar por que essa capacidade de questionar se tornou o verdadeiro diferencial na carreira de um programador, muito além de qualquer framework ou linguagem da moda. Vamos desafiar a ideia de que perguntar é "coisa de júnior" e mostrar como essa necessidade, na verdade, só aumenta com a senioridade.

A Pergunta Como Ferramenta de Escavação

Pense na sua caixa de ferramentas como programador. Você tem seu teclado, seu editor de código, seu debugger... Mas e se a sua ferramenta mais poderosa não for nenhuma dessas? E se for uma pá?

Todo dia, recebemos tarefas que são como a superfície de um terreno. O pedido diz: "Construa um muro aqui". Nossa reação imediata, quase um reflexo, é começar a empilhar tijolos de código. Mas... o que há por baixo dessa superfície?

A mentalidade de executor se contenta em trabalhar na superfície. A tarefa diz "crie um botão", você cria o botão. Missão cumprida. Mas um verdadeiro engenheiro-escavador sabe que o valor raramente está na superfície. Ele está enterrado, escondido sob camadas de suposições.

Vamos ao exemplo real, no setor de prevenção a fraudes de um banco. A tarefa que chega para você é: "Para cada transação que nosso sistema marca como SUSPECT_FRAUD, precisamos que um evento seja publicado em um tópico do Kafka."

O executor, ao ouvir "Kafka", já pensa no producer, na serialização dos dados, e começa a codificar. Mas você, o escavador, pega sua pá – a pergunta – e dá a primeira cavada para entender o motivo por trás da ferramenta:

"Legal, podemos fazer isso. Só para eu entender o objetivo: qual é a dor que vocês estão tentando resolver com esses eventos? O que o processo atual de vocês não atende?"

A resposta pode ser: "A equipe de analistas de fraude está com problemas para avaliar as transações suspeitas. A query que eles rodam direto no banco de dados para buscar o status SUSPECT_FRAUD é muito lenta e demora demais."

Faz sentido. A escavação continua, agora um pouco mais fundo, para entender o plano deles:

"Perfeito, entendi a dor. E como o time de analistas planeja consumir esses eventos do tópico do Kafka? Vocês já têm uma API ou um serviço preparado para processar esse fluxo, ou a ideia é buscar manualmente no tópico?"

E é aqui que a sua picareta atinge a rocha. A resposta vem com uma certa hesitação: "Bem, a gente pensou em usar uma ferramenta para visualizar o tópico e procurar as transações lá dentro..."

Aha! 😅

Você percebe? O problema real não era a falta de dados no Kafka. O problema real, a "dor" enterrada, era a falta de uma ferramenta eficiente e performática para os analistas acessarem e trabalharem com os dados de transações suspeitas. Eles estavam prestes a trocar um processo lento e manual (query no banco) por outro processo igualmente lento e manual (pesquisar em um tópico bruto do Kafka).

E aqui é preciso ser ainda mais realista. Mesmo que o tópico seja apenas para transações de suspeita de fraude, em um banco com múltiplos produtos — cartão de crédito, transferências, PIX, investimentos — o volume ainda seria gigantesco. A sua próxima pergunta de escavação poderia ser:

"E o que acontece depois que um analista identifica uma dessas transações no tópico?".

A resposta revelaria ainda mais camadas do problema.

Você descobriria que alguns casos precisam de uma análise manual e minuciosa, onde o analista cruza dados. Outros poderiam gerar processos automáticos, como um bloqueio preventivo ou o envio de uma notificação. Veja como as perguntas promovem o entendimento real do problema! A solução não é apenas "mostrar os dados". A solução precisa suportar diferentes fluxos de trabalho, priorizar casos e permitir que os analistas gerenciem suas filas de análise.

Com a fundação do problema finalmente exposta, a conversa muda de "como publicar no Kafka?" para um universo de soluções muito mais inteligentes:

• "E se, em vez de vocês terem o trabalho de consumir o tópico, nós criássemos uma API dedicada e otimizada para a área de fraudes? Ela poderia ser a consumidora desses eventos e já entregar os dados prontos para análise."

• "Ou talvez possamos construir um pequeno painel de alertas que seja 'alimentado' por esses eventos, já mostrando os casos mais críticos em ordem de prioridade e permitindo que o analista 'reivindique' um caso para si?"

• "Dando um passo atrás, já investigamos por que a query original no banco é tão lenta? Talvez uma otimização de índice resolva 80% do problema com 10% do esforço."

Muitos acreditam que esse tipo de questionamento "não é trabalho deles". Mas essa é a diferença entre engenharia e simples construção. Um construtor ergue a parede onde mandam. Um engenheiro pergunta se a fundação aguenta e se a parede está no lugar certo.

No final, o executor entrega o producer do Kafka. A equipe de fraude agora tem um novo problema: um mar de eventos que eles não conseguem usar. O programador entregou a tarefa, mas a dor continua a mesma. O escavador iniciou uma discussão que resolveu a lentidão e melhorou o fluxo de trabalho do analista. Ele entregou valor real. Então a lição é… Pegue sua pá. Faça a primeira pergunta. Comece a escavar. 🙃

Agora a conversa é com vocês iniciantes e programadores juniors!

Porque alguns programadores juniors temem fazer perguntas?

Depois de entendermos que as perguntas são nossa melhor ferramenta de escavação, surge uma questão desconfortável: por que justamente aqueles que mais precisam escavar — os programadores em início de carreira — são frequentemente os mais silenciosos?

Se você é um júnior, talvez sinta um nó na garganta antes de clicar "enviar" naquela pergunta no chat da equipe. A mão treme um pouco, você relê a frase dez vezes, apaga, reescreve. Se você é um sênior, talvez já tenha se perguntado por que o novo contratado, tão inteligente e promissor, parece tão relutante em pedir ajuda, preferindo às vezes ficar travado por horas a fio.

Afinal, de quem é a culpa? É do júnior, que não tem "atitude"? As perguntas que ele quer fazer são "bestas"? Ou será que nós, como indústria, estamos errando em algum ponto fundamental?

A verdade é que esse medo raramente é "culpa" do júnior. Ele é um sintoma, o resultado de uma combinação poderosa de pressões internas e, principalmente, de falhas no ambiente ao seu redor.

O primeiro vilão é um inimigo interno que todos nós conhecemos bem: a Síndrome do Impostor. O programador júnior, recém-chegado, muitas vezes se sente como um fraude que, por algum milagre, conseguiu passar pelo processo seletivo. Ele olha para os colegas mais experientes, que discutem arquiteturas complexas com uma fluidez assustadora, e pensa:

“Todos aqui são gênios. Eu não sei nada. Se eu fizer essa pergunta, eles vão achar que cometeram um erro ao me contratar."

Nessa cabeça, o objetivo primário não é aprender, mas sobreviver e provar seu valor. E, na sua lógica, fazer uma pergunta é o equivalente a levantar uma placa de neon escrito "EU NÃO SOU BOM O SUFICIENTE". Obviamente isso não é verdade! Pense comigo caro leitor! Existem perguntas "bestas"? Vamos ser brutalmente honestos: a única pergunta verdadeiramente besta é aquela que não foi feita e que resultou em um bug em produção ou em três dias de trabalho desperdiçado.

O que parece "óbvio" para um sênior é um universo desconhecido para o júnior. Ele não tem o contexto histórico das decisões, das regras de negócio. Ele não conhece os jargões e as siglas internas da empresa. Uma pergunta como:

"Desculpe, o que vocês querem dizer com 'serviço legado'?"

Não é boba; é um pedido por um mapa para que ele possa se orientar no novo território.

E é aqui que a indústria e a cultura da equipe entram em cena. Muitas vezes, o ambiente não só falha em encorajar perguntas, como ativamente as puni. Quantos de nós já não vimos uma pergunta em um fórum como o Stack Overflow ser recebida com respostas ríspidas ou ser fechada por ser "duplicada"? Essa cultura do "descubra sozinho a qualquer custo", esse batismo de fogo onde sofrer em silêncio é visto como um rito de passagem, ensina uma lição terrível para quem está começando: "Perguntar é perigoso. Fique quieto."

A vontade de um júnior perguntar é o termômetro mais preciso da segurança psicológica de uma equipe. Pense em dois cenários:

• Equipe A: O júnior pergunta algo. O sênior responde com um suspiro, ou com um passivo-agressivo "Isso está na documentação, você leu?", ou pior, ignora. A mensagem é clara: "Você me fez perder tempo". A lição que o júnior aprende? "Nunca mais pergunte nada a essa pessoa."

• Equipe B: O júnior pergunta. O sênior para o que está fazendo e diz: "Ótima pergunta. Eu também tive essa dúvida no começo. Deixa eu te mostrar como eu costumo pensar sobre isso...". A mensagem é: "Sua curiosidade é bem-vinda aqui". A lição? "Este é um lugar seguro para aprender."

Portanto, o medo não é uma falha de caráter do júnior. É o reflexo de um sistema. É a síndrome do impostor batendo de frente com uma cultura que, muitas vezes, valoriza a autossuficiência cega em detrimento da colaboração inteligente.

Para você, júnior: entenda que sua pergunta não é um sinal de fraqueza, mas de engajamento. O risco do silêncio é sempre, sempre maior. Aprenda a formular bem sua pergunta (mostrando o contexto e o que você já tentou), respire fundo e mande.

E para você, sênior ou líder: a responsabilidade é sua. Sua reação à primeira, segunda, décima pergunta de um novato definirá o padrão de comunicação e a velocidade de aprendizado de toda a sua equipe. Acolha a dúvida. Celebre a curiosidade. Lembre-se que o silêncio de um júnior não é um sinal de que tudo está bem; na maioria das vezes, é um sinal de alerta.

Por Que a Experiência Pode se Tornar uma Armadilha de Suposições

Se você tem alguma experiência profissional, conhece a sensação. Naquele momento em que um problema complexo surge, enquanto todos ainda tentam entender o cenário, seu cérebro dispara na frente. Como um veterano que reconhece um som à distância, você ouve a descrição e... clique. O padrão se encaixa.

Essa capacidade de reconhecer padrões é o superpoder que a experiência nos dá. É o que nos torna rápidos e eficientes. Não precisamos mais percorrer cada rua de um problema; nossa mente construiu supervias que nos levam diretamente de um desafio (Ponto A) para uma solução comprovada (Ponto B).

Mas essa mesma superpotência tem um lado sombrio: a armadilha das suposições. A lógica é simples: quanto mais estradas pavimentadas você tem na mente, menor a disposição para explorar trilhas desconhecidas.

É por isso que a experiência, muitas vezes, nos cega para as perguntas certas. Se seu cérebro já decidiu a natureza do problema, suas perguntas servirão apenas para confirmar sua rota preferida, e não para explorar se você está no mapa certo. Enquanto isso, a causa real pode estar em um detalhe que você nem considerou, porque sua "sensação" inicial apontava para outro lugar. Sua experiência, em vez de iluminar o caminho, colocou um par de viseiras.

O grande desafio para o profissional experiente é entender que nem todo problema novo é uma reedição de um antigo. Para encontrar a nuance que muda tudo, as perguntas de sempre não servem. É preciso um novo método, que começa com o silêncio. Antes de fazer a primeira pergunta, você precisa de três coisas: observar, escutar e entender.

• Observar: Antes de saltar para sua conclusão padrão, apenas observe os fatos. Quais são os detalhes que sua mente apressada filtrou? O que está ali, escondido à vista de todos, que não se encaixa no seu padrão mental?

• Escutar: Escute de verdade. Escute quem descreve a frustração do cliente. Escute o colega com menos experiência, mas com um par de olhos frescos. A peça que falta no quebra-cabeça raramente virá da sua própria cabeça; ela virá da perspectiva de outra pessoa.

• Entender: Só depois de observar e escutar, você pode juntar as peças. "Ok, minha experiência aponta para uma causa comum. Mas eu escutei que o problema só acontece em uma situação muito específica e observei um detalhe que parecia inofensivo." É nesse momento que você percebe que sua supervia neural te levaria para a cidade errada.

Só então você está pronto para perguntar. E suas perguntas serão completamente diferentes. Elas não servirão mais para confirmar um viés, mas para explorar a anomalia que você descobriu.

Em vez de uma pergunta que fecha o mundo ("Já verificamos a causa X de sempre?"), sua pergunta o expande: "O que essa situação específica tem de diferente que poderia explicar essa anomalia que notamos?".

O verdadeiro valor de um profissional experiente não está no repertório de respostas prontas, mas na sabedoria de saber quando não usá-las. Está na disciplina de abordar cada desafio com uma "mente de principiante", mas armado com a capacidade de um mestre para observar, escutar e, só então, fazer a pergunta que ninguém mais pensou em fazer. É isso que impede que a experiência se torne uma gaiola dourada.

A Humildade Intelectual de Perguntar o "Óbvio"

Imagine a cena: você está em uma reunião (física ou virtual) cheia de engenheiros inteligentes. A conversa está voando alto, repleta de acrônimos, termos técnicos e referências a sistemas que você mal conhece. A arquitetura de uma nova solução está sendo desenhada no quadro branco, as setas e caixas se multiplicando.

No meio de tudo isso, uma dúvida fundamental começa a se formar na sua cabeça. Não é uma dúvida complexa sobre a implementação, mas algo muito mais simples, quase infantil. Algo como: "Espera um pouco... por que mesmo estamos fazendo tudo isso? Qual é o problema original que deu início a essa discussão toda?"

E então, quase que instantaneamente, uma outra voz sussurra no seu ouvido. É a voz do nosso velho amigo, o ego. E ele diz: "Fique quieto. Não pergunte isso. Todo mundo aqui já entendeu. Se você perguntar isso agora, vai parecer o único que está perdido. Vão achar que você não é tão sênior quanto pensam."

Essa batalha interna é uma das mais importantes e silenciosas na carreira de um desenvolvedor. Vivemos em uma cultura de engenharia que, muitas vezes, glorifica o conhecimento. Ser "sênior" ou "especialista" está diretamente ligado à nossa identidade profissional. Nosso ego, em sua tentativa de nos proteger, cria uma armadura de competência. E fazer uma pergunta "básica" parece ser o mesmo que apontar uma rachadura nessa armadura.

É aqui que o ego se torna perigoso. Ele muda o objetivo do jogo. O objetivo deixa de ser "encontrar a melhor solução para o problema" e passa a ser "não parecer burro na frente dos meus colegas".

Quando o ego está no comando, ele impacta diretamente a forma e a liberdade com que fazemos perguntas. Em vez de buscar clareza, o ego busca validação. As perguntas que ele permite são aquelas que demonstram o que já sabemos: perguntas complexas, cheias de jargão, que sutilmente mostram nosso domínio sobre um assunto. Ele nos impede de levantar a mão e simplesmente dizer: "Desculpe, eu me perdi. Podemos recapitular o objetivo principal?".

O mais irônico e trágico dessa situação é que, naquela sala onde você está com medo de perguntar, é quase garantido que metade das pessoas tem exatamente a mesma dúvida "boba" que você. É um fenômeno conhecido como "ignorância pluralista": um grupo de pessoas se conforma com uma norma (neste caso, o silêncio) porque cada indivíduo assume, erroneamente, que é o único que pensa diferente.

Todos ficam em silêncio, cada um em sua ilha de incerteza, com medo de ser o único a não entender. E é nesse silêncio coletivo que nascem as piores decisões técnicas. É assim que projetos de milhões de dólares são iniciados com base em premissas falhas que ninguém teve a coragem de questionar.

A ferramenta para quebrar esse ciclo perigoso é a humildade intelectual.

Humildade intelectual não é se achar inferior. É simplesmente a capacidade de desapegar do seu ego e priorizar a clareza e o resultado coletivo acima da sua imagem pessoal. É a sabedoria de entender que não há pergunta "boba" quando a estabilidade de um sistema, o dinheiro da empresa e meses de trabalho da sua equipe estão em jogo.

O programador verdadeiramente sênior, aquele que transcendeu a necessidade de parecer inteligente, é quem geralmente tem a coragem de parar o trem. É ele quem diz, com calma e sem vergonha:

"Pessoal, estou notando alguns pontos vagos… podemos dar um passo atrás por um segundo? Só para garantir que estamos todos na mesma página. Qual é, exatamente, o problema de negócio que estamos tentando resolver aqui?"

Observe o poder dessa pergunta. Ela não soa como fraqueza. Ela soa como alguém procurando clareza! Ela dá a todas as outras pessoas na sala a permissão para também serem vulneráveis e admitirem suas próprias dúvidas. Em um instante, a pressão para "saber de tudo" se dissipa, e o foco do grupo volta para o que realmente importa. Quase sempre, o que se ouve depois de uma pergunta dessas é um suspiro coletivo de alívio.

Na sua próxima reunião, quando aquela dúvida fundamental surgir, reconheça a voz do seu ego tentando te silenciar. Agradeça a ele por tentar te proteger. E então, respire fundo, levante a mão e faça a pergunta "óbvia" mesmo assim. Você não será lembrado como aquele que "não sabia", mas como aquele que teve a coragem de garantir que todos estivessem construindo a coisa certa, juntos. E essa é uma marca de liderança que ego nenhum pode comprar.

O Impacto Direto das Perguntas no Seu Código

Até agora, nós conversamos sobre a arte de perguntar como uma soft skill, uma ferramenta para o crescimento profissional, para a dinâmica de equipe e para a estratégia de negócio. Mas e o código? Como essa habilidade (ou a falta dela) realmente encontra o teclado? Como o silêncio de um júnior medroso ou as suposições de um sênior apressado se materializam em if/else, em estruturas de dados, em chamadas de API?

A verdade é esta: cada linha de código que você escreve é a resposta final a uma série de perguntas. A diferença é se essas perguntas foram feitas em voz alta, de forma colaborativa e intencional, ou se foram apenas respondidas silenciosamente, pela sua própria suposição.

A qualidade do seu código é um eco direto da qualidade dessas perguntas. Vamos ver como isso impacta seu dia a dia, em cada fase do desenvolvimento.

1. Antes de Escrever a Primeira Linha (A Fase da Arquitetura)

É aqui que as perguntas têm o maior poder de alavancagem. O silêncio nesta fase não cria bugs, ele cria algo muito pior: dívida técnica arquitetônica, a mais cara e dolorosa de todas.

Imagine que chega uma tarefa simples: "Adicionar campo 'endereço' ao perfil do usuário".

• O desenvolvedor silencioso parte da suposição. Ele abre o modelo User, adiciona um campo address como uma string (VARCHAR(255)) no banco de dados, cria um campo de texto livre no formulário e, em poucas horas, a tarefa está "concluída". Simples. Rápido. E terrivelmente míope.

• O desenvolvedor questionador faz uma pausa. Ele gasta vinte minutos fazendo perguntas que vão definir a fundação da funcionalidade:

  • "Este endereço será usado para quê? Apenas para exibição, para cobrança de faturas ou para entrega de produtos?"

    • Impacto no código: A resposta aqui define tudo. Se for para entrega, talvez um usuário precise de múltiplos endereços (casa, trabalho). Isso transforma um simples campo de texto em uma nova tabela addresses no banco, com uma relação one-to-many com o usuário. O código que você escreverá será completamente diferente.

  • "Precisamos de dados estruturados (CEP, rua, número, cidade) ou um campo único é suficiente?"

    • Impacto no código: Essa pergunta define a complexidade do seu back-end (validações, modelo de dados) e do seu front-end (múltiplos campos de formulário). A falta dessa pergunta leva a um campo de texto livre que, em seis meses, precisará ser migrado com scripts complexos e dolorosos quando o time de marketing decidir que precisa segmentar usuários por cidade.

  • "Vamos nos integrar com algum serviço externo, como cálculo de frete ou validação de CEP?"

    • Impacto no código: A resposta "sim" aqui introduz a necessidade de pensar em chamadas de API, tratamento de falhas de serviços de terceiros e talvez até em um padrão de design como o "Adapter" para isolar essa integração.

O silêncio nesta fase te leva a escrever um código que funciona hoje, mas que é uma bomba-relógio para o futuro. As perguntas certas te levam a escrever um código que talvez seja um pouco mais complexo hoje, mas que é robusto, escalável e preparado para a realidade do negócio.

2. Durante o Desenvolvimento (A Fase da Lógica e dos Edge Cases)

É aqui que o silêncio escreve os bugs mais comuns e as piores experiências para o usuário. Você está no meio do código, encontra uma bifurcação, um cenário não previsto na tarefa.

• O desenvolvedor silencioso toma uma decisão unilateral. "O que acontece se o upload do arquivo do usuário falhar no meio do caminho?". Ele pensa: "Ah, vou só retornar um erro 500. Ninguém vai nem notar". Ou: "O que acontece se a API externa que eu consumo demorar 10 segundos para responder?". Ele supõe: "O usuário que espere."

• O desenvolvedor questionador entende que ele não tem todas as respostas. Ele para e pergunta ao time (PM, Designer):

  • "Quando a API externa demorar a responder, qual é a experiência ideal? Mostramos uma animação de 'loading'? Definimos um 'timeout' de 5 segundos e mostramos uma mensagem de erro amigável?"

    • Impacto no código: Isso se traduz em código para try/catch, Promises, async/await, estados de isLoading no front-end e setTimeout. A falta da pergunta resulta em uma interface travada, que frustra o usuário.

  • "Se o upload do arquivo falhar, qual mensagem exatamente mostramos? 'Erro ao fazer upload' ou algo mais útil como 'Arquivo muito grande. O limite é de 5MB'?"

    • Impacto no código: Isso se traduz em tratamento de erro granular. Em vez de um bloco catch genérico, você escreve lógicas para diferentes tipos de erro, fornecendo feedback útil que transforma um momento de falha em um momento de ajuda para o usuário.

O silêncio nesta fase cria um software que só funciona no "caminho feliz". As perguntas constroem um software robusto, resiliente e que respeita o tempo e a inteligência do usuário, mesmo quando as coisas dão errado.

3. Na Fase de Testes (A Fase da Validação e Segurança)

É aqui que o silêncio escreve as vulnerabilidades. Testar não é apenas confirmar que o código faz o que deveria, mas perguntar ativamente: "Como eu posso quebrar isso?".

• O desenvolvedor silencioso testa o fluxo óbvio. Ele preenche o formulário com dados válidos e clica em "salvar". Funciona. "Teste passou".

• O desenvolvedor questionador veste o chapéu de um usuário mal-intencionado ou simplesmente desastrado. Ele se torna a própria máquina de fazer perguntas, que se transformam em casos de teste:

  • "O que acontece se eu injetar um script no campo de endereço?" -> Impacto no código: Isso te força a implementar sanitização de inputs no back-end para prevenir ataques de Cross-Site Scripting.

  • "O que acontece se eu enviar o mesmo formulário 100 vezes em um segundo?" -> Impacto no código: Isso te leva a pensar em rate limiting e proteção contra ataques de negação de serviço.

  • "Eu, como usuário A, consigo, de alguma forma, atualizar o endereço do usuário B apenas trocando o ID na chamada da API?" -> Impacto no código: Isso te obriga a escrever lógicas de autorização robustas, garantindo que um usuário só possa ver e editar seus próprios dados.

No fim das contas, o código não é um artefato isolado. Ele é a materialização física das conversas, decisões e, principalmente, das perguntas que foram (ou não) feitas ao longo de seu ciclo de vida. Fazer perguntas não é uma formalidade burocrática. É a prática de engenharia mais concreta e eficiente que existe. É o que transforma código frágil em software de verdade.

O Termômetro da Boa Pergunta: Como Saber se Você Está no Caminho Certo

Depois de tudo isso, a dúvida mais importante talvez seja esta:

"Ok, eu entendi a importância. Mas no calor da batalha do dia a dia, no meio de uma reunião apressada, como eu sei se a pergunta que estou prestes a fazer é boa? Existe algum sinal? Algum teste rápido para validar minha própria curiosidade?"

Não existe uma fórmula mágica, um if/else que separe uma pergunta ruim de uma boa. Mas, com base em tudo que conversamos, existem sinais claros, sintomas positivos que aparecem quando sua habilidade de questionar está amadurecendo.

Pense neles como um "termômetro" para medir a qualidade e o impacto da sua curiosidade. Se você notar que suas perguntas estão causando os efeitos abaixo, parabéns, você está no caminho certo.

Sinal 1: Suas perguntas geram mais contexto, não apenas um "sim" ou "não". Uma pergunta fraca busca apenas uma confirmação. "O botão deve ser azul?". A resposta é "sim" ou "não" e a conversa morre. Uma pergunta forte busca a intenção por trás da decisão. "Qual é o critério para a escolha da cor do botão? Estamos seguindo um guia de design ou há uma razão de acessibilidade?". A primeira pergunta te dá um pixel. A segunda te dá o propósito, o que te permite tomar dezenas de outras decisões de forma autônoma no futuro. Se suas perguntas estão abrindo a conversa em vez de fechá-la, seu termômetro está subindo.

Sinal 2: Elas movem a conversa do "Como" para o "Porquê". Esse é um dos sinais mais claros de que você está escavando. Se a maioria das suas perguntas é sobre detalhes de implementação ("Devo usar um POST ou PUT neste endpoint?"), você está operando no nível da execução. É importante, mas não é onde o maior valor é gerado. Quando suas perguntas começam a evoluir para "Por que o usuário precisa ver está página em primeiro lugar? Qual é o fluxo de trabalho que estamos tentando facilitar aqui?", você transcendeu a tarefa. Você está operando no nível da estratégia.

Sinal 3: Elas te forçam a pensar (e a falar) sobre cenários de falha. Se você se pega sendo a pessoa que pergunta "Ok, e o que acontece se essa chamada de API falhar?", "Qual é o comportamento esperado se o usuário inserir um texto com mais de 500 caracteres aqui?", "Como o sistema reage se este serviço de terceiro estiver offline?", comemore. Você deixou de ser um programador otimista para se tornar um engenheiro resiliente. Você está construindo software para o mundo real, um lugar caótico e imprevisível. Você está ativamente caçando bugs antes mesmo de eles terem a chance de nascer.

Sinal 4: Elas, às vezes, pausam a reunião por um instante.

Isso pode parecer contraintuitivo, afinal, ninguém quer ser a pessoa que "atrasa" uma reunião. Mas quando sua pergunta causa uma pausa, um silêncio momentâneo onde as pessoas se olham e o fluxo rápido da conversa é interrompido, isso geralmente é um sinal de ouro.

Imagine o cenário: a equipe está discutindo uma nova funcionalidade para permitir que os usuários editem um tipo de documento importante no sistema. Todos estão alinhados, a interface parece clara, a tarefa parece simples. O trem está andando a todo vapor.

É nesse momento que você levanta a mão e diz, com calma:

"Pessoal, só para eu entender a fundo. A gente está falando sobre permitir que o usuário edite e salve novas versões deste documento, certo? Mas, ao revisar a estrutura do nosso banco de dados, eu não encontrei nenhuma tabela de histórico ou uma forma de versionamento para o documento. Como vamos conseguir auditar quem alterou o quê e quando? Ou, mais importante, como vamos conseguir reverter para uma versão anterior se um erro grave for cometido?"

Silêncio.

As pessoas piscam e se olham. O Product Manager para de digitar. O Tech Lead fica com um olhar de dúvida...

O que acabou de acontecer aqui? Você não fez uma pergunta para ser "do contra". Você conectou uma necessidade de negócio fundamental (auditoria, segurança, recuperação de desastres) com uma realidade técnica que estava sendo completamente ignorada (a ausência de uma estrutura de dados para suportar isso).

A "simples" tarefa de "permitir a edição" acabou de revelar uma necessidade muito maior e mais complexa de um sistema de versionamento. Sem a sua pergunta, a equipe provavelmente construiria a funcionalidade. Meses depois, um cliente alteraria um contrato por engano, pediria para "voltar à versão de ontem" e o pânico se instalaria ao perceberem que isso era impossível. O custo para consertar isso em produção, com dados reais já sendo modificados, seria dez vezes maior.

Essa pausa que a sua pergunta causou não foi um atraso; foi a economia de talvez um mês inteiro de retrabalho e dor de cabeça no futuro. Você não interrompeu o fluxo; você o salvou de correr em direção a um penhasco. Quando sua pergunta faz todos pararem para pensar em uma consequência que ninguém havia considerado, você não está atrasando a reunião. Você está sendo o engenheiro mais valioso da sala.

Sinal 5: Elas frequentemente resultam em código mais simples (ou em nenhum código). Aqui está um sinal contraintuitivo, mas poderoso. As melhores perguntas muitas vezes levam à remoção de complexidade. Perguntas como "Nós realmente precisamos construir esse sistema de cache customizado agora, ou podemos começar sem ele e medir a performance real em produção?" ou "Existe alguma ferramenta que já faz isso e que poderíamos usar, em vez de construir do zero?" são incrivelmente valiosas. Se suas perguntas estão ativamente combatendo o over-engineering e levando a soluções mais simples, você está gerando um valor imenso para a sua equipe.

Sinal 6: Você começa a entender melhor o trabalho dos seus colegas (não-técnicos). Quando você pratica o questionamento profundo, um efeito colateral maravilhoso acontece: você começa a entender de verdade as dores e os processos do time de Marketing, Vendas, Financeiro ou Suporte. Se, ao final de uma discussão sobre uma feature, você consegue explicar para outra pessoa por que o time de vendas precisa daquilo, sua pergunta foi excelente. Você está construindo pontes entre os silos da empresa, não apenas software.

Saber se você está fazendo as perguntas certas não é sobre ter uma epifania a cada questionamento. É sobre observar os resultados. É uma prática contínua de usar a curiosidade como uma ferramenta para gerar clareza, simplicidade e valor. E a boa notícia é que, quanto mais você pratica, mais afiado e confiável seu "termômetro" se torna.

Testes de Unidade, a Máquina de Fazer Perguntas

Para muitos programadores, a palavra "teste" evoca uma sensação de... dever. Uma tarefa a ser feita no final, quase como arrumar a bagunça depois da festa. É uma formalidade para aumentar aquele número de "cobertura de código" e deixar o pipeline de CI/CD feliz. Se essa é a sua visão, eu te convido a suspendê-la por alguns minutos.

E se eu te dissesse que essa é a forma mais superficial e menos interessante de enxergar os testes? E se, na verdade, os testes de unidade fossem a ferramenta de design mais poderosa que você tem à sua disposição? E se eles não fossem sobre verificar o código, mas sobre descobri-lo e defini-lo?

É exatamente isso. Escrever um bom teste de unidade é um exercício estruturado de fazer perguntas incrivelmente precisas sobre o seu código, antes mesmo que ele exista. O teste não é o fiscal do seu código; ele é o seu arquiteto, o seu parceiro de diálogo mais exigente.

Ao sentar para escrever um teste, você é forçado a parar de pensar de forma abstrata e a começar a fazer perguntas brutalmente concretas.

Primeira pergunta, a mais fundamental: "O que, exatamente, você deveria fazer?"

Antes mesmo de escrever function calcularDesconto(...){, você escreve o esqueleto do seu teste: it('deve calcular o desconto corretamente para clientes VIP em produtos elegíveis'). O simples ato de dar um nome claro e descritivo ao seu teste te obriga a definir a responsabilidade única da sua função. Se o nome do teste começa a ficar complicado e cheio de "E" (it('deve calcular o desconto E aplicar a taxa de frete E enviar um email')), você acaba de receber o feedback mais claro possível: sua função está tentando abraçar o mundo. O teste te força, desde o início, a criar componentes pequenos, focados e coesos, não por dogma acadêmico, mas por pura praticidade.

Segunda pergunta: "Com o que vamos trabalhar e o que você vai me devolver?"

Um teste precisa de inputs concretos e espera um output exato. expect(calcularDesconto({ cliente: 'VIP', preco: 200.00 })).toBe(20.00);. Este pequeno trecho de código é uma das coisas mais poderosas que você pode fazer. Você está definindo o contrato da sua função de forma inequívoca. Não há espaço para ambiguidade. Você está especificando, em código, o comportamento esperado. É o fim do "ah, eu não sabia que essa função podia receber um objeto sem a propriedade 'cliente'". O teste define as regras do jogo.

Terceira pergunta: "E se tudo der certo? Como é o seu melhor dia?"

Estes são os seus testes de "caminho feliz". Você escreve cenários para os casos de uso mais comuns e importantes. it('deve retornar 0 para clientes não-VIP'), it('deve calcular o desconto corretamente para clientes normais acima de R$500'). Esses testes constroem a fundação da sua lógica, garantindo que o comportamento principal está sólido como uma rocha.

E quando o universo conspirar contra você?

O teste se torna seu "advogado", forçando você a pensar nos "caminhos tristes", nos cenários caóticos do mundo real que tantas vezes ignoramos. Seu conjunto de testes começa a fazer um interrogatório implacável:

• "O que acontece se eu te passar null como cliente? Você explode com um TypeError ou retorna 0 de forma elegante?" -> it('deve retornar 0 quando o cliente for nulo').

• "E se o preço do produto for um número negativo? Você o aceita e calcula um desconto negativo bizarro, ou lança uma exceção de argumento inválido?" -> it('deve lançar um erro para preços negativos').

• "E se o objeto do cliente vier sem a propriedade 'tipo'? Você assume um padrão ou quebra?" -> it('deve tratar um cliente sem tipo como não-VIP').

• "E se eu te passar um preço gigantesco que cause um estouro de número? E se o tipo do cliente for uma string vazia?"

Cada um desses testes é uma pergunta de design. A resposta que você dará a ela será uma decisão consciente, que será implementada no seu código. Você não está mais deixando esses casos extremos ao acaso; você está ativamente projetando o comportamento da sua função para lidar com o caos.

É isso que transforma o desenvolvimento de software. Você deixa de operar no modo "eu acho que funciona" e passa para o modo "eu posso provar que funciona nestes cenários". É uma mudança de um desenvolvimento baseado na esperança para uma engenharia baseada em evidências.

A Pergunta Final!

Vimos que as perguntas são as melhores ferramentas de escavação que um programador possui. Vimos como o medo, muitas vezes, silencia o enorme potencial de quem está começando; como a experiência, ironicamente, pode criar viseiras que nos impedem de ver novas soluções; e como a humildade para questionar o "óbvio" é, na verdade, uma das maiores demonstrações de força e liderança que existem.

Agora, vamos juntar todas essas peças. Afinal, depois de tanta conversa, como transformamos essa reflexão em um plano de ação? Como garantimos que, na próxima segunda-feira, nossa postura será diferente?

Muitos buscam uma "fórmula mágica" para a pergunta perfeita, um template que possam copiar e colar. A verdade é que as melhores perguntas não nascem de uma fórmula, mas de uma postura. Uma postura que se sustenta em três ações fundamentais que devem vir antes de qualquer questionamento: Observar, Escutar e Entender.

É por isso que estes três pilares são tão cruciais. Eles são a matéria-prima da boa pergunta. Sem eles, suas perguntas serão baseadas em "achismos". Com eles, suas perguntas serão baseadas em evidências.

• Observar é o ato de desligar o piloto automático. É ler a tarefa com olhos de detetive, não de executor. É notar a pequena inconsistência na documentação que ninguém viu. A observação te dá os fatos.

• Escutar é o superpoder de absorver informação sem o filtro do seu próprio ego. É ouvir a frustração na voz do cliente, a hesitação na explicação do Product Manager. A escuta te dá as emoções e as dores por trás dos fatos.

• Entender é a pausa estratégica para conectar os pontos. "Ok, observei que a performance cai aqui (o fato), e escutei que o cliente só reclama disso no final do mês (a dor). Entendi! O problema está no volume de dados do fechamento mensal."

Só depois dessa síntese é que a pergunta matadora — a pergunta certa — pode ser formulada, porque agora ela nasce de um contexto rico. Com essa base, vamos direcionar a conversa final para os diferentes momentos da carreira.

Para Seniores, Tech Leads e Especialistas: A Autoanálise Como Ferramenta de Crescimento

Se você está em uma posição de liderança ou é uma referência técnica, sua responsabilidade transcende o código; você é um guardião do contexto e um catalisador da clareza para toda a equipe. Sua autoanálise deve ser um hábito constante. Pergunte-se com honestidade:

• "Eu estou realmente me preparando para o jogo?" Antes de uma reunião de refinamento, eu dedico tempo para ler a documentação e pensar nas possíveis ambiguidades, ou chego "de peito aberto", reagindo apenas ao que me é apresentado e ocupando o tempo da reunião com dúvidas que eu poderia ter resolvido antes?

• "Eu estou afiando meu machado?" Qual foi a última vez que dediquei tempo para melhorar a maneira como analiso uma tarefa, tentando enxergar além da solução óbvia e conectar os pontos com a estratégia do negócio? Ou estou apenas confiando nos meus reflexos e na experiência passada, correndo o risco de cair no "Viés do Especialista"?

• "Minhas perguntas são um farol ou uma neblina?" Quando eu questiono algo, estou colaborando com perguntas objetivas que guiam a equipe para uma solução ("Já consideramos o impacto disso na performance do dashboard X?")? Ou estou apenas trazendo mais dúvidas e incertezas sem oferecer um caminho ("Isso tudo me parece muito complexo e arriscado.")? A primeira é liderança; a segunda pode ser paralisia por análise.

Para os Juniores: Navegando o Medo e Encontrando Seus Aliados

Para você que está no início da jornada, a mensagem final é clara: o medo de perguntar não é uma falha sua. Mas superá-lo é uma das primeiras e mais importantes vitórias da sua carreira. E você não precisa fazer isso sozinho.

• Seja um Observador de Pessoas: Nas reuniões, ative seu modo detetive. Quem são os seniores que fazem perguntas claras e com humildade? Quem tem paciência para explicar um conceito pela segunda vez? Quem reage bem às dúvidas dos outros? Essas pessoas são seus "portos seguros". Mapeie seus aliados e se aproxime deles. A maioria dos bons seniores adora ensinar.

• Abrace a "Pergunta Boba" de uma vez por todas: Eu te garanto, leitor: não existe pergunta boba. O que existe é um time inteiro construindo uma funcionalidade por três semanas com base numa premissa completamente errada, porque ninguém teve a coragem de fazer a pergunta "boba" que desmascararia o problema logo no início.

Entenda a Regra da Repetição: É aqui que mora o bom senso. Há uma diferença colossal entre:

• Fazer 70 vezes a mesma pergunta sobre um fato: Isso não demonstra curiosidade, mas falta de esforço para anotar, pesquisar e reter a informação que já lhe foi passada. Mostra que você não está fazendo a sua parte para estudar o assunto e melhorar.

• Fazer a mesma perguntas algumas vezes ao longo de um projeto complexo e do mundo real: Isso é completamente normal, esperado e até desejável! O contexto muda, os detalhes se aprofundam. Fazer a mesma pergunta em diferentes estágios do projeto mostra que você está engajado e tentando conectar os pontos.

E aqui vai um segredo final: os bons seniores e líderes querem que você pergunte. O silêncio de um júnior é aterrorizante. Significa uma de duas coisas: ou ele é um gênio que entendeu tudo de primeira (raro), ou ele está completamente perdido e com medo, pois não foi dado espaço para dúvidas! E no final está cavando um buraco de retrabalho que só será descoberto daqui a duas semanas. Um sênior deveria ter medo do dia em que nenhum júnior busca mais a sua ajuda, pois isso significa que a cultura de aprendizado e segurança da equipe está quebrada e que o ego está falando mais alto.

No fim, a habilidade de fazer perguntas é a habilidade de aprender, de colaborar e de liderar, tudo em um só pacote. É a ferramenta que nos impede de construir catedrais magníficas no terreno errado. A jornada para se tornar um questionador melhor começa com uma única decisão: a de valorizar a clareza acima da certeza, e a humildade acima do ego.

Obrigado por ler até o final e até o próximo artigo! 🖖🏼