Por Que Decidi Aprender Programação Depois de 15 Anos de Gestão

E O Que Isso Está Mudando Na Minha Forma de Pensar

Estava escrevendo documentação técnica no VS Code para o projeto Kitdot, quando tive um clique. Não era a primeira vez que abria o editor. Já havia feito ajustes pontuais em markdown, editado alguns arquivos de configuração. Mas dessa vez era diferente. Estava documentando o Kitdot, um projeto da WEB3DEV, e pela primeira vez não estava apenas usando uma ferramenta de desenvolvimento. Estava habitando o ambiente onde código nasce.

Foi um momento estranho de consciência. Ali, cercada por syntax highlighting, extensões, terminal integrado, percebi que estava do lado de fora olhando para dentro. Conhecia profundamente soft skills, gestão, sistemas organizacionais. Mas não entendia realmente como as ferramentas que meus times usavam funcionavam. Não era incapacidade. Era escolha. Escolha que fazia cada vez menos sentido.

Tenho quinze anos de carreira construída em habilidades humanas. Gestão de comunidades, coordenação de projetos complexos, facilitação, comunicação estratégica. Nos últimos quatro anos mergulhei em Web3, aprendi sobre squads, metodologias ágeis, Shape Up, Scrum. Trabalhei com desenvolvedores brilhantes em hackathons, startups, projetos de código aberto. Sempre do lado da gestão, sempre do lado das pessoas.

E isso funcionou bem. Mas estava começando a sentir um limite invisível.

O Limite Invisível Entre Gestão e Implementação

Esse limite aparece em momentos específicos. Quando uma equipe técnica explica por que determinada feature vai levar três sprints e você suspeita que talvez estejam superestimando, mas não tem como avaliar criticamente. Quando você precisa escolher entre duas arquiteturas propostas e depende completamente da capacidade de comunicação de quem está propondo, não da sua própria análise. Quando quer otimizar processos na plataforma da sua organização mas precisa traduzir sua visão para alguém implementar, perdendo nuances no caminho.

Não é questão de confiança. É questão de fluência. Um gestor que não entende o trabalho do time que coordena opera com informação filtrada e traduzida. Às vezes a tradução é boa. Às vezes não. E você só descobre quando já é tarde.

No mercado de tecnologia, esse limite tem peso extra. Coordeno comunidades em Web3, trabalho com desenvolvedores, facilito a construção de produtos digitais. Quanto mais imersa nesse ecossistema, mais óbvio ficava que precisava não apenas entender conceitos de programação teoricamente, mas pensar como programadora. Não para substituir desenvolvedores, mas para ser uma gestora tecnicamente fluente.

Por Que Agora, Por Que Sim

A decisão veio gradualmente, mas a ação demorou. Faltava tempo. Faltava disciplina. E tinha uma voz interna questionando se fazia sentido aprender algo tão técnico depois de duas décadas focada em outro tipo de expertise.

A resposta veio quando reformulei a pergunta. Não era “devo aprender programação?” mas “o que tenho a perder me tornando mais técnica?” A resposta foi: nada. E muito a ganhar.

Comecei o curso.dev do Filipe Deschamps. Escolhi desenvolvimento web porque é a base do que construímos na WEB3DEV e porque queria entender desde os fundamentos. Não estou fazendo um bootcamp intensivo para trocar de carreira. Estou aprendendo de forma sustentável, integrando com meu trabalho atual.

Tenho projetos concretos em mente. Quero otimizar plataformas que usamos na WEB3DEV. Quero poder avaliar tecnicamente propostas de ferramentas e processos. Quero conversar com desenvolvedores sem precisar que simplifiquem demais para mim. Quero escrever especificações técnicas melhores. E sim, quero eventualmente implementar algumas coisas eu mesma.

O Que Já Está Mudando

Ainda estou no início da jornada. Não posso compartilhar anos de experiência porque não os tenho. Mas já posso compartilhar mudanças concretas na forma de pensar.

