"O que acontece numa sessão individual de 50 minutos (com o seu projeto na tela)"
"Antes, durante e depois: o formato da sessão individual da mentoria, minuto a minuto, e a folha de três linhas que você pode preparar hoje."
"Quem nunca estudou isso não sabe o que não sabe."
A frase apareceu na pesquisa deste blog falando de segurança, mas ela vale pro app inteiro. E ela explica por que post nenhum, nem este, resolve o seu caso sozinho: um texto responde as perguntas que você já sabe fazer. A pergunta que você não sabe que existe só aparece quando alguém olha o seu projeto e faz por você.
É pra isso que existe a sessão individual da Mentoria Dono do App. Já contei as três fases e os portões e a conta de horas da agenda. Este post é sobre os 50 minutos: o que acontece antes, durante e depois. É o formato, não um caso. A primeira turma ainda não existe, e eu não vou inventar aluno pra ilustrar.
Por que você não acha sozinho
Não é falta de esforço. Quem constrói com IA testa o que vê: o botão, a tela, o cadastro. O que dá problema costuma ser o que não aparece: a regra de acesso que deixa a conta B ler o dado da A, a chave guardada no lugar errado, o banco que mora numa conta que não é sua. Nada disso dá sintoma até o dia em que dá.
E isso não é coisa de iniciante. Em 2013, a Microsoft Research e a Universidade de Lugano estudaram a revisão de código, quando um programador olha a mudança do outro antes dela entrar. A conclusão: o motivo declarado é achar defeito, mas o que a revisão mais entrega é transferência de conhecimento, mais noção do que o time está fazendo e soluções alternativas pro mesmo problema. O estudo é com times de programadores profissionais, não com quem constrói sem ser dev, e não mede mentoria. Mas mostra uma coisa que serve aqui: até quem programa há anos precisa de outro par de olhos, e o ganho maior não é o erro achado. É o que você passa a enxergar sozinho depois.
Antes da sessão: a folha de três linhas
A sessão não começa no minuto um. Começa um dia antes, quando você me manda uma folha com três linhas:
- O que funciona hoje. Uma frase, do jeito que você conferiu. "Cliente se cadastra e marca horário; conferi em janela anônima ontem."
- O que quebrou ou te assusta. Com o que aparece na tela, não com o diagnóstico. "Depois que mudei o preço, o total do agendamento vem zerado."
- A decisão que você não consegue tomar sozinho. "Tiro do Lovable agora ou depois de ter os primeiros pagantes?"
Mais o link do repositório (a pasta do código guardada no GitHub) e os seus "não" no checklist "Protótipo ou produto?". Com isso eu chego na sessão já tendo aberto o projeto. Os 50 minutos não se gastam em "me mostra onde fica".
Durante: os 50 minutos, em três blocos
Primeiros 10 minutos: o app rodando na sua tela. Você compartilha a tela e usa o app como um cliente usaria. Eu não toco no teclado. Quero ver onde você clica, onde hesita, o que você conferiu e o que pulou. Metade das perguntas que você não sabia fazer aparece aqui.
Os 25 do meio: arquitetura e o que está errado. Arquitetura, aqui, quer dizer o desenho do app: onde mora o dado, quem pode ler o quê, o que depende do quê. Abrimos o código e o banco juntos. Eu aponto o que está errado em ordem de estrago, não em ordem de aparição: a regra de acesso aberta vem antes do botão desalinhado, mesmo que o botão te incomode mais. E cada coisa que eu aponto vem com o jeito de você conferir sozinho depois, porque o objetivo é você enxergar sem mim.
Últimos 15: o que fazer até a próxima. Uma coisa, não três. Escrita, com a frase de conferência ("vou saber que está pronto quando, fazendo X, eu vir Y") e com os itens do checklist que devem virar "sim" até lá. Se ficar tempo, é aqui que se decide o que precisa de um dev de verdade e o que não precisa.
Depois: duas semanas
São seis sessões, uma a cada duas semanas, durante as 12 semanas. O intervalo é de propósito: duas semanas é o tempo de executar a uma coisa combinada, travar, perguntar no grupo, destravar e conferir. A sessão seguinte começa pela frase de conferência da anterior. Passou? Próxima. Não passou? É por ela que a gente começa, não pelo assunto novo.
Por que são 15 vagas
Faz a conta comigo: seis sessões por pessoa, 15 pessoas, dá 90 sessões em 12 semanas, umas sete e meia por semana, fora o encontro em grupo e o WhatsApp. Cabe na minha agenda. O dobro não cabe. O teto de vagas não é técnica de venda, é a quantidade de horas que eu tenho pra olhar projeto dos outros com atenção.
O que você faz hoje, com ou sem mentoria
Escreva a folha de três linhas do seu app. Agora, antes de fechar esta página.
Ela serve pra qualquer pessoa que for te ajudar: o amigo dev, o freelancer, o suporte da plataforma. Quem recebe "o app não funciona" gasta a primeira meia hora descobrindo o que você quer dizer. Quem recebe as três linhas começa pela resposta. E tem um efeito colateral que eu vejo toda vez: escrever a linha 3 já resolve metade das decisões, porque a pergunta que você não consegue escrever ainda não é uma decisão, é uma ansiedade.
A folha te deixa pronto pra ser ajudado. O que ela não faz é ver o que você não sabe que não sabe: isso precisa de alguém olhando o seu projeto, na ordem das fases, conferindo cada "sim" antes de avançar.
Fontes
- Alberto Bacchelli e Christian Bird, "Expectations, Outcomes, and Challenges of Modern Code Review", ICSE 2013, Microsoft Research e Universidade de Lugano (o motivo declarado é achar defeito; o que a revisão mais entrega é transferência de conhecimento, noção do que o time faz e soluções alternativas): https://2013.icse-conferences.org/content/expectations-outcomes-and-challenges-modern-code-review.html