Esta é a Parte 1 de 3 desta série sobre superar a síndrome do impostor criando um app completo.

• Parte 1 (este post): A decisão e o planejamento inicial
• Parte 2 (em breve): Implementação e desenvolvimento
• Parte 3 (em breve): Lições aprendidas e resultados

Depois do meu último emprego na ilha de Man, tive um período complicado no qual experienciei o fatídico burnout.

Um período sombrio que até então eu não tinha dado a devida importância, seja como for, o caminho para sair e se restaurar é longo e assustador.

Mental Health já é um assunto global, bem desenvolvido nas redes então vou poupar vocês dos detalhes. Mas sim, o ambiente de trabalho tem uma gorda fatia na saúde do funcionário.

Dito isso, vamos ao post e onde tudo começou.

Dezembro chegou e eu estava em casa. Desempregado. Com ansiedade atacada. Estudando ISTQB porque “certificação pode ajudar nas entrevistas”. Criando flashcards no Anki. Tentando manter uma rotina.

E aquela voz não parava:

Você pula de galho em galho, nunca conseguiu explicar pra família o que faz, nunca finaliza um projeto

Eu sei que não é verdade.

Racionalmente, eu sei.

Tenho 10 anos de experiência. Já fui desenvolvedor backend. Já fui arquiteto de sistemas. Trabalhei com várias e várias linguagens, várias empresas incríveis. Mas racionalmente saber não faz a voz calar.

Por que tinha uma parte que ERA verdade:

Você nunca entregou um portfólio, um produto ou app teu

E foi isso que me quebrou. Não o desemprego. Não a ansiedade. Foi perceber que eu tinha medo de tentar ou até mesmo ter que aprender coisas novas.

Sim, aprender coisas novas pois, qualquer pessoa depois de certa idade quer gerenciar ou aprimorar o que já sabe, a famosa especialização.

A Decisão

3 da manhã. Não conseguia dormir. Ansiedade alta. Abrindo e fechando LinkedIn. Vendo vaga atrás de vaga. Uma grande maioria pedindo “full-stack”. Todas pedindo coisas que eu não tinha no currículo.

Pensei: “Eu sei backend. Eu sei criar APIs, modelar bancos de dados, arquitetar sistemas, testar sistemas. Por que eu não consigo criar um frontend simples?”

E a resposta foi bem simples e cruel: porque eu nunca tentei de verdade.

Tinha medo de tentar e confirmar que eu era impostor.

Então às 3h17 da manhã, com minha pantufa do snorlax e ansiedade nas alturas, tomei uma decisão:

Vou criar um aplicativo completo. Sozinho. Do zero. Frontend que eu não sei. Backend que eu conheço. Tudo integrado.

E se eu falhasse? Pelo menos teria tentado.

O tema? Trânsito, eu precisava aprender a dirigir na ilha de Man, tirar minha habilitação e para isso precisava fazer o teste teórico. Ora, eu crio algo para o portfólio e de quebra estudo para o teste.

Um projeto com mais ganhos que o esperado.

O Plano: Como Fazer a IA Trabalhar Pra Mim?

Aqui é onde a história fica interessante.

Eu não acordei e pedi pro ChatGPT “faz um app pra mim”. Isso não funciona. Nunca funcionou. Nunca vai funcionar (Talvez vá, não sei). E todo mundo que tentou sabe onde isso vai dar.

Por outro lado eu tenho um bloqueio no que tange a usar IA para tudo, a nova serotonina em formato de tokens que resolve todos os problemas que lhe é solicitado ainda me assusta.

Ainda assim acredito que podemos comparar o uso de IA ao uso de um carro, pode parecer estranho de se aprender, você nunca terá 100% de controle, mas ainda assim pode manipular e usar para tarefas que sozinho você não conseguiria, no caso do carro, pode ser percorrer vários KM com carga, no caso da IA, pode ser escrever códigos repetitivos ou revisar o que foi escrito. Além de planejar é claro, o que têm feito cada vez melhor.

Primeira Coisa: Admitir o Que Eu Não Sabia

Abri um documento e escrevi:

O QUE EU SEI:

