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.

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:

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

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.

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.

Translate

sexta-feira, 14 de agosto de 2026