Síndrome do impostor na tecnologia

Este post é baseado na palestra It's Dangerous to Go Alone: Battling the Invisible Monsters in Tech, apresentada por Julie Pagano na PyCon 2014.

A palestra fala sobre algo que muita gente sente, mas pouca gente admite em voz alta: insegurança, ansiedade, falta de confiança e síndrome do impostor na carreira de tecnologia.

E talvez a primeira coisa importante seja essa:

não é só sobre "se sentir inseguro às vezes".

Todo mundo passa por momentos de dúvida. Começar em um emprego novo, receber uma tarefa difícil, trocar de stack, entrar em um time mais experiente ou fazer uma entrevista técnica pode balançar qualquer pessoa.

A síndrome do impostor é diferente porque ela distorce a forma como você interpreta a própria competência.

O que é síndrome do impostor

Síndrome do impostor é a dificuldade de internalizar as próprias conquistas.

Você entrega algo bom, mas pensa:

• "foi sorte"
• "qualquer pessoa faria melhor"
• "eu só consegui porque me ajudaram"
• "uma hora vão descobrir que eu não sou tão bom assim"

O problema é que desenvolvimento de software já envolve falha o tempo todo.

A gente quebra coisa. Introduz bug. Não entende uma abstração. Erra estimativa. Fica preso em problema simples. Precisa pedir ajuda. Volta para documentação. Apaga código que acabou de escrever.

Isso é normal.

Mas para quem está preso na síndrome do impostor, as falhas ficam gigantes e as vitórias ficam pequenas.

Você lembra do bug que causou, mas esquece dos bugs que corrigiu. Lembra da pergunta que não soube responder, mas ignora tudo que estudou para chegar até ali. Lembra da crítica no code review, mas não absorve quando alguém diz que seu trabalho foi bom.

Como Julie resume na palestra, as vitórias diminuem de importância e as falhas parecem enormes.

O impacto real na carreira

A síndrome do impostor não fica só na cabeça. Ela muda comportamento.

Muita gente deixa de compartilhar conhecimento porque acha que não tem nada relevante para dizer. Não escreve blog post. Não palestrata. Não faz mentoria. Não comenta em discussões técnicas. Não abre pull request em projeto open source.

Não porque falta capacidade.

Mas porque existe um medo constante de ser exposto.

Esse medo aparece em situações comuns:

• pair programming parece assustador porque alguém vai ver você pensando
• code review parece julgamento pessoal, não melhoria do código
• entrevista parece um ritual impossível
• vaga nova parece sempre "fora do seu nível"
• palestra ou artigo parece algo reservado para "pessoas realmente boas"

Uma das partes mais fortes da palestra é quando Julie conta que queria trabalhar no Google, mas não aplicava porque achava que não era boa o suficiente. Só avançou porque uma recrutadora insistiu, conversou com ela e ajudou a atravessar aquela barreira.

Isso é importante porque mostra um custo invisível:

a pessoa não falha porque tentou e não conseguiu; ela falha antes, porque nem tenta.

O outro lado: tentar compensar demais

Nem todo mundo com síndrome do impostor se esconde.

Algumas pessoas fazem o contrário: tentam compensar a insegurança trabalhando mais do que deveriam.

Leem todos os livros. Aceitam todos os projetos. Vão a todos os eventos. Estudam de noite. Trabalham no fim de semana. Tentam estar sempre atualizadas. Sentem que estão sempre correndo atrás de todo mundo.

Por um tempo, isso pode até parecer produtividade.

Mas não é sustentável.

O resultado costuma ser burnout: exaustão prolongada, perda de interesse no trabalho e, às vezes, vontade de largar tudo.

E esse é um ponto muito sério. A síndrome do impostor não tratada pode fazer uma pessoa talentosa parar de gostar de programar.

Síndrome do impostor não é falta de competência

Um cuidado importante: síndrome do impostor não significa que toda insegurança é injustificada.

Às vezes você realmente precisa estudar mais. Às vezes seu código precisa melhorar. Às vezes você não está pronto para uma responsabilidade específica.

Isso faz parte.

A diferença é que uma avaliação saudável consegue olhar para pontos fortes e pontos fracos. Já a síndrome do impostor quebra esse equilíbrio.

Você enxerga limitações, mas não enxerga progresso.

Julie também compara isso com o efeito Dunning-Kruger: pessoas com pouca habilidade que superestimam a própria competência. É curioso porque os dois fenômenos convivem na indústria.

De um lado, pessoas qualificadas deixando de tentar porque acham que não são boas o suficiente.

Do outro, pessoas pouco preparadas se colocando em todos os espaços porque não percebem suas próprias limitações.

Para engenharia de software, saber onde você é forte e onde precisa de ajuda é uma habilidade valiosa. O problema é quando esse senso de limite vira prisão.

Não vá sozinho

O título da palestra vem de uma frase clássica dos jogos: "It's dangerous to go alone".

É perigoso ir sozinho.

Uma das recomendações centrais é construir uma "party": um grupo de suporte com pessoas em quem você confia.

Não é um grupo de bajuladores. Não é gente para dizer que você é incrível o tempo todo.

É gente que consegue fazer duas coisas:

1. dar feedback honesto e construtivo
2. lembrar você dos fatos quando sua percepção estiver distorcida

Pode ser uma pessoa do time, uma liderança, amigos da área, mentores, comunidades ou pares de estudo.

