Como Aprender Com Aquele Senior Que “Simplesmente Sabe”
Ajude o seu senior a te ajudar
Recebi essa pergunta no Instagram várias vezes: “O que fazer quando começo na empresa?”
Boa pergunta, e por isso decidi escrever esta newsletter pra gente ir mais a fundo.
A maioria das respostas que tu vais ouvir são tipo “aprende com os seniors” ou “observa como eles trabalham”.
Okay. Mas como?
Aquele senior olha pro pedido de um produto novo e diz “isso vai dar problema”. Ele não consegue explicar exatamente por quê. Ele vê uma proposta de feature e “sente” que tem algo errado. Ele revisa teu plano de implementação e já sabe onde vai quebrar antes mesmo de começar.
Tu perguntas “como fizeste isso?”, ele responde: “ah, experiência.”
Frustrante pra c$##$%, né?
O Problema de Saber Um Pouco de Tudo
Eu sou medíocre em muitas coisas. Não no sentido de ser ruim, eu acho que dá pro gasto. Mas no sentido de não ser especialista em nada.
Toco violão. Razoavelmente bem. Sei tocar algumas músicas, toco uns dedilhados. Mas não sou aquele violonista que tu chama quando quer impressionar alguém.
Toco pandeiro. Dizer que eu sei tocar é demais, mas o som fica aceitável pelo menos. Mas não sou o cara que outros percussionistas param pra assistir.
Tô aprendendo japonês. Consigo ler, formar frases simples, entendo conversas básicas. Mas conversa fluente? Ainda não.
Tô aprendendo salsa. Danço bem o suficiente pra me divertir numa festa, faço as transições básicas, acompanho o ritmo. Mas não sou aquele dançarino que chama atenção na pista.
Espanhol? Morei em Madri um tempo e consigo enrolar, mas também não me sinto em um nível avançado.
E até na área de dados - minha profissão - eu sei fazer muita coisa mas não me sinto expert em nada. Talvez da área de negócios?
Sabe o que todos esses exemplos têm em comum?
Eu tento aprender muita coisa ao mesmo tempo. Espalho minha atenção. Pratico cada coisa um pouquinho. E fico competente em várias, mas expert em nenhuma.
É o oposto de como verdadeiros especialistas se formam.
E essa questão me fascina. Por isso tô lendo um livro pesadíssimo chamado Accelerated Expertise - porque será que existe uma maneira de ganhar expertise mais rápido? De construir conhecimento profundo em vez de superficial?
Curto o assunto por si só. Mas mais importante: quero acelerar como os Data Creators aprendem e crescem nas suas carreiras. Se eu conseguir entender como expertise se forma, posso ajudar vocês a não ficarem espalhando atenção como eu faço. Unir o útil ao agradável.
De acordo com algumas teorias, sim. Existe uma maneira de acelerar expertise.
E tem a ver com onde tu focas tua atenção e como tu extrais conhecimento de quem já é expert.
O problema não é má vontade do senior. O que tá acontecendo na cabeça dele não é processamento lógico que dá pra escrever num tutorial. É reconhecimento de padrões operando em memória implícita.
Como eu escrevi antes: o objetivo de um time de dados é gerar conhecimento. Só que nem todo conhecimento é explícito. Existe conhecimento tácito - aquele que é impossível de capturar só com palavras.
O Problema Com “Só Aprende Observando”
Tem uma história de enfermeiras em UTIs neonatais que conseguiam “simplesmente saber” quando um bebê prematuro estava desenvolvendo sepse, horas antes dos médicos perceberem.
Quando perguntavam como sabiam: “intuição” e “experiência”.
Parece bullshit, né?
Mas uma pesquisadora passou meses entrevistando essas enfermeiras usando técnicas específicas de análise cognitiva. E descobriu que elas estavam usando pistas específicas, só que essas pistas eram processadas tão automaticamente que as enfermeiras nem tinham consciência delas.
Respiração superficial. Pressão ligeiramente elevada. Mudança sutil na cor da pele. Nenhuma sozinha era diagnóstico. Mas o conjunto ativava um padrão.
Algumas dessas pistas nem estavam na literatura médica. As enfermeiras tinham construído expertise através de centenas de casos. E essa expertise era tácita.
Isso acontece em data science também. Aquele senior que olha pro teu plano e “sente” que vai dar problema? Ele já viu esse padrão dar merda antes. Várias vezes. A memória dele reconhece automaticamente.
Se tu souberes fazer as perguntas certas, tu consegues mapear como ele pensa.
Como Experts Realmente Pensam
Pesquisadores que estudam tomada de decisão em ambientes reais passaram décadas observando como especialistas resolvem problemas no mundo real - bombeiros, pilotos, médicos de emergência, militares em combate.
E descobriram algo que vai contra o que eu pensava: experts não comparam opções.
Lê de novo. Aquele senior não faz lista de prós e contras. Ele não avalia múltiplas alternativas. Ele faz outra coisa.
O modelo que emergiu dessas pesquisas funciona assim:
Quando um expert vê um problema, o cérebro dele:
Reconhece a situação - compara com protótipos na memória implícita
Gera quatro coisas automaticamente:
Expectativas do que vai acontecer
Objetivos prioritários agora
Pistas relevantes pra prestar atenção
Ações possíveis a tomar
Tudo isso em segundos. Em memória implícita. Por isso ele não consegue explicar direito.
Exemplo
Time de Produto vem com um pedido pra criar uma feature nova. Um novo tipo de evento que usuários podem fazer. Precisa configurar no banco, ajustar dashboards, atualizar a pipeline.
Tu olhas e pensas: “beleza, vou criar as tabelas necessárias e seguir o padrão que já existe.”
O senior olha cinco segundos e diz: “do jeito que tá desenhado, isso vai virar uma bomba em três meses.”
O que aconteceu na cabeça dele?
Reconheceu o padrão: novo produto sem mapeamento claro de dependências, sem pensar em como rastrear no warehouse, sem discutir impacto nos sistemas existentes
Expectativa: em produção, vai criar inconsistências nos dados, dashboards vão começar a mostrar números estranhos, vamos descobrir que faltou logar eventos críticos
Objetivo: prevenir débito técnico antes de virar incêndio que vai consumir semanas de refactoring
Pistas: ele notou que ninguém discutiu schema, como eventos vão ser estruturados, que foreign keys precisam existir, como isso se integra com o data model atual
Ação: mapear todas as dependências primeiro, desenhar estrutura de dados considerando queries futuras, validar com stakeholders o que realmente precisa ser rastreado
Um júnior olhando o mesmo pedido? Não sente nada. Só vê “criar feature X”. Porque não tem o protótipo de “padrões que levam a débito técnico em dados”.
O Gargalo É Teu Professor
Toda organização tem um bottleneck. O ponto que limita tudo. Onde as coisas travam. Onde os incêndios acontecem.
(para mais leia sobre TOC - Theory of Constraints)
Os conhecimentos mais valiosos estão exatamente ali.
Pensando bem: se o gargalo da empresa é a qualidade dos dados que vive gerando inconsistências, quem tem os protótipos mais densos? O senior que investiga esses problemas toda semana.
Se o bottleneck é o tempo que leva pra colocar modelos em produção, quem tem expertise em MLOps? O cara que já fez isso centenas de vezes e já viu tudo que pode dar errado.
O gargalo não é só um problema. É um sinal: “aqui tem conhecimento tácito crítico que poucos dominam.”
Por Que Isso Importa
A maioria dos juniors pega tickets aleatórios do backlog. Um dia mexe em visualização. Outro dia faz um ETL simples. Depois uma análise exploratória.
Ou querem fazer algo interessante pra eles...
Aprendendo no modo difuso. Espalhando atenção por cem áreas diferentes. Construindo conhecimentos superficiais em tudo.
O senior que “simplesmente sabe”? Ele passou anos resolvendo o mesmo tipo de problema no gargalo. Ele tem vários modelos mentais sobre aquele domínio específico. Por isso reconhece padrões instantaneamente.
Identifica o bottleneck da organização e cola nele.
Se a empresa vive com problema de qualidade de dados? Vai pro time que cuida disso. Se o gargalo é governança e compliance? É lá que tu aprendes mais rápido. Se é performance de sistemas em produção? Cola nesse problema.
Por quê? Porque é onde:
Os problemas são mais difíceis (forçando expansão de protótipos)
O feedback é imediato (tu vês se funcionou ou não)
Os experts estão focados (eles passam tempo lá)
O impacto é visível (todo mundo tá prestando atenção)
Deming já falava: conhecimento (e gestão) é sobre predição, não sobre verdades abstratas.
Tu só constróis modelos preditivos reais quando estás trabalhando onde tem problemas. Parece óbvio, mas precisa ser dito. Porque é o único lugar onde experimentação gera aprendizado válido.
Mexer em coisa que não é bottleneck? Tu podes estar “melhorando”, mas não tá construindo modelos mentais que importam.
Mapear Processos É Reconhecer Gargalos
Quando tu mapeia processos na tua empresa, o que tu tá realmente fazendo é procurar as restrições.
A maioria das pessoas aprende a desenhar fluxogramas. Swimlanes aqui, losangos de decisão ali. Medem tudo. Documentam cada passo.
Mas experts em mapear processos não fazem isso. Eles olham pro processo por 60 segundos e dizem: “teu gargalo tá aqui, vai se mover pra cá depois, e tu estás otimizando as coisas erradas.”
Como?
Eles têm muitos padrões de bottleneck na cabeça:
Bottleneck de coordenação (muitos handoffs entre times)
Bottleneck de capacidade (um ponto específico não aguenta o volume)
Bottleneck de política (regras artificiais criando o limite)
Quando eles veem um processo, não analisam. Reconhecem.
O cérebro deles faz exatamente as mesmas quatro operações:
Pistas: filas se formando, tempos de espera, utilização alta antes/depois de certos passos
Expectativas: “quando eu vejo esse padrão, a restrição vai se mover pra X a seguir”
Objetivos: focar esforço na restrição, não em otimização local
Ações: qual padrão de intervenção usar (adicionar capacidade, reduzir variação, alinhamento, eliminar desperdício)
Um novato tenta mapear tudo. O expert sabe o que ignorar. Porque os modelos mentais dele dizem exatamente onde tá a alavancagem.
Como Isso Se Conecta Com Aprender No Gargalo
Quando tu tá começando, tu não tens esse entendimento das restrições. Tu olhas pro processo e vês... um monte de caixinhas conectadas por setas.
Mas se tu trabalhas no bottleneck da organização por alguns meses, tu começas a entender as coisas.
Tu começas a ver padrões. Tu notas quando uma fila tá se formando. Tu prevês onde o próximo problema vai aparecer. Tu entendes por que aquela “solução” não vai funcionar.
Tu tá construindo as mesmas conexões que o expert tem.
E quando tu precisas mapear um processo novo, seja pra documentar, seja pra melhorar, tu não precisa desenhar tudo em detalhes absurdos. Tu vês o bottleneck instantaneamente.
Tipo assim: imagina que tu passaste seis meses trabalhando no problema de qualidade de dados. Tu viste dezenas de casos onde dados ficaram inconsistentes. Tu aprendeste os padrões.
Agora alguém te pede pra mapear como funciona a ingestão de dados de uma fonte nova. Tu olhas pro fluxo proposto e imediatamente vês:
“Não tem validação aqui, vai gerar lixo”
“Esse passo vai ser o bottleneck quando o volume crescer”
“Faltou pensar em idempotência, vai duplicar dados”
Tu não analisaste. Tu reconheceste.
Isso é expertise em mapear processos. E tu só constróis isso trabalhando nas restrições reais da organização.
Indo no Gemba..
As Quatro Perguntas
Quando um senior resolve algo rápido ou dá um feedback que tu não entendes completamente, não perguntes só “como fizeste isso?”
Faz essas quatro perguntas:
1. “Que pistas tu notaste primeiro?”
Isso mapeia o que chamou atenção dele e que tu não viste.
Exemplo:
JR: “Como tu soubeste que esse novo produto ia dar problema nos dados?”
Senior: “Vi que vocês não discutiram chave primária, não mapearam relacionamentos com tabelas existentes, e não pensaram em como vão fazer join depois.”
Aí tu anota e já põe nos teus padrões pra observar.
2. “O que esperavas que acontecesse?”
Isso extrai as expectativas - o modelo mental dele sobre consequências.
JR: “Por que isso seria problema?”
Senior: “Em três meses quando precisarem de um relatório cruzando esse produto com outros dados, vocês vão descobrir que não tem como fazer o join. Ou pior, vão fazer um join errado que vai gerar números incorretos e ninguém vai perceber até causar um problema grande.”
Entender a causa e efeito é super importante.
3. “Quais eram tuas prioridades aqui?”
Isso revela os objetivos - como ele prioriza entre múltiplas coisas.
JR: “Deveria desenhar toda a estrutura antes ou podia começar e iterar?”
Senior: “Estrutura de dados não é código que tu refatoras fácil. Uma vez que tem dados em produção, mudanças viram migrações complexas. Gasta duas horas pensando agora pra economizar duas semanas depois.”
Entender quando é melhor gastar 2 horas pensando pra economizar 1 semana apagando incêndio.
4. “Que outras ações tu consideraste?”
Isso mostra as alternativas - as opções que passaram pela cabeça dele.
JR: “Tinha outra forma de estruturar isso?”
Senior: “Podia normalizar mais e ter tabelas separadas pro histórico, ou desnormalizar pra performance mas aceitar redundância. Depende se tu vais consultar mais por agregações ou por eventos individuais.”
Agora tu sabes que existem trade-offs. E começas a construir teu próprio repertório de quando usar cada abordagem.
(Exemplos criados com a ajuda da IA)
O Que Fazer Quando Tu Começas
Voltando pra pergunta original: “o que fazer quando começo na empresa?”
Três coisas que importam:
Primeiro: acha o gargalo, ou seja, os problemas!
Onde os projetos travam? Onde os incêndios acontecem? O que limita o output do time?
Pergunta pra três pessoas diferentes. Compara as respostas. Tu vais começar a ver o padrão.
Se ninguém souber responder com clareza, isso já é um sinal. Ninguém mapeou o processo direito. Ninguém sabe onde tá o problema de verdade.
Segundo: identifica quem tem os modelos mentais pra resolver
Quem resolve esses problemas mais rápido? Quem os outros consultam quando isso quebra? Quem “simplesmente sabe” o que tá errado?
Presta atenção em como eles falam sobre o processo. Eles usam linguagem específica? Eles mencionam padrões que tu não conheces?
Essas são as conexões que tu precisas construir.
Terceiro: trabalha nas restrições e usa as quatro perguntas
Cada vez que tu enfrentas um problema:
Tenta resolver sozinho
Anota: que pistas notaste? Que esperavas que acontecesse? Que ações consideraste?
Mostra pro senior
Faz as quatro perguntas
Compara os quatro elementos
A diferença entre o que tu pensaste e o que ele pensou? Esse é o gap que tu precisas fechar.
Aos poucos, tu vais começar a entender como o senior faz as conexões na cabeça dele.
E de quebra teu Senior vai te amar, pois quando alguém traz perguntas deste nível mostra um nível de proatividade bem raro.
A Biblioteca de Padrões
Um expert em arquitetura de dados não sabe “tudo sobre dados”. Ele tem 500 modelos mentais sobre padrões de problema:
“Quando vejo produto novo + sem discussão de schema + pressão pra entregar rápido → vai gerar débito técnico que vai custar 10x mais depois”
“Quando sistema começa a ficar lento + foi adicionado um campo novo + sem índice → alguém esqueceu de indexar e agora tá fazendo full table scan”
“Quando números não batem entre dashboards + teve deploy recente + sem rollback → mudança quebrou alguma coisa na estrutura dos dados”
Cada um desses é um padrão. Pistas + expectativas + objetivos + ações.
Tu só constróis essa biblioteca trabalhando onde dói e perguntando muito.
Se tu espalhas tua atenção por mil áreas diferentes, tu tens 10 modelos em cada uma. Superficial em tudo.
É a mesma razão que não dá pra copiar as práticas da Toyota. Eles têm 50 anos de padrões construídos trabalhando nas restrições deles, na ordem que apareceram. Tu não podes pular pra lição 500 sem ter feito as lições 1-499.
Tu Tens Que Ajudar Ele a Te Ajudar
Identifica onde a expertise crítica está. Usa as quatro perguntas pra mapear como os experts pensam. Constrói os modelos mentais através de experimentação focada na restrição.
(se fores ver, isso também o Kaizen com outro nome..)
Ele quer te ensinar. Mas ele não sabe como verbalizar o que tá acontecendo na cabeça dele. Quando tu fazes as quatro perguntas, tu tá dando estrutura pro conhecimento tácito dele virar explícito.
Próxima vez que um senior te der um feedback que tu não entendes completamente? Não aceites “é experiência” como resposta.
Faz as perguntas. Mapeia os modelos mentais dele. E se possível, faz isso trabalhando na restrição da organização.
É assim que tu transformas “observar seniors” em um processo sistemático de construção de expertise onde ela realmente importa.
Heitor Sasaki