And What Are You Doing

O que realmente significa perguntar "o que você está fazendo"

A pergunta parece simples, mas a resposta quase nunca é. Eu já passei horas tentando explicar meu trabalho para alguém que acabou de entrar no escritório e viu minha tela cheia de console, logs subindo em velocidade absurda, e um monte de gráficos que não faziam sentido pra quem não estava no contexto. A primeira coisa que eu aprendi foi que ninguém quer saber os detalhes técnicos quando você para no corredor. Querem um resumo de uma frase. E mesmo assim, às vezes a resposta mais honesta é: estou tentando descobrir por que o serviço não responde há três horas. Essa variação da pergunta aparece com frequência em revisões de código, em entrevistas e até em conversas informais no break room. A diferença é que ela exige uma justificativa, não uma descrição. Eu costumo responder falando do problema que estou resolvendo, não da ferramenta que estou usando. Já vi gente explicar que está migrando um banco legado para o novo modelo relacional, e quando perguntaram why, responderam que era porque o SQL antigo estava lento. A resposta certa seria mencionar o timeout nas queries de agregação que acontecia toda sexta à noite, quando o volume de transações disparava. Esse era o sintoma real, não a lentidão genérica. O que acontece na prática é que as pessoas fazem perguntas abertas esperando uma resposta curta, e quem responde acaba entrando em detalhes que ninguém pediu. Minha estratégia agora é dar a resposta em duas camadas. Primeiro uma linha: estou refatorando a camada de acesso a dados porque as queries atuais estão gerando carga desnecessária no banco. Depois, se a pessoa insistir, entro nos detalhes. Funciona na maioria das vezes.

Como responder de forma útil sem soar como um robô

A maior armadilha é transformar uma resposta casual em uma apresentação técnica. Eu já fiz isso várias vezes e as pessoas simplesmente desligaram. A dica prática é mapear o nível de conhecimento de quem está perguntando antes de entrar no mérito. Quando um gerente de projeto pergunta o que você está fazendo, ele quer saber se vai entregar no prazo, não como o sistema funciona. Quando um colega da mesma área pergunta, aí sim vale a pena entrar nos detalhes de implementação. Outro ponto que poucas pessoas consideram: o timing importa mais do que o conteúdo. Perguntas feitas no início da manhã, quando ainda estão chegando, geralmente merecem respostas curtas. Às 17h30, na véspera de um release, a mesma pergunta pode ser interpretada como pressão ou curiosidade genuína, dependendo do tom de voz. Eu aprendi isso na hard way, quando respondi uma pergunta superficial com vinte minutos de explicação técnica numa sexta à tarde e vi o olhar de quem perguntou mudar de interesse para alívio rápido. A pessoa só queria saber se eu estava ocupado o suficiente para não ser interrompido depois.

what are you doing right now

Essa versão da pergunta é especificamente interessante porque o advérbio "right now" muda completamente a expectativa. Não é sobre seu projeto atual, é sobre o que sua mão está fazendo no momento exato da pergunta. Eu já respondi isso de forma literal uma vez e a pessoa ficou em silêncio por alguns segundos. Depois rimos dos dois lados, mas a lição ficou: quando alguém pergunta o que você está fazendo agora, a resposta deve refletir a ação imediata, não o contexto macro. No meu dia a dia, isso significa algo como: estou revisando um pull request que mudou a configuração do cluster, ou estou escrevendo testes para cobrir um edge case que quebrou em produção semana passada, ou tô só tomando café porque o deploy travou e não tem nada pra fazer até o responsável resolver. A última é a mais honesta e, paradoxalmente, a que mais gera conversas produtivas.

Por que essa pergunta é tão difícil de responder bem

Existem pelo menos três razões que se sobrepõem. A primeira é que trabalho técnico é inerentemente estratificado. O que parece uma tarefa simples na superfície — atualizar uma dependência, por exemplo — esconde decisões de compatibilidade, rollback plan, validação em staging e monitoramento pós-deploy. A segunda é que o entrevistador ou colega raramente tem o contexto completo do seu dia, então qualquer resposta que você dê parecerá incompleta ou exagerada dependendo do ângulo. A terceira, e talvez a mais importante, é que nós mesmos muitas vezes não temos clareza sobre o que estamos fazendo no momento exato. Passamos de uma tarefa para outra sem registrar onde paramos, e quando perguntam, a mente vai direto para o último contexto ativado, que pode ser completamente diferente do que estava na sua lista principal. Eu tenho um jeito pouco ortodoxo de lidar com isso. Anoto em uma linha, no início de cada bloco de trabalho, o que estou prestes a fazer e em qual estado something ficou a última tarefa. Não é um diário, é só uma nota rápida no bloco de notas do celular. Quando perguntam, eu leio e adapto. Às vezes a nota diz algo como "testando migração 047 no banco de staging" e a resposta fica pronta em três segundos. Sem forçar memória, sem inventar detalhe técnico que não existe.

O que funciona na prática e o que não funciona

Respostas estruturadas em tópicos funcionam bem em e-mail e em documentação interna. Não funcionam bem em conversa cara a cara, a menos que a pessoa esteja anotando algo. Linguagem muito técnica também é um problema real: eu já ouvi colegas descrevendo trabalho deles usando siglas que nem eu conhecia, e no final da explicação percebi que eles próprios estavam confusos sobre o que haviam dito. O conselho prático é traduzir o jargão antes de usá-lo, não depois. O que realmente funciona na maior parte das situações é a estrutura problema-acao-resultado. Dizer que estou resolvendo um problema de latência, que ação estou tomando para mitigar e qual resultado espero até o fim do dia. Isso dá contexto, direciona a conversa e ainda sinaliza que você tem controle da situação, mesmo que o resultado ainda não seja certo. E honestamente, essa é a parte mais importante: reconhecer quando não sabe o resultado final, porque isso evita promessas que vão estourar na próxima reunião de status. A pergunta o que você está fazendo nunca vai ter uma resposta única e perfeita. Mas quanto mais você pratica a habilidade de calibrar o nível de detalhe conforme o interlocutor, mais naturais as respostas ficam. E com o tempo, você para de pensar na pergunta como uma cobrança e passa a enxergar como uma oportunidade de alinhar expectativas — algo que, no fim das contas, é praticamente o mesmo trabalho que você já faz quando documenta um procedimento ou explica um bug pra equipe de suporte.