Primeiro: precisão importa de formas não óbvias. Em gestão e comunicação, você pode ser aproximado. “Vamos fazer isso na próxima semana” funciona. Em código, aproximações quebram sistemas. Um ponto e vírgula no lugar errado, uma variável com nome ligeiramente diferente, uma função chamada na ordem errada. Tudo importa. Essa disciplina de precisão está vazando para como penso sobre processos. Ambiguidade tolerada em comunicação gera bugs em sistemas humanos também.

Segundo: abstrações têm custo. Aprendi sobre funções, componentes, módulos. Formas de abstrair complexidade para reusar código. Mas cada abstração adiciona uma camada entre intenção e implementação. Abstrações boas tornam sistemas mais manuteníveis. Abstrações ruins escondem problemas. Comecei a ver isso em estruturas organizacionais também. Quantas camadas de abstração existem entre decisão estratégica e execução? Cada camada ajuda ou dificulta?

Terceiro: debugging é metodologia de pensamento. Quando código não funciona, você não chuta soluções aleatórias. Você isola o problema, testa hipóteses, verifica pressupostos, elimina possibilidades sistematicamente. Percebi que muito da gestão de crises organizacionais é debugging disfarçado. E muitas vezes fazemos errado porque não pensamos metodicamente sobre onde o sistema está quebrando.

Quarto: documentação é pensamento tornado visível. Escrever boa documentação técnica requer clareza sobre o que o código faz, por que decisões foram tomadas, como partes se conectam. É explicar seu raciocínio para outro humano (ou para você mesma daqui seis meses). Isso conecta diretamente com algo que aprendi trabalhando com métodos ágeis e Shape Up: sistemas só funcionam bem quando há clareza compartilhada sobre o que estamos construindo e por quê.

Soft Skills + Hard Skills: O Que Muda

Passei anos desenvolvendo habilidades relacionais, comunicação, facilitação, design de processos. Essas habilidades continuam sendo minha base. Mas adicionar capacidade técnica não está substituindo o que construí. Está multiplicando.

Quando você entende tanto as dinâmicas humanas quanto as restrições técnicas, consegue fazer pontes que outros não fazem. Consegue desenhar processos que respeitam ambas as realidades. Consegue comunicar em dois registros: técnico quando necessário, humano sempre.

Mulheres em tech enfrentam um padrão recorrente: somos empurradas para “soft skills” e depois nossa autoridade técnica é questionada. Muitas de nós desenvolvemos expertise profunda em gestão, comunicação, pessoas. E depois descobrimos que esse conhecimento é simultaneamente essencial e desvalorizado. A resposta não deveria ser abandonar soft skills para provar competência técnica. A resposta é adicionar competência técnica sem perder o que já dominamos.

O Caminho do Meio

Estou no meio do caminho. Já passei do ponto onde tudo é completamente estranho, mas ainda longe do ponto onde sinto fluência. É um espaço desconfortável e produtivo.

Vou continuar aprendendo. Vou implementar os projetos que planejei para WEB3DEV. Vou errar bastante. Vou perguntar coisas óbvias para desenvolvedores mais experientes. E vou documentar o processo, porque acredito que aprender em público gera valor para quem está em jornadas similares.

Se você está em tecnologia mas não programa, provavelmente já sentiu esse limite invisível. Se está considerando aprender, minha experiência até agora diz: vale a pena, mesmo (talvez especialmente) se você já tem anos de carreira em outras áreas. Suas habilidades existentes não desaparecem quando você adiciona programação. Elas se expandem.

O campo de estudo que mais me fascina são sistemas complexos, e tenho compartilhado essas explorações em português porque sinto falta desse tipo de conteúdo no nosso idioma. Aprender a programar está se revelando mais uma lente para entender sistemas. Dessa vez, sistemas que humanos constroem para coordenar máquinas que coordenam outros sistemas. E no centro disso tudo, sempre, estão pessoas tentando trabalhar juntas de formas que funcionem.

Esta é uma Era de hard skills para mim. Mas não porque soft skills sejam menos importantes. Porque a combinação das duas é o que realmente transforma como você navega em espaços tecnológicos complexos.