 |
| Bellacosa Mainframe e o dunning kruger effect |
☕ Um Café no Bellacosa Mainframe
Dunning-Kruger Effect: Doctor Who, COBOL e o Dia em que Três Meses de Experiência Pareciam Mais que Trinta Anos
Uma viagem pela TARDIS dos incidentes para entender por que pouco conhecimento pode produzir muita confiança — enquanto aprender mais frequentemente nos ensina exatamente o tamanho daquilo que ainda não sabemos
09:12.
Segunda-feira.
Café quente.
Produção tranquila.
Talvez tranquila demais.
Nosso jovem programador COBOL havia acabado de completar alguns meses trabalhando com mainframe.
Já conhecia:
IDENTIFICATION DIVISION
ENVIRONMENT DIVISION
DATA DIVISION
PROCEDURE DIVISION
Sabia compilar.
Sabia executar job.
Já tinha resolvido:
S0C7.
S0C4.
Dataset not found.
Um JCL quebrado.
Um SQLCODE -811.
Sentia-se bem.
Muito bem.
Talvez...
bem demais.
Na reunião, um especialista diz:
— Precisamos revisar cuidadosamente essa alteração porque ela mexe em restart, checkpoint e atualização de três arquivos VSAM.
Nosso jovem responde:
— Mas não parece complicado.
O especialista levanta os olhos.
— Não?
— É só ler, alterar e gravar.
Silêncio.
Um DBA olha para o teto.
O operador bebe café lentamente.
O especialista pergunta:
— E se o job cair depois da atualização do primeiro arquivo e antes do segundo?
— Restartamos.
— De onde?
Nosso jovem fica alguns segundos em silêncio.
— Do início?
— E as atualizações já feitas?
— Hmmm...
O especialista continua:
— E se houver commit intermediário?
Silêncio.
— E se o registro no segundo arquivo não existir?
Silêncio.
— E se o restart repetir uma transação já processada?
Mais silêncio.
— E se o programa for rerun sem limpar o checkpoint?
Agora nosso jovem não parece mais tão confortável.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se perto do quadro branco.
A porta abre.
O Doctor sai.
Olha para nosso aprendiz.
— Você conhece COBOL?
— Sim.
— Muito?
Nosso jovem hesita.
Cinco minutos atrás teria respondido:
“Bastante.”
Agora:
— Estou começando a achar que talvez não.
O Doctor sorri.
— Excelente.
— Excelente?!
— Sim.
— Acabei de descobrir que sei menos do que imaginava.
— Exatamente.
Pausa.
— Esse costuma ser um ótimo começo.
Bem-vindo ao:
Dunning-Kruger Effect
Ou:
Efeito Dunning-Kruger
O fenômeno pelo qual pessoas com conhecimento ou habilidade limitada em determinado domínio podem superestimar sua própria competência, em parte porque ainda não desenvolveram conhecimento suficiente para reconhecer adequadamente os próprios erros, limitações e lacunas.
Em linguagem Bellacosa:
“Quando você sabe pouco, ainda não sabe o suficiente para perceber tudo o que não sabe.”
🧠 Antes de tudo: não transforme Dunning-Kruger em insulto
Essa é importantíssima.
Na internet, “Dunning-Kruger” virou quase sinônimo de:
“Fulano é burro e acha que sabe tudo.”
Isso é uma simplificação ruim.
O fenômeno não diz:
pessoas pouco inteligentes são arrogantes.
Nem:
todo iniciante é excessivamente confiante.
Nem:
todo especialista é humilde.
A ideia é mais interessante.
Para avaliar nossa própria competência, precisamos possuir parte das mesmas habilidades necessárias para desempenhar bem a tarefa.
Ou seja:
às vezes precisamos aprender para descobrir que estávamos errando.
☕ O programador COBOL que descobriu o PERFORM
Primeiro dia.
Você aprende:
PERFORM 1000-PROCESSAR
PERFORM 2000-GRAVAR.
Fantástico.
COBOL parece simples.
Depois descobre:
PERFORM THRU.
PERFORM VARYING.
PERFORM UNTIL.
PERFORM TEST BEFORE.
TEST AFTER.
Escopo.
Fall-through.
GO TO perdido no meio.
Alterações feitas em 1987.
COPYBOOK.
REDEFINES.
OCCURS DEPENDING ON.
COMP-3.
E você percebe:
o COBOL que parecia pequeno era apenas a parte que já cabia no seu mapa.
🗺️ O território era muito maior
Isso acontece em praticamente toda área técnica.
No começo:
COBOL = PROGRAMA
JCL = EXECUTAR
DB2 = BANCO
CICS = ONLINE
Depois:
COBOL começa a envolver:
layout;
encoding;
numeric representation;
runtime;
compiler options;
LE;
performance;
compatibilidade.
JCL vira:
catalog;
SMS;
GDG;
DISP;
restart;
JES;
condition codes;
procedures.
DB2 vira:
locking;
isolation;
optimizer;
indexes;
buffer pools;
logging;
utilities;
recovery.
CICS vira:
tasks;
regions;
queues;
storage;
syncpoint;
TOR/AOR;
routing;
recovery.
Conhecimento aumenta.
E junto com ele:
a superfície do desconhecido.
👻 Easter Egg nº 1 — A TARDIS do conhecimento
Companion entra na TARDIS pela primeira vez.
— É maior por dentro!
Doctor:
— Conhecimento também.
— Como assim?
— Quanto mais você entra...
Pausa.
— maior ele fica.
Talvez essa seja uma das melhores metáforas para aprender mainframe.
Você abre a porta esperando uma cabine.
Encontra um universo.
🧠 O problema metacognitivo
Existe uma palavra importante:
metacognição
Basicamente:
capacidade de avaliar o próprio pensamento e conhecimento.
Para perceber:
“Minha solução está errada”
você precisa possuir conhecimento suficiente para reconhecer o erro.
Isso cria um paradoxo.
A pessoa pode cometer erro...
e simultaneamente não possuir as ferramentas mentais necessárias para identificar que cometeu.
☕ COBOL e o PIC errado
Iniciante escreve:
01 WS-VALOR PIC 9(5).
Depois recebe:
123456
Problema.
Veterano pergunta:
— E se passar de 99999?
Novato:
— Não vai passar.
— Por quê?
— Porque nunca vi passar.
Agora encontramos:
Dunning-Kruger;
Availability Heuristic;
Base Rate Neglect;
Optimism Bias.
Tudo numa variável.
🧠 Pouco conhecimento produz modelos simples
No início, seu modelo mental pode ser:
INPUT
↓
PROCESSAMENTO
↓
OUTPUT
Excelente.
Depois aprende que existe:
INPUT
↓
VALIDAÇÃO
↓
NORMALIZAÇÃO
↓
LOCK
↓
PROCESSAMENTO
↓
COMMIT
↓
LOG
↓
QUEUE
↓
DOWNSTREAM
↓
RECONCILIAÇÃO
Quanto mais o modelo cresce:
menos confortáveis ficam frases como:
“É só fazer X.”
☕ Uma palavra perigosa na TI:
“Só.”
“É só alterar o copybook.”
“É só aumentar o parâmetro.”
“É só reiniciar.”
“É só migrar.”
“É só chamar API.”
“É só trocar COBOL por Java.”
O “só” frequentemente indica:
complexidade invisível para quem está falando.
Nem sempre.
Mas merece atenção.
🧠 Dunning-Kruger + Planning Fallacy
Essa combinação é fantástica.
Pessoa conhece pouco o trabalho.
Logo:
não enxerga todas as etapas.
Então estima:
“Duas horas.”
Depois descobre:
copybook;
impact analysis;
testes;
batch;
DB2;
MQ;
regressão;
change;
rollback.
Planning Fallacy aparece porque:
não sabemos nem listar tudo aquilo que precisamos estimar.
📅 “É só uma mudança pequena”
Nosso jovem diz:
— Alterar esse campo leva quinze minutos.
Veterano responde:
— O código, talvez.
— Então?
— Precisamos descobrir quem usa.
E aí começam:
grep;
impact analysis;
programas;
copybooks;
feeds;
arquivo externo;
reconciliação.
Quinze minutos de digitação.
Três dias de engenharia.
🧠 Overconfidence Bias versus Dunning-Kruger
São próximos.
Mas não iguais.
Overconfidence Bias
Confiança excessiva em:
conhecimento;
previsão;
capacidade.
Pode afetar qualquer nível de experiência.
Dunning-Kruger
Destaca especialmente como baixa competência pode dificultar a própria avaliação da competência.
Um especialista também pode ser overconfident.
Mas provavelmente não por desconhecer completamente os fundamentos do domínio.
☕ O veterano arrogante também existe
Trinta anos de COBOL não imunizam ninguém.
Aliás:
experiência pode gerar:
Overconfidence Bias;
Status Quo Bias;
Authority Gradient.
Então não transforme Dunning-Kruger numa arma geracional:
“Júnior não sabe nada.”
Nem:
“Veterano está ultrapassado.”
Ambos são atalhos ruins.
🧠 Conhecimento específico
Uma pessoa pode ser especialista em:
COBOL batch.
E iniciante em:
CICS.
Pode ser senioríssima em:
Db2.
E newbie em:
IA generativa.
Competência não é um nível global.
É contextual.
🎯 Pergunta Bellacosa nº 1
Sempre pergunte:
“Especialista em quê, exatamente?”
Isso reduz generalização.
🧠 Authority Gradient
Agora imagine:
um especialista muito confiante.
Ele diz:
— Isso é simples.
Sala aceita.
Talvez ele esteja falando fora da própria área.
Cargo cria autoridade.
Dunning-Kruger pode ficar protegido pela hierarquia.
👥 Groupthink
Uma pessoa confiante fala primeiro.
Outros pensam:
“Ele parece saber.”
Ninguém questiona.
Agora excesso de confiança individual vira consenso coletivo.
Groupthink amplifica.
🧠 Fluency Effect
Explicações simples e fluidas soam mais verdadeiras.
Pessoa diz com segurança:
“É claramente problema de rede.”
Outra diz:
“Há várias hipóteses; ainda precisamos verificar lock, downstream e saturação.”
Quem parece mais competente?
Curiosamente:
o primeiro.
Mas talvez o segundo saiba muito mais.
☕ A maldição do “depende”
Pergunte a um iniciante:
— Quanto leva?
Resposta:
— Uma hora.
Pergunte a um especialista:
— Depende.
Parece menos confiante.
Mas:
“depende”
pode significar que ele enxerga:
variáveis;
condições;
exceções.
A incerteza bem calibrada é sinal de conhecimento.
🧠 Expertise aumenta nuance
Iniciante:
“Sim.”
Especialista:
“Sim, se A e B forem verdadeiros; caso C exista precisamos fazer D.”
A segunda resposta parece menos elegante.
Mas representa melhor a realidade.
👻 Easter Egg nº 2 — Doctor Who e “depende”
Companion:
— Essa alavanca salva o universo?
Doctor:
— Depende.
— Do quê?
— Da época, dimensão, polaridade, posição das luas e se alguém mexeu no circuito de contenção.
Companion:
— Então você não sabe?
Doctor:
— Pelo contrário.
Pausa.
— Sei o suficiente para não responder rápido.
🧠 Dunning-Kruger + Narrative Bias
Conhecimento pequeno favorece histórias simples.
“Foi o deploy.”
“Foi Db2.”
“Foi operador.”
Uma narrativa clara cria sensação de entendimento.
Quanto mais sabemos:
mais percebemos:
interações.
Narrative Bias gosta do especialista de cinco minutos.
Sistemas complexos geralmente não.
🧠 Representativeness Heuristic
Iniciante vê:
timeout.
Aprendeu:
timeout pode ser Db2.
Pronto:
Db2.
Porque ainda conhece poucos padrões.
Veterano talvez conheça vinte mecanismos que produzem timeout.
Mais conhecimento gera mais alternativas.
Isso pode até parecer indecisão.
Mas é riqueza diagnóstica.
🧠 Confirmation Bias
Pessoa iniciante encontra primeira teoria.
Não sabe quais evidências seriam necessárias para refutá-la.
Então busca confirmação.
Isso reforça sensação de competência.
Aprender método de diagnóstico é tão importante quanto aprender comandos.
☕ Comandos versus raciocínio
Saber:
CANCEL
é fácil.
Saber:
quando cancelar
é outra carreira.
Saber:
START
é fácil.
Saber:
por que iniciar
é engenharia.
🧠 Action Bias
Pouca experiência + muita confiança:
“Restart.”
Especialista:
— Primeiro vamos capturar dump.
Iniciante pode pensar:
“Ele está complicando.”
Na verdade:
o especialista sabe que restart pode destruir evidência.
O conhecimento adicionou cautela.
🧠 Omission Bias também pode aparecer
Novato:
“Melhor não tocar.”
Porque não entende risco.
Ou:
“Pode mexer tranquilo.”
Porque também não entende risco.
Pouco conhecimento não produz sempre ação.
Produz:
avaliação mal calibrada.
Esse é o coração do problema.
🧠 Confidence Calibration
O objetivo não é ser:
confiante
ou:
inseguro.
É ser:
calibrado.
Se você diz:
90% de confiança,
deveria acertar aproximadamente 90% de casos equivalentes ao longo do tempo.
Isso pode ser treinado.
📊 Decision Journal
Antes do diagnóstico:
HYPOTHESIS:
DB2 lock
CONFIDENCE:
80%
Depois:
ROOT CAUSE:
API timeout
Registre.
Depois de 50 casos:
você começa a saber se seus 80% realmente significam 80%.
Isso é maturidade.
🧠 Hindsight Bias tentará trapacear
Depois:
“Eu sabia que talvez fosse API.”
Claro.
Mas antes você escreveu:
DB2 80%.
Logs cognitivos ajudam.
☕ Um SMF da confiança
Seria maravilhoso:
SMF TYPE 999
USER CONFIDENCE RECORD
Campos:
hipótese;
confiança;
resultado.
Nosso ego odiaria.
Nossa engenharia agradeceria.
🧠 Self-Serving Bias entra
Acertou?
“Experiência.”
Errou?
“Caso muito atípico.”
Se isso acontecer sempre:
nunca calibramos.
Self-Serving Bias mantém Dunning-Kruger vivo.
🧠 Feedback é essencial
O fenômeno diminui quando pessoas recebem:
treinamento;
feedback;
experiência.
Porque passam a reconhecer os próprios erros.
Ou seja:
a cura não é:
humilhação.
É:
aprendizado com feedback de qualidade.
☕ Rir do newbie não ajuda
Se alguém pergunta algo básico:
não transforme isso em:
“Como você não sabe?”
Essa cultura incentiva:
fingir conhecimento.
E fingir conhecimento é muito mais perigoso que admitir dúvida.
🧠 Psychological Safety
Equipe madura permite:
“Não sei.”
“Preciso verificar.”
“Nunca fiz isso.”
Essas frases são controles de segurança.
Sim.
“Não sei” pode ser uma ferramenta de alta disponibilidade.
🎯 Pergunta Bellacosa nº 2
Quando não souber:
“Quem sabe mais sobre isso que eu?”
Simples.
Poderosa.
🧠 Authority Gradient inverso
Às vezes alguém em posição elevada evita dizer:
“Não sei.”
Porque acredita que cargo exige certeza.
Isso gera decisões perigosas.
Um líder forte pode dizer:
“Não conheço esse detalhe. Quem conhece?”
Isso melhora sistema.
☕ O especialista que sabe perguntar
Talvez uma das marcas mais fortes da senioridade seja:
não saber tudo.
Mas saber:
onde está dúvida;
quem consultar;
qual evidência procurar.
🧠 Unknown unknowns
Donald Rumsfeld popularizou uma linguagem famosa:
known knowns;
known unknowns;
unknown unknowns.
Em engenharia:
Known known
Sabemos que Db2 pode lockar.
Known unknown
Não sabemos qual thread.
Unknown unknown
Nem sabemos que uma dependência nova entrou no fluxo.
Quanto menos experiente:
maior tendência a não perceber os unknown unknowns.
🧠 O mapa do desconhecido
Especialista talvez não saiba resposta.
Mas conhece categorias de problema.
Isso já é muito.
Novato acha:
mapa = território.
Especialista sabe:
há áreas não mapeadas.
☕ Indiana Jones do mainframe
Novato:
— Já conheço a caverna.
Veterano:
— Você viu a entrada.
Perfeito.
🧠 Curiosity as defense
Uma forma poderosa de combater Dunning-Kruger:
curiosidade metódica.
Pergunte:
o que posso estar deixando passar?
qual premissa não testei?
quem discordaria?
qual caso-limite?
qual impacto indireto?
Curiosidade reduz certeza prematura.
🎯 Pergunta Bellacosa nº 3
“O que eu precisaria saber para descobrir que estou errado?”
Essa pergunta é ouro.
🧠 Pre-mortem
Imagine:
mudança falhou.
Por quê?
Isso força nossa mente a procurar complexidade que talvez não tenhamos visto.
🧠 Red Team
Dê solução para outro profissional.
Peça:
“Quebre.”
Se você sabe pouco:
talvez não enxergue riscos.
O colega traz repertório diferente.
👥 Pair Programming
Para iniciantes:
excelente.
Não apenas porque alguém corrige.
Mas porque expõe:
formas diferentes de pensar.
Você aprende a ver o que não via.
💻 Code Review
Código:
IF WS-STATUS = 'A'
PERFORM PROCESSAR
END-IF
Reviewer:
— O que acontece com 'B'?
— Nunca vem.
— Onde está garantido?
Novato:
— Hmmm.
Pronto.
Um pedaço do território apareceu.
🧠 Testes revelam ignorância útil
Teste falha.
Isso é maravilhoso.
Ele mostra:
seu modelo mental estava incompleto.
Teste não “atrapalha” desenvolvimento.
Ele revela discrepância entre:
o que você imaginava
e:
o que o sistema realmente faz.
☕ Um teste vermelho é uma aula barata
Muito melhor que SEV-1.
🧠 Sandbox
Ambiente seguro também combate excesso de confiança.
Experimente.
Quebre.
Veja.
Quanto mais experiência direta:
mais calibrado o modelo.
🧠 Simulações e Game Days
Você acha:
failover leva 3 min.
Teste.
Leva 27.
Excelente.
Melhor descobrir numa terça às 14h que numa sexta às 03h.
🧠 Dunning-Kruger + Planning Fallacy no DR
— Restore é simples.
— Já testou?
— Não.
— Quanto leva?
— Uns 15 minutos.
Restore real:
3 horas.
Planejamento baseado em conhecimento imaginado.
🧠 Fundamental Attribution Error
Depois falha:
“Operador não sabia restaurar.”
Mas gestão também achava que era simples.
Dunning-Kruger pode existir em processos, não apenas indivíduos.
👥 Organizational Dunning-Kruger
Uma organização inteira pode acreditar:
“Somos maduros em DevOps.”
Mas mede:
quantidade de pipelines.
Não:
lead time;
failure rate;
rollback;
observabilidade.
Conhecimento superficial institucional gera confiança alta.
☕ “Temos IA”
Pergunta:
— O que faz?
— IA.
Perfeito exemplo moderno.
Talvez apenas API chamando modelo.
Mas apresentação:
“Agente autônomo enterprise.”
Conhecimento superficial + marketing.
🤖 IA e Dunning-Kruger
Esse é um terreno fascinante.
Pessoa aprende:
prompt.
RAG.
agent.
tools.
Em poucos dias pensa:
“Agora entendi IA.”
Depois chega:
evals;
hallucinations;
security;
prompt injection;
context poisoning;
tool permissions;
distribution shift;
governance;
observability.
A TARDIS abre de novo.
Maior por dentro.
🧠 AI can amplify perceived expertise
Agora temos um problema novo.
Pessoa pergunta à IA.
Recebe resposta sofisticada.
Passa a sentir que entende o assunto.
Mas:
ter acesso a uma boa explicação não é igual a possuir competência operacional.
Você pode copiar JCL perfeito.
Mas consegue diagnosticar quando falhar?
Outra questão.
☕ Copiar não é dominar
//STEP1 EXEC PGM=SORT
Funciona.
Ótimo.
Agora explique:
SORT FIELDS;
SUM;
OUTFIL;
JOINKEYS;
DCB;
space;
performance.
Conhecimento operacional vem depois.
🧠 Automation Bias + Dunning-Kruger
Usuário pouco experiente recebe resposta da IA.
Não sabe identificar erro.
Confia.
Esse é um risco importante.
Quanto menor sua capacidade de avaliar output:
maior necessidade de controles externos.
🎯 Regra Bellacosa para IA
Quanto menos você conhece o domínio, menos deveria tratar a fluência da IA como prova de correção.
Peça:
fontes;
testes;
validação;
especialista.
🧠 Expertise is verification capacity
Uma definição interessante:
ser especialista não é apenas produzir resposta.
É conseguir:
avaliar a qualidade de uma resposta.
Isso importa enormemente na era da IA.
☕ O júnior com Copilot
Copilot gera código.
Compila.
Júnior:
— Perfeito.
Veterano:
— Testou overflow?
— Não.
— Retry?
— Não.
— Thread safety?
— Não.
Ferramenta aumentou produtividade.
Mas pode aumentar confiança antes da competência.
Educação precisa acompanhar.
🧠 Dunning-Kruger não é uma curva universal simples
Aqui uma curiosidade importante.
Na internet existe um gráfico famoso:
CONFIDENCE
/\
/ \
/ \____
\____
EXPERIENCE
Com nomes como:
“Mount Stupid”;
“Valley of Despair”;
“Slope of Enlightenment”;
“Plateau of Sustainability”.
É divertido.
Mas não é o gráfico original do estudo.
É uma representação popular posterior, muitas vezes usada de forma exagerada.
Bom Easter Egg conceitual:
não transforme o próprio Dunning-Kruger numa simplificação Dunning-Kruger.
😄 Meta-Dunning-Kruger
Pessoa lê um artigo de cinco minutos sobre Dunning-Kruger.
Passa a diagnosticar:
todo mundo.
Talvez seja o exemplo mais engraçado possível.
🧠 O estudo original
O efeito leva o nome de David Dunning e Justin Kruger, pesquisadores que estudaram como pessoas avaliavam suas próprias habilidades em diferentes tarefas.
Uma ideia central dos trabalhos:
algumas pessoas com pior desempenho também tinham dificuldade maior em reconhecer a própria baixa performance.
Mas o tema é estudado, debatido e refinado.
Não use como rótulo médico ou diagnóstico pessoal.
É uma lente sobre calibração.
☕ Bellacosa rule:
Use vieses para revisar decisões, não para insultar colegas.
Vale para toda a série.
🧠 Impostor Syndrome não é o inverso simples
Outro erro popular:
“Dunning-Kruger = incompetente confiante.”
“Impostor syndrome = competente inseguro.”
Realidade é mais complexa.
Confiança e competência variam.
Pessoas experientes podem subestimar ou superestimar.
Não transforme psicologia em Pokémon.
🧠 Expertise can reduce confidence
À medida que você aprende:
descobre exceções.
Isso pode reduzir certeza.
Mas não significa necessariamente baixa autoconfiança.
Um especialista pode dizer:
“Tenho 70% de confiança.”
Isso é melhor que um iniciante dizendo:
“100%.”
Calibração.
🧠 Confidence intervals cognitivas
Em vez de:
“é Db2.”
Diga:
“Db2 é minha hipótese principal, 60%, mas MQ e API continuam abertas.”
Isso mostra qualidade epistemológica.
☕ “Não sei ainda” é diferente de “não sei nada”
Outra distinção importante.
Especialista pode suspender conclusão.
Isso não é fraqueza.
É controle de qualidade.
🧠 Dunning-Kruger + Action Bias
Pouco conhecimento.
Alta confiança.
Incidente.
Ação rápida.
Restart.
Perfeito.
Uma defesa:
gates de mudança baseados no risco, não na confiança de quem fala.
🧠 Second Pair of Eyes
Quanto mais crítico:
review.
Mesmo se especialista diz:
“Tenho certeza.”
Especialmente então.
🧠 Checklists
Pilotos experientes usam.
Cirurgiões experientes usam.
Operadores experientes também deveriam.
Checklist não é muleta de incompetência.
É proteção contra:
memória;
pressa;
excesso de confiança.
☕ Quanto mais experiente, mais você entende por que checklist existe
Provavelmente.
🧠 Runbook as distributed expertise
Um bom runbook permite que conhecimento de vários especialistas esteja disponível no incidente.
Isso reduz dependência do:
“eu acho.”
🧠 Escalation Criteria
Dunning-Kruger pode fazer iniciante não perceber:
quando pedir ajuda.
Defina:
ESCALATE IF:
- data integrity uncertain
- rollback unclear
- security impact unknown
- two failed attempts
Agora não depende do ego decidir.
🎯 Pergunta Bellacosa nº 4
“Qual é o momento em que eu devo parar e chamar alguém?”
Isso deveria ser ensinado desde o primeiro dia.
🧠 Seniority is knowing escalation
Você não precisa resolver tudo.
Profissional maduro sabe:
quando risco ultrapassa competência disponível.
☕ A frase mais cara:
“Deixa comigo.”
Às vezes excelente.
Às vezes prelúdio de War Room.
Pergunte:
— Você já fez isso?
Se:
— Nunca, mas parece simples.
Talvez alguém queira ficar por perto.
🧠 Unknown Skill Boundary
Faça mapa pessoal:
I CAN DO ALONE
I CAN DO WITH REVIEW
I NEED HELP
I SHOULD NOT TOUCH
Isso é poderoso.
Especialmente no início.
💻 Exemplo COBOL iniciante
Posso fazer sozinho
Alteração simples com teste conhecido.
Com review
Mudança em copybook compartilhado.
Preciso de ajuda
Restart complexo.
Não devo tocar sozinho
Reprocessamento financeiro sem conhecer reconciliação.
Excelente.
🧠 Growth means moving boundaries
Com experiência:
coisas migram:
Need Help → Review → Alone.
Mas conscientemente.
Não porque:
“acho que já sei.”
🧠 Deliberate Practice
Só repetir não basta.
Você pode repetir erro por dez anos.
Experiência útil precisa:
feedback;
desafio;
correção.
Isso é prática deliberada.
☕ Dez anos de experiência ou um ano repetido dez vezes?
Frase antiga.
Ainda ótima.
🧠 Normalization of Deviance
Pessoa faz algo errado.
Funciona.
Repete.
Agora:
“Tenho muita experiência nisso.”
Talvez tenha acumulado sobrevivência, não competência.
Outcome Bias + Normalization + Dunning-Kruger.
🧠 Survivorship Bias
Você sempre fez:
restart sem dump.
Nunca deu problema.
Conclusão:
“Não precisa dump.”
Mas talvez teve sorte.
Os casos ruins ainda não apareceram.
🧠 Success can delay learning
Quando erro não produz consequência:
feedback não chega.
Então prática ruim continua.
Curiosamente:
às vezes o fracasso pequeno é professor melhor que o sucesso sortudo.
☕ Sandbox quebrando seu ego com carinho
Esse é o lugar perfeito.
Quebre lá.
Aprenda barato.
🧠 Psychological safety for questions
Novato precisa poder perguntar:
“O que é syncpoint?”
Sem medo.
Senão finge.
Fingimento + produção crítica = aventura.
👥 Mentorship
Mentor bom não diz apenas:
“Faça assim.”
Explica:
“Aqui está o que pode acontecer se fizermos diferente.”
Isso constrói mapa de riscos.
🧠 Teaching exposes complexity
Curiosamente, ensinar também ajuda o especialista.
Quando precisa explicar:
descobre lacunas próprias.
Então:
mentoria combate Dunning-Kruger dos dois lados.
☕ Método Feynman
Tente explicar conceito de forma simples.
Se não consegue:
talvez não entenda tão bem quanto pensa.
Para COBOL:
“Explique por que este programa precisa de checkpoint.”
Se resposta vira fumaça:
estude mais.
🧠 Teach Back
Após treinamento:
peça ao aprendiz:
“Explique para mim como faria.”
Isso revela modelo mental.
Muito melhor que:
“Entendeu?”
Todo mundo responde:
“Sim.”
🧠 “Entendeu?” é uma pergunta quase inútil
Use:
“O que faria se o STEP2 terminasse RC=8?”
Agora testa conhecimento.
🧪 Scenario-based training
Coloque casos:
S0C7;
file status 35;
lock;
MQ backlog;
restart.
Peça decisão.
Depois feedback.
Isso melhora calibração.
🧠 Learning curve da humildade
Uma jornada saudável:
EU SEI
↓
HMM...
↓
EU NÃO SABIA QUE ISSO EXISTIA
↓
AGORA ENTENDO MELHOR
↓
AINDA TENHO MUITO A APRENDER
Essa última frase pode permanecer para sempre.
E é ótimo.
👻 Easter Egg nº 3 — o Doctor de 900 anos
Companion:
— Você sabe tudo?
Doctor:
— Não.
— Mas você tem centenas de anos.
— Exatamente.
— Não entendi.
— Depois de centenas de anos...
Pausa.
— tive tempo suficiente para descobrir quantas coisas ainda não sei.
🧠 Expertise and uncertainty
Conhecimento real não elimina incerteza.
Ajuda a:
localizá-la.
Essa é uma diferença enorme.
Novato:
não vê risco.
Especialista:
diz onde risco está.
☕ “Não sei” localizado
Ruim:
“Não sei nada.”
Bom:
“Sei que o processamento está correto até o commit; não sei ainda como o restart trata registros após checkpoint.”
Essa é uma dúvida útil.
🧠 Incident Command
Incident Commander precisa valorizar:
declaração de confiança.
Exemplo:
DBA:
Hypothesis: lock
Confidence: 70%
APP:
Hypothesis: API
Confidence: 50%
Isso reduz voz dominante.
🧠 Confidence without evidence
Se alguém diz:
“Tenho certeza.”
Pergunte:
“Qual evidência mudaria sua opinião?”
Se:
“Nenhuma.”
Temos um problema.
🧠 Dunning-Kruger + Confirmation Bias
Pouca competência dificulta reconhecer evidência contrária.
Então precisamos processo que force:
contraprova.
🧪 Falsification question
Antes de executar:
“Se minha teoria estiver errada, o que verei?”
Excelente hábito.
📊 Historical calibration
Quantas vezes sua primeira hipótese estava certa?
10%?
60%?
Dados ajudam.
🧠 Base Rate Neglect
Novato pode achar:
problema raro
porque acabou de aprender sobre ele.
Representativeness.
Availability.
Dunning-Kruger.
O conhecimento recém-adquirido parece explicar o universo.
☕ O “martelo novo”
Você aprende:
deadlock.
Próximas três semanas:
tudo parece deadlock.
Aprende:
memory leak.
Agora tudo é memory leak.
Isso é normal no aprendizado.
Só não promova para RCA sem evidência.
🧠 Law of the Instrument
A famosa ideia:
se tudo que você tem é um martelo, tudo parece prego.
No aprendizado:
a última ferramenta aprendida vira lente universal.
Combina perfeitamente com Recency e Availability.
🧠 Dunning-Kruger organizacional em modernização
Equipe conhece pouco mainframe.
Conclui:
“É só reescrever em Java.”
Outra equipe conhece pouco cloud.
Conclui:
“Cloud não presta.”
Mesma estrutura.
Pouco conhecimento do outro domínio.
Alta certeza.
☕ A fronteira mais perigosa é a que você nunca atravessou
Antes de declarar:
“simples”;
“obsoleto”;
“impossível”,
converse com quem vive ali.
🧠 Cross-domain review
Para decisão mainframe/cloud:
traga especialistas dos dois lados.
Evita:
ignorância unilateral.
🤖 Agentes e hype
Pessoa monta primeiro agente.
Funciona numa demo.
Conclusão:
“Agora podemos automatizar tudo.”
Depois encontra:
tool errors;
permissions;
state;
security;
loops;
cost;
observability.
Demo não é produção.
🧠 Prototype confidence
POC sucesso pode gerar:
overgeneralization.
Pergunte:
volume?
failure modes?
recovery?
adversarial inputs?
governance?
A maturidade começa depois da demo.
☕ Hello World é extraordinariamente confiável
Até tentar pagar salário com ele.
📋 Checklist anti-Dunning-Kruger
[ ] Tenho experiência real neste domínio?
[ ] Já enfrentei casos de falha, não apenas happy path?
[ ] Que riscos eu talvez nem saiba listar?
[ ] Quem conhece mais esse assunto?
[ ] Minha confiança está apoiada em dados ou sensação?
[ ] Já executei isso em ambiente seguro?
[ ] Sei como rollback funciona?
[ ] Sei como reconhecer que estou errado?
[ ] Que evidência contradiz minha hipótese?
[ ] Estou chamando algo de “simples” cedo demais?
[ ] Minha estimativa inclui trabalho invisível?
[ ] Estou confundindo sucesso passado com competência?
[ ] A IA está me dando confiança sem compreensão?
[ ] Preciso de review?
[ ] Qual é meu limite de escalonamento?
🧪 Como combater o Dunning-Kruger — passo a passo
Passo 1 — Declare nível de experiência
Sem vergonha.
“Primeira vez.”
Ajuda todo mundo.
Passo 2 — Quantifique confiança
Não apenas “sei”.
Passo 3 — Peça review
Principalmente em área nova.
Passo 4 — Use checklists
Memória não é processo.
Passo 5 — Teste em ambiente seguro
Aprenda antes da produção.
Passo 6 — Procure feedback rápido
Erro barato ensina.
Passo 7 — Mantenha decision journal
Calibre-se.
Passo 8 — Procure contraexemplos
Sua regra possui exceção?
Passo 9 — Ensine o que aprendeu
Explicar revela lacunas.
Passo 10 — Atualize o mapa da própria competência
O que agora você sabe que não sabe?
🧠 Competence Map
Crie algo simples:
COBOL
████████░░
JCL
███████░░░
DB2
████░░░░░░
CICS
███░░░░░░░
IMS
██░░░░░░░░
Não precisa ser preciso.
Serve para lembrar:
competência é multidimensional.
☕ Nível 99 em COBOL não dá nível 99 em tudo
Infelizmente não existe multiclass automática.
🧠 Humility is not self-deprecation
Humildade técnica não é:
“Sou ruim.”
É:
“Conheço meus limites e atualizo minha opinião quando chegam dados melhores.”
Isso é força.
🧠 Confidence with escape hatch
Uma frase perfeita:
“Minha melhor hipótese é X, com 70% de confiança. Se Y não aparecer, abandono.”
Isso é profissionalismo.
🧠 Certainty theater
Algumas organizações recompensam:
certeza.
Executivos perguntam:
— Vai funcionar?
Engenheiro:
— Provavelmente.
Parece fraco.
Outro:
— Com certeza.
Parece líder.
Talvez estejamos premiando teatro.
☕ A confiança mais alta da reunião nem sempre mora na pessoa que sabe mais
Essa merece quadro.
🧠 Management needs calibrated language
“Não sei”;
“precisamos testar”;
“70%”;
não deveriam ser penalizados.
Senão organização fabrica excesso de confiança.
🧠 Incentives create fake certainty
Se promoção exige:
“ter resposta”,
pessoas inventam respostas.
Se cultura valoriza:
investigação,
pessoas admitem dúvidas.
Dunning-Kruger pode ser amplificado pelo ambiente.
🧠 Actor-Observer Bias
Quando outro exagera competência:
“arrogante.”
Quando fazemos:
“precisávamos decidir rápido.”
Novamente:
mesma régua.
🧠 Self-Serving Bias
Acertamos depois de dizer:
“tenho certeza.”
“Viu?”
Erramos:
“Era caso raro.”
Precisamos registros.
🧠 Fundamental Attribution Error
Não rotule:
“ele tem Dunning-Kruger.”
Isso é exatamente usar uma categoria psicológica para explicar pessoa.
Muito irônico depois do capítulo anterior.
Melhor dizer:
“A confiança demonstrada parece maior do que a evidência e a experiência disponíveis.”
Comportamento.
Não identidade.
☕ O meme não é diagnóstico
Regra universal.
🧠 Psychological safety + accountability
Se alguém assume tarefa fora da competência sem avisar:
problema.
Mas também pergunte:
era fácil pedir ajuda?
Havia especialista?
Prazo permitia?
Novamente:
pessoa + contexto.
🧠 Mentoring ladder
Para um newbie:
OBSERVE
↓
DO WITH HELP
↓
DO WITH REVIEW
↓
DO ALONE
↓
TEACH
Essa progressão reduz excesso de confiança sem sufocar autonomia.
💻 COBOL apprenticeship
Primeiro:
leia código.
Depois:
alteração pequena.
Depois:
testes.
Depois:
restart.
Depois:
produção crítica.
Não jogue novato num SEV-1 e depois reclame que não sabia.
🧠 Competence needs exposure
Livro ensina.
Curso ensina.
Mas incidentes reais ensinam ambiguidades.
Por isso:
shadowing.
pairing.
labs.
Game Days.
☕ O primeiro S0C7 que você resolve parece magia
No décimo:
você percebe que S0C7 era a porta.
Não a casa.
🧠 Resilience Engineering
Equipes resilientes não dependem de:
indivíduos saberem tudo.
Criam:
redundância de conhecimento;
runbooks;
instrumentação;
escalation;
automação.
Isso reduz dano de avaliações individuais erradas.
🧠 Swiss Cheese novamente
Se um newbie superestima capacidade:
uma barreira deveria ajudar.
Review.
Teste.
Approval.
Canary.
O erro cognitivo de uma pessoa não deveria atravessar tudo.
🧀 Bias também precisa de queijo suíço
Bonito.
Cada viés humano:
inevitável.
Defesas:
processo;
tecnologia;
cultura.
Nenhuma perfeita.
Juntas:
resiliência.
🧠 Continuous Improvement
Depois de incidente:
não pergunte:
“Quem sabia pouco?”
Pergunte:
quem tinha quais skills?
onde review faltou?
treinamento estava adequado?
escalation era claro?
nossa confiança estava calibrada?
Agora Dunning-Kruger vira melhoria.
🎯 Pergunta Bellacosa nº 5
“Que conhecimento descobrimos que não sabíamos que precisava existir?”
Essa pergunta é belíssima.
É o coração do aprendizado.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Dunning-Kruger Effect descreve situações em que habilidade limitada também dificulta avaliar corretamente a própria habilidade.
Não é sinônimo de burrice ou arrogância.
Pouco conhecimento cria modelos mentais simples e pode esconder complexidade.
Expertise frequentemente aumenta percepção das exceções e das incertezas.
Overconfidence Bias pode ocorrer em qualquer nível; Dunning-Kruger destaca problemas de autoavaliação em baixa competência.
Planning Fallacy pode nascer de não conhecermos todas as etapas do trabalho.
Representativeness e Availability fazem o pouco que conhecemos parecer aplicável a tudo.
Self-Serving Bias pode impedir calibração quando explicamos nossos erros como casos excepcionais.
Feedback, prática deliberada, mentoria, review e testes ajudam a melhorar a autoavaliação.
IA pode aumentar confiança sem aumentar competência equivalente, especialmente quando o usuário não consegue validar a resposta.
“Não sei” e “preciso de ajuda” são controles de segurança.
E principalmente:
O verdadeiro salto de conhecimento não acontece quando você finalmente acha que sabe tudo. Acontece quando aprende a distinguir claramente aquilo que sabe, aquilo que suspeita e aquilo que ainda precisa perguntar.
🕰️ De volta à reunião das 09:12
Nosso jovem começou dizendo:
— É só ler, alterar e gravar.
Uma hora depois, o quadro está cheio:
VSAM 1
VSAM 2
CHECKPOINT
RESTART
COMMIT
RERUN
DUPLICATE PROCESSING
RECOVERY
RECONCILIATION
Ele olha.
— Eu não fazia ideia de que havia tudo isso.
O especialista responde:
— Normal.
— Então eu estava errado?
— Sua solução inicial estava incompleta.
— É a mesma coisa?
— Não exatamente.
Nosso jovem pensa.
— E quanto tempo até eu dominar?
O especialista ri.
— Qual parte?
O Doctor sorri.
— Excelente resposta.
Nosso programador pega o café.
Agora parece menos confiante.
Mas também:
muito mais preparado para aprender.
🔧 Seis meses depois
Nova mudança.
Alguém pergunta:
— Parece simples. Você consegue fazer sozinho?
Antigamente:
“Sim.”
Agora ele responde:
— O código, sim.
— E o resto?
— Preciso revisar restart e impacto no copybook com alguém.
— Não sabe?
— Sei onde estou confortável e onde quero segundo par de olhos.
O veterano sorri.
Essa é uma espécie curiosa de evolução:
ele parece menos confiante porque ficou mais competente.
Na verdade, apenas ficou mais calibrado.
🥚 Easter Egg final
Na manhã seguinte aparece:
BELLACOSA.BIAS(DUNNING-KRUGER)
Dentro:
IF CONFIDENCE = '100%'
AND EXPERIENCE = 'LOW'
PERFORM ASK-MORE-QUESTIONS
END-IF.
IF SOMEONE-SAYS 'IT-IS-SIMPLE'
PERFORM FIND-HIDDEN-COMPLEXITY
END-IF.
IF I-DO-NOT-KNOW
PERFORM ASK-FOR-HELP
NOT PRETEND-I-KNOW
END-IF.
Comentário:
* "I DON'T KNOW"
* IS A VALID PRODUCTION CONTROL.
Outro:
* CONFIDENCE IS NOT A SKILL METRIC.
Outro:
* THE MORE YOU LEARN,
* THE BIGGER THE TARDIS GETS.
Mais um:
* A NEW HAMMER
* DOES NOT MAKE EVERYTHING A NAIL.
E naturalmente:
* DALEKS HAVE 100% CONFIDENCE.
* THIS HAS NOT ALWAYS HELPED THEM.
Nosso jovem fecha o membro.
Pouco depois alguém pergunta:
— Você conhece IMS?
Ele sabe alguma coisa.
Já estudou.
Já escreveu pequenos exemplos.
Poderia dizer:
“Sim.”
Em vez disso:
— Conheço o básico de DL/I e alguns conceitos. Ainda não operaria uma situação crítica sozinho.
O colega responde:
— Ótimo. Então vamos chamar a Alice também.
Nenhuma vergonha.
Nenhum teatro.
Nenhuma aventura desnecessária.
Apenas competência real crescendo exatamente onde a falsa certeza diminuiu.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica uma última frase:
O iniciante perigoso não é aquele que sabe pouco. É aquele que não consegue enxergar onde termina aquilo que sabe. E o especialista valioso não é aquele que sabe tudo — é aquele que sabe exatamente quando precisa continuar perguntando.
☕🌀
Next stop: Illusion of Control — quando passamos a acreditar que dashboards, procedimentos, comandos, automações e nossa própria experiência nos dão mais controle sobre o sistema do que realmente possuímos.