• Backend: C#, .NET, APIs REST, Entity Framework, PostgreSQL, NodeJs, Typescript
• DevOps: Azure DevOps, CI/CD, Docker, Git, Github
• Testes: Playwright, ReqnRoll, xUnit, NUnit, Jest
• Arquitetura: Clean Architecture, BDD, SOLID

O QUE EU NÃO SEI:

• Frontend: React Native, Expo, componentes, navegação
• Mobile: Como estruturar um app mobile
• Integração: Como fazer frontend chamar meu backend
• UI/UX: Como criar interfaces que não pareçam de 2005

O QUE EU PRECISO APRENDER:

• O básico de React Native (suficiente pra não me perder)
• Como criar componentes
• Como fazer navegação entre telas
• Como integrar com API

Segunda Coisa: Estudar (Mas Não Muito)

Eu não ia virar especialista em React Native em uma semana ou duas. Impossível.

Mas eu podia entender o suficiente pra saber o que perguntar.

Fui no YouTube. Traversy Media. “React Native Crash Course”. 3 horas de vídeo.

Assisti em 1.5x de velocidade. Pausando. Tomando notas. Não pra decorar sintaxe. Pra entender:

• Como um app React Native se estrutura
• O que são componentes
• Como funciona o state
• O que é um hook
• Como funciona navegação
• Como fazer requisições HTTP

Fiz bastante paralelo com o que eu sabia de outras tecnologias, seja Typescript que eu já sabia e ajudou muito no processo, seja orientação a objetos para focar em interfaces corretas.

Não saí sabendo fazer. Saí sabendo como fazer perguntas inteligentes.

E isso fez toda diferença.

Terceira Coisa: Conversar com a IA (De Verdade)

Aqui é o pulo do gato.

Não foi:

“AI, cria um app pra mim”

Como diz o coelho, se você não sabe onde quer chegar qualquer caminho lhe serve.

Foi algo neste sentido:

• Instruções para pair programming e documentação.
• Toda a especificação técnica que criei
• Meu nível de conhecimento em cada área
• As dúvidas específicas que tinha
• O que eu esperava aprender no processo

A resposta não foi código. Foi um plano de ação com datas, o que aprender, o que procurar, algumas coisas desatualizadas, mas um ponto de partida

A Jornada (E o Que Ninguém Te Conta)

Dia 1: Backend (A Parte Que Eu Conhecia)

Comecei pelo que eu sabia: backend.

Ao contrário do que eu pensei que faria, criar um backend em .NET 8, clean arch e tudo mais, eu decidi pelo simples, Supabase, o motivo é simples: Manter a mesma linguagem já que sou dev único.

Não vou entrar muito em detalhes, mas o supabase me permite criar toda a estrutura de backend em serverless, algo que eu já tinha trabalhado no passado e tinha conforto em lidar.

E mesmo na minha zona de conforto, tive momentos de “caralho, será que tá certo?”

Iniciando com o front end comecei criando autenticação, seguindo tutoriais, perguntava para AI se aquela implementação fazia sentido e o que poderia melhorar.

Utilizei um outro projeto de exemplo (Keycloak, vou fazer post dele depois)

Comecei a utilizar MCPs para alimentar a IA com informações do projeto local, o mesmo com context7, sequential thinking, memory e afins.

A AI que eu usei foi o Claude, caso esteja se perguntando.

Em momentos de pair programming, muitas vezes eu criava um componente, revisava com o claude e ele ficaria responsável por outras implementações enquanto eu trabalhava em outras partes como as requests para o backend, ou interfaces para transição de dados. e de tempos em tempos algumas perguntas eram feitas:

• “Por que essa abordagem?”
• “Quais as alternativas?”
• “Como isso escala?”
• “Como eu testaria isso?”

Não era só aceitar código. Era entender código.

E aqui vai um pulo do gato e parte mais importante sobre codar com IA, como mencionei lá em cima: SEROTONINA.

É bom demais ver o código funcionando e rodando, a IA assim que termina já te oferece uma nova feature que você nem tinha pensado e como você segura o dedo do enter?

Fica com essa pra pensar.

Continua na Parte 2, onde vou detalhar o processo de implementação, os desafios técnicos que enfrentei e como usei IA de forma efetiva como pair programmer.

Fique ligado!