O ponto é simples: se o seu medidor interno de competência está descalibrado, você precisa de sinais externos mais confiáveis.

Meça progresso

Outra ideia útil da palestra é transformar progresso em algo mais concreto.

Perguntar "eu sou bom?" costuma gerar uma resposta emocional.

Perguntar "o que eu consegui melhorar nos últimos três meses?" gera uma resposta mais observável.

Alguns exemplos:

• corrigi bugs que antes eu não conseguiria corrigir
• entreguei uma feature de ponta a ponta
• fiz meu primeiro code review
• expliquei um conceito para alguém
• escrevi um post técnico
• participei de uma entrevista
• contribuí com um projeto
• pedi ajuda mais cedo em vez de travar por dias

Nada disso precisa ser grandioso.

Progresso real quase sempre parece pequeno enquanto está acontecendo.

Treine olhar para os positivos

Para algumas pessoas, reconhecer pontos positivos é natural.

Para outras, precisa ser treino.

Uma prática simples é registrar pequenas vitórias. Não para inflar ego, mas para criar evidência.

Porque nos dias ruins, a memória fica seletiva.

Você pode manter uma lista de coisas que aprendeu, problemas que resolveu, feedbacks positivos que recebeu e situações difíceis que conseguiu atravessar.

Isso não elimina insegurança, mas ajuda a discutir com ela usando dados.

Cuidado com ambientes negativos

Ambientes técnicos podem reforçar muito a síndrome do impostor.

Toda comunidade tem pessoas que usam conhecimento como arma. Aquela pessoa que corrige tudo com desprezo, faz cara de surpresa quando alguém não sabe algo, interrompe com "na verdade..." o tempo todo ou transforma qualquer dúvida em prova de inferioridade.

Essas pessoas podem até ser inteligentes.

Mas não são boas fontes de dados sobre o seu valor.

Ao mesmo tempo, vale olhar para o próprio comportamento. A palestra menciona práticas que parecem pequenas, mas desgastam ambientes:

• surpresa fingida: "como assim você não sabe isso?"
• correções irrelevantes só para mostrar superioridade
• backseat driving enquanto outra pessoa está codando
• comentários sutis de sexismo, racismo, homofobia ou qualquer forma de exclusão

Diminuir esse tipo de ruído melhora a vida de todo mundo, especialmente de quem já está lutando contra insegurança.

Mate seus heróis

Uma das partes mais interessantes da palestra é a ideia de "matar seus heróis".

Não literalmente.

A ideia é parar de tratar pessoas experientes como seres mágicos que nasceram sabendo tudo.

Quando olhamos para uma pessoa referência na área, geralmente vemos o resultado final: palestras boas, código bom, livros, projetos, reputação.

Não vemos o caminho: código ruim, dúvidas, rejeições, bugs, medo, treino, anos de prática.

Transformar heróis em humanos ajuda a enxergar algo mais realista:

eles também começaram pequenos.

Eles também erraram.

Eles também têm inseguranças.

E você não precisa virar uma cópia deles para construir uma carreira boa.

Ajude outras pessoas

Uma forma poderosa de combater a síndrome do impostor é ajudar quem está começando.

Quando você explica algo para alguém, percebe que sabe mais do que achava. Quando vê uma pessoa iniciante se chamando de burra por não entender algo básico, talvez reconheça o mesmo padrão em si.

Isso cria empatia.

Também cria responsabilidade.

Se você é mentor, professor, liderança ou referência para alguém, o jeito como fala de si mesmo importa. Autodepreciação constante pode parecer humildade, mas também pode ensinar outras pessoas a se diminuírem.

Ser honesto sobre dificuldade é saudável.

Se destruir o tempo todo, não.

Finja até conseguir, mas com cuidado

Julie traz uma frase comum entre as pessoas entrevistadas para a palestra: "fake it until you make it".

Mas existe uma distinção importante.

Não é para mentir sobre habilidade técnica. Não coloque no currículo o que você não sabe. Não finja domínio de uma tecnologia crítica. Não assuma responsabilidade colocando outras pessoas em risco.

Aqui, "fake it" significa agir apesar da falta de confiança.

Enviar a proposta de palestra mesmo com medo.

Aplicar para a vaga mesmo sem ter 100% dos requisitos.

Publicar o texto mesmo achando que poderia estar melhor.

Fazer a pergunta mesmo com receio de parecer simples.

Às vezes a confiança vem depois da ação, não antes.

O ponto principal

Síndrome do impostor prospera no silêncio.

Quando ninguém fala sobre isso, cada pessoa acha que está sozinha. Acha que todo mundo entendeu a documentação de primeira. Que todo mundo programa sem travar. Que todo mundo sabe explicar arquitetura com clareza o tempo todo. Que só ela está improvisando.

Mas tecnologia é feita por pessoas.

Pessoas cansam, erram, aprendem, esquecem, pedem ajuda e tentam de novo.

O objetivo não é eliminar toda insegurança. Um pouco de dúvida pode até proteger contra arrogância.

O objetivo é impedir que a insegurança decida o tamanho da sua carreira.

Se você se reconheceu nesse texto, talvez o próximo passo seja pequeno:

conversar com alguém de confiança, registrar seus progressos, pedir feedback, publicar algo simples, aplicar para uma vaga, contribuir com um projeto ou ajudar alguém que está começando.

Não precisa enfrentar os monstros invisíveis sozinho.