 |
| Bellacosa Mainframe e a zona de conforto para aprender novos skills |
☕ Um Café no Bellacosa Mainframe
A Zona de Conforto sem Mistérios
O guia do Programador COBOL Padawan para atravessar o medo, aprender novas tecnologias e crescer como um oficial da Frota Estelar
Existe uma cena que se repete silenciosamente em milhares de departamentos de tecnologia.
Um programador experiente abre o terminal 3270, acessa o TSO, entra no ISPF, seleciona a opção 2, edita um membro COBOL, submete o JCL e acompanha o resultado no SDSF.
Tudo funciona.
O programa compila.
O MAXCC termina em zero.
O arquivo é atualizado.
O processamento noturno segue normalmente.
A tripulação pode respirar aliviada.
Então alguém aparece na reunião e pronuncia palavras aparentemente vindas de uma transmissão interceptada do Quadrante Delta:
— Precisamos colocar o fonte no Git.
— Vamos automatizar o deploy com Ansible.
— A aplicação será exposta por uma API REST.
— O pipeline será executado no Jenkins.
— Também teremos integração com OpenShift, observabilidade e inteligência artificial.
Naquele momento, o veterano que enfrentou abends, arquivos VSAM corrompidos, SQLCODE -911, problemas de COMMAREA, incidentes de produção e madrugadas ao lado do console sente algo estranho.
Não é falta de capacidade.
Não é incompetência.
É apenas o encontro com uma nova fronteira.
É a passagem da zona de conforto para a zona de medo.
A imagem analisada nesta conversa apresenta quatro regiões simbólicas do desenvolvimento pessoal e profissional:
Zona de conforto
Zona de medo
Zona de aprendizado
Zona de crescimento
Embora seja um modelo simples, ele ajuda a compreender algo profundamente humano: a forma como reagimos ao desconhecido.
E, para um programador COBOL iniciante, compreender esse processo é tão importante quanto aprender WORKING-STORAGE, PERFORM, READ, WRITE, CALL, JCL, DB2 ou CICS.
Porque a tecnologia muda.
Os sistemas evoluem.
Os compiladores recebem novos recursos.
As empresas adotam novas arquiteturas.
Mas o maior obstáculo, frequentemente, não está no código.
Está na voz interna que diz:
“Talvez eu não consiga.”
Prepare sua caneca de café, ajuste o comunicador e confira se o seu job terminou com RC=0000.
Nossa missão começa agora.
Capítulo I — O que realmente é a zona de conforto?
A zona de conforto é o conjunto de atividades, situações, conhecimentos e ambientes nos quais nos sentimos seguros e relativamente no controle.
É o território conhecido.
Para um programador COBOL iniciante, a zona de conforto pode ser pequena:
abrir o editor;
digitar um programa simples;
exibir uma mensagem com DISPLAY;
realizar cálculos;
executar um JCL básico;
consultar o spool;
corrigir pequenos erros de compilação.
Para um profissional veterano, ela pode ser muito maior:
COBOL;
JCL;
VSAM;
DB2;
CICS;
IMS;
MQ;
RACF;
utilitários;
análise de dumps;
implantação em produção.
A zona de conforto não é necessariamente um lugar ruim.
Esse é um dos primeiros mitos que precisamos desmontar.
Muitos discursos motivacionais tratam a zona de conforto como uma prisão, um pântano ou uma estação espacial abandonada. Porém, ela também representa domínio, experiência, estabilidade e eficiência.
Imagine um piloto que não se sente confortável com os controles da nave.
Imagine um cirurgião que desconhece seus instrumentos.
Imagine um operador de produção que precisa improvisar durante todo processamento crítico.
Isso seria perigoso.
Na zona de conforto, tarefas conhecidas exigem menos esforço mental. O cérebro reconhece padrões, antecipa resultados e executa sequências já praticadas.
Quando um programador experiente lê:
READ ARQ-CLIENTES
AT END
MOVE 'S' TO WS-FIM
END-READ
ele não precisa analisar cada palavra como um iniciante.
Ele reconhece o padrão.
O mesmo acontece quando encontra:
//STEP01 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
LISTCAT ENT('EMPRESA.CLIENTES.KSDS') ALL
/*
O conhecimento já foi incorporado.
Aquilo que antes exigia grande concentração tornou-se familiar.
Portanto, a zona de conforto é também o depósito das habilidades consolidadas.
Ela é o seu hangar.
É o local onde a nave recebe manutenção, combustível e reparos.
O problema começa quando o hangar se transforma no único destino possível.
Capítulo II — Quando o conforto vira estagnação
Existe uma diferença importante entre estabilidade e estagnação.
A estabilidade diz:
“Eu domino esta atividade.”
A estagnação diz:
“Não preciso aprender nenhuma outra.”
Essa diferença parece pequena, mas define carreiras inteiras.
Um profissional pode trabalhar durante vinte anos com COBOL e continuar evoluindo. Ele pode aprofundar seus conhecimentos em performance, arquitetura, segurança, APIs, modernização, compiladores, DevOps e observabilidade.
Outro profissional pode repetir durante vinte anos o mesmo conjunto de tarefas sem ampliar sua compreensão.
Ambos possuem experiência.
Mas apenas um continua expandindo sua capacidade.
O tempo de carreira não é automaticamente igual a crescimento.
Às vezes, alguém possui vinte anos de aprendizado.
Em outros casos, possui um ano de aprendizado repetido vinte vezes.
No universo mainframe, a sensação de segurança pode ser particularmente forte porque muitas tecnologias centrais são estáveis, robustas e longevas.
COBOL continua processando operações fundamentais.
JCL continua organizando cargas batch.
DB2 continua armazenando dados essenciais.
CICS continua executando milhões de transações.
Essa estabilidade é uma virtude.
Mas não significa que o ecossistema esteja parado.
Hoje, COBOL conversa com:
O mainframe não desapareceu.
Ele ganhou novas portas, novos corredores e novos decks.
O profissional que conhece apenas um corredor pode continuar trabalhando, mas terá dificuldade para compreender a nave inteira.
Capítulo III — A zona de medo: o primeiro campo de força
Ao tentar aprender algo novo, normalmente não entramos diretamente na zona de aprendizado.
Primeiro atravessamos a zona de medo.
É nela que aparecem:
Imagine que você programa COBOL há algum tempo, mas nunca utilizou Git.
Um colega abre o terminal e executa:
git clone
git add
git commit
git push
git pull
git merge
Você olha aquilo e pensa:
“Isso não é para mim.”
Curiosamente, talvez essa mesma pessoa consiga compreender um JCL com dez steps, arquivos temporários, condições de execução, procedimentos catalogados e símbolos.
Ou talvez consiga analisar um programa COBOL com vinte mil linhas.
Mesmo assim, cinco comandos de Git parecem ameaçadores.
Por quê?
Porque competência em uma área não elimina automaticamente o medo de ser iniciante em outra.
Esse é um dos grandes desafios do profissional experiente: aceitar voltar temporariamente à condição de aprendiz.
Um iniciante já espera não saber.
Um veterano pode sentir vergonha de não saber.
É aí que entra a famosa síndrome do impostor.
Capítulo IV — A síndrome do impostor no deck de comando
A síndrome do impostor é a sensação persistente de que não somos tão competentes quanto os outros acreditam ou de que seremos “descobertos” como inadequados.
Ela pode aparecer até mesmo em profissionais altamente qualificados.
Pensamentos comuns incluem:
“Todo mundo entende isso, menos eu.”
“Só consegui porque tive sorte.”
“Não sou realmente bom.”
“Vou fazer uma pergunta e passar vergonha.”
“Sou velho demais para aprender.”
“Essa tecnologia é para pessoas mais jovens.”
“Meu inglês não é bom.”
“Nunca vou entender isso.”
Agora observe uma curiosidade.
Em muitos treinamentos técnicos, várias pessoas têm exatamente a mesma dúvida, mas ninguém pergunta.
Todos acreditam que são os únicos que não entenderam.
A sala permanece em silêncio.
O instrutor continua.
E vinte profissionais saem carregando a mesma lacuna.
A pergunta que parecia representar fraqueza poderia ter ajudado toda a turma.
Na ponte da USS Enterprise, o comandante não esconde uma leitura desconhecida dos sensores por medo de parecer inseguro. Ele consulta Data, Geordi, Spock, Uhura, Worf ou qualquer especialista disponível.
Pedir informação não diminui sua autoridade.
Melhora a decisão.
Em tecnologia, perguntar é parte do trabalho.
Capítulo V — As desculpas mais elegantes do universo corporativo
A zona de medo raramente se apresenta dizendo:
“Estou com medo.”
Ela costuma vestir um uniforme racional e apresentar justificativas aparentemente perfeitas.
Algumas frases clássicas:
“Não tenho tempo agora.”
“Vou estudar quando o projeto terminar.”
“Primeiro preciso comprar um computador melhor.”
“Minha empresa ainda não usa isso.”
“Essa tecnologia é moda.”
“Já estou muito velho.”
“Sou desenvolvedor, não sou infraestrutura.”
“Sou mainframe, não sou cloud.”
“Não preciso de Git porque o fonte está no PDS.”
“Inteligência artificial não serve para COBOL.”
“Python é coisa de cientista de dados.”
“Docker não roda no z/OS, então não me interessa.”
Algumas dessas afirmações podem conter partes verdadeiras.
O problema está no uso da verdade como escudo para evitar qualquer aproximação.
Talvez você realmente não precise instalar Kubernetes amanhã.
Mas pode precisar entender o que ele faz.
Talvez não vá administrar OpenShift.
Mas pode precisar compreender onde sua API será publicada.
Talvez não programe aplicações Python em produção.
Mas pode usar Python para analisar relatórios, automatizar tarefas ou converter arquivos.
Aprender não significa abandonar sua especialidade.
Significa construir pontes entre ela e o restante do universo tecnológico.
Capítulo VI — A opinião dos outros e os klingons imaginários
Na zona de medo, a opinião das outras pessoas ganha um poder exagerado.
O estudante pensa:
“O que vão dizer se eu errar?”
Na prática, a maioria das pessoas está ocupada pensando nos próprios problemas.
O público imaginário que julgaria cada erro geralmente não existe.
E, quando existe alguém disposto a ridicularizar uma pergunta honesta, isso revela mais sobre essa pessoa do que sobre quem perguntou.
Aprender exige tolerância ao erro.
Um programa COBOL não nasce perfeito.
Ele passa por:
O erro é uma mensagem.
Assim como o compilador apresenta:
IGYPS2121-S
a experiência também fornece diagnósticos.
O problema não é receber uma mensagem de erro.
O problema é ignorá-la.
Um erro analisado vira conhecimento.
Um erro escondido vira risco.
Capítulo VII — A zona de aprendizado: onde o desconforto começa a produzir valor
Depois da zona de medo, encontramos a zona de aprendizado.
É aqui que o profissional:
É importante notar que aprender não significa compreender tudo imediatamente.
Aprendizado costuma seguir uma sequência parecida com esta:
Primeiro, você nem sabe que algo existe.
Depois, percebe que não sabe.
Em seguida, tenta entender.
Comete erros.
Repete.
Reconhece padrões.
Executa com ajuda.
Executa sozinho.
Ensina outra pessoa.
Incorpora o conhecimento à sua zona de conforto.
Essa sequência aparece em praticamente qualquer tecnologia.
Capítulo VIII — Exemplo prático: aprendendo Git sem abandonar o mainframe
Vamos imaginar um programador COBOL chamado Ensign Bellacosa.
Ele trabalha há anos com membros em bibliotecas particionadas:
EMPRESA.SISTEMA.COBOL
EMPRESA.SISTEMA.JCL
EMPRESA.SISTEMA.COPY
Um dia, recebe a missão de aprender Git.
Etapa 1 — Zona de medo
Ele encontra termos como:
repositório;
commit;
branch;
merge;
clone;
pull request.
Tudo parece complicado.
Etapa 2 — Tradução para o universo conhecido
Ele começa a criar analogias:
Repositório: conjunto organizado de fontes.
Commit: fotografia lógica de uma alteração.
Branch: linha paralela de desenvolvimento.
Merge: combinação de alterações.
Histórico: registro de versões.
Pull request: solicitação formal de revisão e integração.
Agora os conceitos deixam de ser completamente alienígenas.
Etapa 3 — Primeiro laboratório
Ele cria uma pasta:
mkdir curso-cobol
cd curso-cobol
git init
Adiciona um programa:
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY 'OLA, FROTA ESTELAR'.
STOP RUN.
Depois executa:
git add HELLO.cbl
git commit -m "Primeiro programa COBOL"
Acabou de criar seu primeiro registro de versão.
Etapa 4 — Repetição
Depois de dez commits, o processo parece menos ameaçador.
Depois de cinquenta, tornou-se rotina.
O que aconteceu?
Git saiu da zona de medo, atravessou a zona de aprendizado e entrou na zona de conforto.
Capítulo IX — A zona de desenvolvimento proximal
Existe um conceito importante da psicologia da educação chamado zona de desenvolvimento proximal.
Ele descreve a distância entre:
aquilo que a pessoa já consegue fazer sozinha;
e aquilo que consegue realizar com apoio, orientação ou ferramentas.
Essa ideia combina perfeitamente com o aprendizado técnico.
Considere três desafios:
Desafio muito fácil
Alterar uma mensagem em um programa que você já conhece.
Resultado: pouca evolução.
Desafio adequado
Adicionar leitura de arquivo sequencial, com ajuda de um exemplo.
Resultado: exige esforço, mas é possível.
Desafio excessivo
Criar sozinho uma arquitetura corporativa distribuída com CICS, MQ, Kafka, APIs, Kubernetes, segurança e observabilidade, sem conhecer nenhum desses elementos.
Resultado: confusão e frustração.
O melhor desafio é aquele que fica um pouco além da habilidade atual.
Não precisa ser confortável.
Mas precisa ser alcançável.
Na Frota Estelar, um cadete não assume sozinho o comando de uma nave classe Galaxy em sua primeira aula.
Ele começa no simulador.
Depois participa de exercícios.
Recebe supervisão.
Assume tarefas menores.
Enfrenta o Kobayashi Maru.
Easter egg detectado.
O Kobayashi Maru não mede apenas conhecimento técnico. Ele mede comportamento diante de uma situação impossível. É um lembrete de que desenvolver profissionais também significa prepará-los para incerteza, pressão e decisões imperfeitas.
Capítulo X — A zona de crescimento
Na camada mais externa do modelo aparece a zona de crescimento.
Ela inclui:
encontrar propósito;
viver sonhos;
definir novas metas;
conquistar objetivos;
construir autonomia;
gerar impacto;
ajudar outras pessoas.
É importante entender que crescimento não significa ausência de medo.
Pessoas que crescem continuam sentindo insegurança.
A diferença é que aprenderam a agir mesmo sem garantia absoluta.
Um programador COBOL pode entrar nessa zona quando:
conquista sua primeira oportunidade;
resolve um incidente importante;
recebe uma certificação;
ministra sua primeira aula;
publica um artigo;
cria um projeto;
participa de uma comunidade;
moderniza uma aplicação;
integra COBOL com uma API;
torna-se referência para outros iniciantes.
O conhecimento deixa de ser apenas uma ferramenta de sobrevivência profissional.
Ele passa a servir a um propósito.
Capítulo XI — Propósito não é apenas cargo ou salário
Encontrar propósito não significa necessariamente tornar-se gerente, arquiteto ou executivo.
Um excelente programador pode encontrar propósito em:
manter sistemas críticos funcionando;
preservar conhecimento;
reduzir falhas;
ensinar novos profissionais;
melhorar a qualidade do código;
documentar aplicações antigas;
automatizar tarefas repetitivas;
simplificar processos;
construir soluções confiáveis.
No universo mainframe, existe uma dimensão especial de propósito.
Muitos programas COBOL sustentam processos invisíveis para a sociedade.
Quando alguém:
recebe um salário;
faz um pagamento;
utiliza um cartão;
contrata um seguro;
movimenta uma conta;
compra uma passagem;
consulta um benefício;
há grandes chances de algum sistema corporativo robusto estar trabalhando nos bastidores.
O programador talvez não apareça na tela.
Mas sua responsabilidade está presente em cada transação.
É o equivalente tecnológico da engenharia da nave: quase ninguém vê o núcleo de dobra durante uma viagem tranquila, mas todos dependem dele.
Capítulo XII — O crescimento não é linear
A imagem dos círculos pode dar a impressão de que seguimos uma sequência perfeita:
conforto → medo → aprendizado → crescimento.
Na vida real, o processo se parece mais com um job complexo contendo reinícios, condicionais e steps de recuperação.
Você pode avançar e depois recuar.
Pode dominar Git e sentir medo diante de Docker.
Pode aprender Docker e travar em Kubernetes.
Pode compreender APIs e sentir dificuldade com segurança.
Pode ter confiança técnica e insegurança ao apresentar uma palestra.
Cada habilidade possui seu próprio conjunto de círculos.
Você não está simplesmente “dentro” ou “fora” da zona de conforto.
Em alguns temas, é capitão.
Em outros, é cadete.
Essa compreensão produz humildade.
Um especialista em COBOL pode ser iniciante em Python.
Um especialista em cloud pode não compreender CICS.
Um cientista de dados pode nunca ter escrito JCL.
Um desenvolvedor Java pode se assustar com REDEFINES.
Todos possuem mapas diferentes.
Capítulo XIII — Nem todo desconforto gera crescimento
Aqui precisamos corrigir uma interpretação perigosa.
A frase “saia da zona de conforto” é frequentemente usada de forma irresponsável.
Nem todo desconforto é produtivo.
Existe uma diferença entre:
desafio;
sobrecarga;
ameaça;
ambiente abusivo;
pressão excessiva;
esgotamento.
Um profissional não cresce simplesmente porque está submetido a estresse constante.
Quando a exigência ultrapassa os recursos disponíveis, pode ocorrer:
ansiedade;
perda de concentração;
queda de desempenho;
medo de errar;
insônia;
desmotivação;
burnout.
A melhor aprendizagem acontece em uma zona de esforço administrável.
Em outras palavras:
Crescimento exige desafio, não destruição.
A Frota Estelar não envia uma nave sem combustível, sensores, equipe e plano apenas para “tirar a tripulação da zona de conforto”.
Ela prepara a missão.
Analisa riscos.
Define protocolos.
Treina os oficiais.
Estabelece rotas de contingência.
Essa é a diferença entre coragem e imprudência.
Capítulo XIV — O descanso também compila conhecimento
Existe outro detalhe esquecido pelos discursos de produtividade: o cérebro precisa de descanso.
Depois de estudar, praticar e enfrentar problemas, precisamos permitir que o conhecimento seja consolidado.
O descanso ajuda a:
organizar memórias;
reduzir fadiga;
melhorar atenção;
fortalecer associações;
recuperar energia.
Um estudante pode acreditar que oito horas seguidas de estudo produzirão oito vezes mais aprendizado do que uma hora.
Frequentemente, não produzirão.
Depois de certo ponto, a qualidade cai.
É semelhante a um sistema sobrecarregado.
Mais carga não significa necessariamente mais throughput.
Sem gerenciamento, pode significar contenção, fila, paginação e degradação.
Até o cérebro possui seu próprio WLM.
Curiosidade Bellacosa: ao estudar um assunto difícil, faça uma pausa e tente explicá-lo sem consultar o material. Essa recuperação ativa fortalece o aprendizado mais do que apenas reler o mesmo texto repetidamente.
Capítulo XV — Passo a passo para expandir sua zona de conforto
Agora vamos transformar o modelo em um plano prático.
Passo 1 — Mapeie sua zona atual
Pegue papel, Obsidian, bloco de notas ou planilha.
Crie três colunas:
DOMINO
ESTOU APRENDENDO
AINDA NÃO CONHEÇO
Exemplo:
DOMINO:
COBOL básico
JCL simples
Arquivo sequencial
ESTOU APRENDENDO:
VSAM
DB2
Git
AINDA NÃO CONHEÇO:
CICS
MQ
APIs
Ansible
OpenShift
Esse mapa reduz a sensação de caos.
Você não precisa aprender tudo ao mesmo tempo.
Passo 2 — Escolha apenas uma fronteira
Não tente estudar:
COBOL;
DB2;
CICS;
IMS;
MQ;
Python;
Git;
Docker;
Kubernetes;
IA;
na mesma semana.
Escolha uma missão.
Exemplo:
“Durante os próximos sete dias, vou aprender o básico de Git.”
Passo 3 — Defina um objetivo observável
Evite objetivos vagos:
“Quero entender Git.”
Prefira algo verificável:
“Vou criar um repositório, adicionar um programa COBOL e realizar cinco commits.”
Objetivos observáveis produzem evidência de progresso.
Passo 4 — Divida em pequenas tarefas
Exemplo de plano Git:
Dia 1: compreender repositório e commit.
Dia 2: instalar a ferramenta.
Dia 3: criar um repositório local.
Dia 4: adicionar um programa COBOL.
Dia 5: alterar e registrar versões.
Dia 6: criar uma branch.
Dia 7: revisar tudo.
Passo 5 — Crie um laboratório seguro
Nunca comece testando em produção.
Crie um ambiente onde errar não cause prejuízo.
Pode ser:
A zona de aprendizado precisa permitir experimentação.
Passo 6 — Registre erros e soluções
Crie um diário técnico.
Exemplo:
ERRO:
Commit falhou porque o Git não conhecia meu nome e e-mail.
SOLUÇÃO:
git config --global user.name "Vagner"
git config --global user.email "exemplo@email.com"
APRENDIZADO:
A identidade do autor precisa ser configurada.
Depois de alguns meses, esse diário se torna um manual pessoal.
Passo 7 — Ensine o que aprendeu
Explique a outra pessoa.
Escreva um post.
Grave um vídeo.
Produza um exemplo.
Ensinar obriga o cérebro a organizar o conhecimento.
Quando você consegue explicar um conceito de forma simples, normalmente começou a compreendê-lo de verdade.
Capítulo XVI — Um plano de 30 dias para o Padawan COBOL
Semana 1 — Consolidar o hangar
Revise:
Objetivo: fortalecer a base.
Semana 2 — Explorar o sistema
Estude:
JCL;
JOB;
EXEC;
DD;
DISP;
SYSOUT;
retorno de execução;
SDSF.
Objetivo: compreender como o programa é executado.
Semana 3 — Visitar uma nova fronteira
Escolha uma tecnologia:
Git;
DB2;
VSAM;
CICS;
Python;
Linux.
Objetivo: realizar um laboratório simples.
Semana 4 — Produzir evidência de crescimento
Crie:
um pequeno projeto;
documentação;
artigo;
apresentação;
repositório;
roteiro de aula.
Objetivo: transformar conhecimento em resultado visível.
Ao final dos trinta dias, você não dominará todo o universo.
Mas sua zona de conforto será maior.
Essa é a métrica correta.
Capítulo XVII — Curiosidades sobre o aprendizado
Curiosidade 1 — O especialista enxerga blocos
Iniciantes observam elementos isolados.
Especialistas reconhecem padrões completos.
Um iniciante vê cada linha de um READ.
Um especialista vê a estrutura inteira de processamento.
Esse agrupamento mental é chamado, em muitos contextos, de “chunking”.
Curiosidade 2 — Repetição sem reflexão pode cristalizar erros
Praticar é importante.
Mas praticar incorretamente pode fortalecer hábitos ruins.
Por isso, feedback é essencial.
Curiosidade 3 — Dificuldade moderada ajuda a memória
Quando precisamos fazer algum esforço para recuperar uma informação, a aprendizagem pode ser mais forte do que quando apenas a reconhecemos passivamente.
Curiosidade 4 — Explicar revela lacunas
Você pode acreditar que compreendeu um tema até tentar explicá-lo.
Nesse momento aparecem as áreas nebulosas.
Curiosidade 5 — Confiança vem depois da ação
Muitas pessoas esperam sentir confiança para começar.
Frequentemente, a ordem é inversa:
ação → prática → pequenos resultados → confiança.
O capitão não recebe confiança pronta em um pacote.
Ele a constrói missão após missão.
Capítulo XVIII — Easter eggs para a tripulação
Primeiro easter egg: o conceito de “ir onde ninguém jamais esteve” não descreve apenas exploração espacial. Também descreve o momento em que um desenvolvedor abre pela primeira vez uma tecnologia desconhecida e decide continuar mesmo sem compreender tudo.
Segundo easter egg: o comando PERFORM UNTIL é uma excelente metáfora para o aprendizado:
PERFORM ESTUDAR-E-PRATICAR
UNTIL WS-HABILIDADE = 'DOMINADA'
END-PERFORM
Mas tome cuidado para não criar um loop infinito por falta de condição de saída.
Terceiro easter egg: Spock representa análise lógica, Kirk representa iniciativa, Scotty representa domínio técnico e McCoy representa o elemento humano. Um bom profissional precisa dos quatro aspectos:
lógica;
ação;
competência;
humanidade.
Quarto easter egg: Data possuía acesso a uma quantidade gigantesca de informações, mas passou anos aprendendo contexto, humor, empatia e julgamento. Conhecimento não é apenas acumular dados. É aprender quando, por que e como utilizá-los.
Quinto easter egg: “resistir é inútil” pode ser uma frase Borg, mas também descreve o mercado tecnológico. A mudança acontece. A escolha está entre enfrentá-la com consciência ou ser surpreendido por ela.
Capítulo XIX — O que fazer quando o medo aparecer
Quando sentir medo diante de uma nova tecnologia, execute este protocolo:
1. Nomeie o medo
Não diga apenas:
“Isso é difícil.”
Pergunte:
Tenho medo de errar?
Tenho medo de parecer iniciante?
Não conheço os pré-requisitos?
O material está avançado demais?
Estou tentando aprender muitas coisas?
Preciso de ajuda?
2. Reduza o tamanho da missão
Em vez de “aprender Kubernetes”, tente:
“Compreender o que é um pod.”
Em vez de “dominar DB2”, tente:
“Executar um SELECT simples.”
Em vez de “aprender CICS”, tente:
“Entender o que é uma transação.”
3. Encontre uma analogia
Conecte o novo ao conhecido.
Exemplo:
API como uma interface formal entre sistemas;
commit como um ponto de controle;
branch como uma linha paralela;
container como um ambiente empacotado;
pipeline como um fluxo automatizado de steps.
4. Faça um teste pequeno
O conhecimento abstrato assusta mais do que um laboratório concreto.
5. Registre a vitória
Não espere um grande certificado para reconhecer progresso.
Seu primeiro programa compilado já é uma vitória.
Seu primeiro commit também.
Seu primeiro SELECT, sua primeira API e seu primeiro playbook também.
Conclusão — A zona de conforto não é abandonada; ela é ampliada
A principal lição da imagem não é que devemos fugir da segurança.
Também não significa que precisamos viver permanentemente sob pressão.
A zona de conforto é importante.
Ela contém tudo o que já conquistamos.
É nosso arquivo histórico de competências.
É o conjunto de rotinas que dominamos.
É a base de onde partimos.
O crescimento acontece quando utilizamos essa base para explorar uma nova região.
Primeiro aparece o medo.
Depois, o aprendizado.
Em seguida, a nova habilidade.
Finalmente, aquilo que parecia impossível torna-se familiar.
O jovem programador que hoje se assusta com JCL amanhã submeterá jobs naturalmente.
Quem hoje teme DB2 amanhã analisará SQLCODE.
Quem hoje não entende Git amanhã fará commits, branches e merges.
Quem hoje olha para APIs como um universo distante amanhã poderá integrar programas COBOL a aplicações modernas.
A nave não precisa abandonar seu porto para sempre.
Ela parte, explora, aprende e retorna maior do que antes.
E cada missão amplia o mapa.
Portanto, Padawan COBOL, não pergunte apenas:
“Como posso sair da minha zona de conforto?”
Pergunte:
“Qual pequeno desafio posso enfrentar hoje para tornar minha zona de conforto maior amanhã?”
Talvez seja compilar seu primeiro programa.
Talvez seja entender um JCL.
Talvez seja aprender Git.
Talvez seja estudar DB2, CICS, MQ, Linux, Python, Ansible ou inteligência artificial.
Não importa qual seja a fronteira.
Escolha uma.
Dê um passo.
Registre o aprendizado.
Ajude outro tripulante.
Depois escolha a próxima.
Porque o verdadeiro profissional não é aquele que nunca sente medo.
É aquele que aprendeu a transformar o desconhecido em conhecimento, o conhecimento em competência e a competência em serviço para toda a tripulação.
Vida longa e próspera.
E que todos os seus jobs terminem com:
MAXCC=0000
☕🖖🚀
