Entrevista com minha mãe, programadora COBOL de mainframe (2016)

 (ezali.substack.com)
2 pontos por GN⁺ 2023-12-15 | 1 comentários | Compartilhar no WhatsApp

Entrevista com minha mãe, programadora COBOL de mainframe

  • Minha mãe trabalha em um dos maiores bancos da UE desde antes de eu nascer.
  • O mundo da programação bancária é completamente diferente daquele com o qual a maioria das pessoas está acostumada.
  • Se minha mãe e a equipe dela parassem de trabalhar, o banco quebraria em poucas semanas.

1991

  • Minha mãe começou o treinamento interno no Nordbanken (hoje Nordea).
  • Fez vários testes e passou em testes de QI, avaliações psicológicas e testes de multitarefa.
  • Começou como programadora COBOL de mainframe IBM e, 25 anos depois, ainda exerce a mesma função no mesmo banco.

COBOL

  • COBOL não é uma linguagem de programação elegante como a funcional Haskell ou a concorrente Golang.
  • COBOL é uma linguagem imperativa e procedural, e é orientada a objetos desde 2002.
  • No contexto da programação para mainframe, quase não há gente que conheça COBOL.

Banco de dados

  • O banco de dados principal se chama IMS, um banco de dados hierárquico criado pela IBM para o programa Apollo.
  • Há tentativas de migração para DB2, mas esse é um trabalho que levará anos.
  • O banco de dados DB2 atualmente armazena cerca de 10 TB de dados.

Batch

  • Cerca de 80% do sistema é composto por jobs batch.
  • Os jobs batch são executados em horários ou intervalos específicos, processando dados ou enviando dados para outros bancos/instituições.

Problemas que os bancos enfrentam

  • Bancos que usam mainframes têm muitos problemas com os quais precisam lidar.
  • Os programadores estão envelhecendo, e novos funcionários levam de 2 a 3 anos até conseguirem trabalhar de forma independente.
  • Existem programas com décadas de existência, e ninguém sabe o que eles fazem.

Palavras finais

  • É muito interessante pensar quais novas tecnologias o Nordea e outros bancos vão adotar nos próximos anos.

Perguntas e respostas

  • Por que escolheu programação COBOL em mainframe IBM? Porque queria trabalhar com computadores.
  • Qual foi a pior coisa que aconteceu durante um dia de trabalho? Um colega esqueceu um ponto em um módulo importante do sistema, e o banco ficou fora do ar por 16 horas.
  • Como será o futuro dos bancos? Eles reconhecem que precisam substituir os mainframes por algo moderno.
  • Quais desafios você enfrentou como mulher programadora nos anos 90? Nenhum problema.
  • Trabalhar mais de 20 anos com a mesma base de código fica entediante? Construir sistemas novos sempre foi divertido.
  • Escrever código para bancos dá medo? Muito medo, mas o ambiente de testes é sólido, então na maior parte do tempo tudo corre bem.
  • Você já cometeu algum grande erro para o banco? Em 1997, cometi um erro que permitia sacar dinheiro ilegalmente de contas de poupança para aposentadoria.
  • Como é o ambiente de trabalho? Saíram de mesas individuais para um espaço aberto, e ela odeia muito isso.

Opinião do GN⁺

  • Mainframes e a linguagem COBOL ainda desempenham um papel importante no setor financeiro, e a especialização nessa tecnologia é muito valiosa.
  • A complexidade dos sistemas bancários e a dependência de tecnologias antigas dificultam a transição para sistemas novos, o que é um grande desafio.
  • Esta entrevista mostra que, em comparação com o rápido avanço da tecnologia, alguns setores ainda usam tecnologias antigas, criando um contraste interessante.

Leituras relacionadas

1 comentários

 
GN⁺ 2023-12-15
Comentários do Hacker News

  • A submissão original ao HN em 2016 foi https://news.ycombinator.com/item?id=12096250
    Se você está procurando mais leituras sobre o tema “o mundo da programação bancária é um mundo completamente diferente daquele com que a maioria de nós está acostumada”, An oral history of Bank Python também é uma boa: https://calpaterson.com/bank-python.html
    Também apareceu no HN antes: https://news.ycombinator.com/item?id=29104047

    • É surpreendente pensar que já faz 7 anos. Eu queria entrevistar minha mãe sobre as histórias de quando ela programava mainframes com o Michigan Algorithm Decoder, mas acabei não conseguindo
      https://news.ycombinator.com/item?id=12097032

  • As pessoas costumam pensar: “se você é um programador de mainframe de 20 anos, a idade tem um valor enorme, então deve receber um salário alto”, mas a realidade geralmente é mediana, ou até abaixo da média, o que cria um problema no pipeline de talentos
    O que realmente tem valor não é a habilidade em si, como “saber COBOL”, mas o conhecimento organizacional sobre a enorme lógica de negócio acumulada dentro do COBOL. Um desenvolvedor mediano também consegue aprender COBOL, mas quando um programador COBOL aposentado volta com um contrato de US$ 500 mil por ano, não é por causa do COBOL, e sim por causa do conhecimento institucional acumulado
    Se bancos e instituições realmente pagassem muito bem a jovens programadores de mainframe, o problema demográfico atual teria sido menos grave

    • Na pós-graduação, conheci alguém que estava nessa situação. Ele trabalhava em um banco e foi demitido durante a crise financeira; o banco tentou migrar os sistemas existentes para algo como Java
      Eles acharam que o projeto estava quase concluído e que, como a equipe de reescrita já tinha se familiarizado o suficiente com COBOL, conseguiria terminar o restante sem ele. Na prática, porém, embora entendessem COBOL, precisavam desesperadamente do conhecimento institucional dele. No fim, ele voltou em meio período, cobrando uma taxa de consultoria absurdamente alta, até a transição terminar, e nesse meio-tempo fez a pós-graduação para desenvolver suas competências
    • Trabalhei com sistemas centrais em COBOL em uma grande seguradora e concordo totalmente. A empresa não pagava pelo conhecimento de COBOL em si, mas pelas pessoas que conheciam as peculiaridades e armadilhas não documentadas dentro do código
      Um programador razoável consegue ler um programa COBOL e acompanhá-lo. Mas não sabe por que uma exportação essencial morre durante a extração de dados para um arquivamento 10-K. O motivo era que alguém presumiu que uma certa contagem de registros não passaria de 3000 e codificou de forma fixa para simplesmente gerar erro quando esse valor fosse ultrapassado
    • No meu primeiro emprego, trabalhei com mainframes de bancos/seguros, e o ambiente de trabalho era bem ruim, desde coisas pequenas como código de vestimenta até coisas complicadas como uma base de código legada terrivelmente antiga. Se pagassem bem, eu teria aguentado, mas nem isso acontecia
      Na prática, eu ganhava muito menos do que no meu emprego anterior instalando infraestrutura física de cabos, ou seja, fibra óptica e Ethernet de cobre; escolhi aquele trabalho basicamente porque o escritório tinha ar-condicionado. Não era algo que eu quisesse transformar em carreira
      Quando trabalhei como administrador de sistemas Windows de nível intermediário em suporte telefônico a clientes de um provedor de nuvem, eu ganhava quase 30% a mais do que como responsável júnior por mainframe em bancos/seguradoras. Mesmo sendo uma tecnologia rara e em um setor de alto valor, o trabalho com mainframe era muito menos recompensado, e naquela empresa os desenvolvedores de mainframe eram os menos remunerados entre os desenvolvedores em todos os níveis de carreira. Quem era remunerado de forma adequada eram apenas os contratados independentes que tinham trabalhado lá por 30 anos antes de se aposentar
    • Tenho experiência com COBOL, já trabalhei em mainframe e estaria disposto a fazer de novo. Para os padrões de programadores COBOL, ainda sou jovem, então alguém poderia me aproveitar por mais 20 anos
      Mas os salários desses cargos são péssimos em comparação com o que se pode receber com outras tecnologias, e a vida moderna pressiona fortemente a buscar salários maiores
    • Isso acontece de verdade. Trabalhei em um banco multinacional sediado nos EUA, e a equipe da matriz criou um programa chamativo para atrair recém-formados em ciência da computação
      Esse programa oferecia o valor de mercado “justo” para cargos de entrada no setor e fazia a pessoa passar por 2 ou 3 equipes ou departamentos no primeiro ano. Ao final, se a empresa ainda gostasse do candidato, ele podia escolher a equipe em que entraria como funcionário efetivo, mas não havia aumento salarial, e, naquele ponto, as pessoas que não tinham conseguido entregar resultados rapidamente já tinham sido filtradas
      Do ponto de vista da empresa, o resultado foi excelente. Eles conseguiam jovens programadores mais proficientes em COBOL do que seus novos colegas por US$ 60 mil a US$ 70 mil por ano, enquanto colegas sêniores ou com longo tempo de casa recebiam, conforme o caso, US$ 200 mil a US$ 400 mil

  • Minha avó programava com cartões perfurados, mas não sei em que hardware, e agora já é tarde para perguntar. Meu pai trabalhou bastante com Fortran e COBOL em mainframes soviéticos e, depois, fez muito trabalho de Y2K nos EUA
    O objeto mais legal entre esses é uma impressão de um programa Fortran que ele rasgou em três pedaços para embrulhar um filme grande de 64 mm de fotos de montanhas que havia tirado antigamente. Provavelmente veio de um mainframe Minsk-32; o nome do programa é MATR1, ele faz manipulação de matrizes e os comentários mencionam terreno. Hoje está emoldurado na parede perto da minha bancada
    Eu também programei em várias linguagens a vida inteira, e agora meu filho adolescente está se interessando por programação, fazendo Java e Python no ensino médio. Rumo à quarta geração de programadores

    • Parece uma ideia de filme em que a mesma base de código é passada de geração em geração. O título Código legado combinaria

  • Se estiver correto dizer que, do ponto de vista técnico, esse é o cargo mais importante do banco, então, considerando a participação de mercado do Nordea na Suécia e nos países nórdicos, se aquela equipe desaparecer, a economia sueca — e talvez até a nórdica — pode balançar. Isso provavelmente também teria um impacto considerável na UE.
    Depois de ler esse texto, fiquei me perguntando se esses programadores COBOL, que mantêm bancos assim funcionando, não seriam um fator ônibus absurdamente subestimado em várias economias do mundo. Também fico curioso para saber qual é o plano de contingência para uma situação dessas.
    [0] https://en.wikipedia.org/wiki/Nordea

    • Fico me perguntando se programadores APL estão numa situação parecida. Sei que um bom número de grandes empresas usa APL.
    • O plano de contingência para uma situação dessas pode ser, de forma infame, parar de funcionar por algumas semanas: https://en.wikipedia.org/wiki/TSB_Bank_(United_Kingdom)#Migration_to_the_Sabadell_Proteo_banking_platform
      Acho que a perda de conhecimento institucional deve ter sido um grande fator naquele desastre.
    • Como programador que já foi atropelado por um ônibus — e justamente pelo ônibus em que eu tinha passado 5 horas até o ponto final no oeste da Grécia — digo que o risco de morrer atropelado por um carro é muito maior.
      Some a isso o aumento nas vendas de SUVs, que são mais perigosos para pedestres e ciclistas, e talvez seja até surpreendente que bancos não desabem por causa de programadores mortos, mas sim por má contabilidade e fraude.

  • O trecho “eu tinha uma mesa própria, mas agora me mudaram para um espaço aberto em que você escolhe qualquer lugar para sentar, e eu odeio isso” me pegou de um jeito estranho, mesmo eu nunca tendo trabalhado com mainframe.

    • Eu também prefiro muito mais uma mesa própria. É muito natural uma pessoa configurar o ambiente de acordo com seus gostos e preferências, e não entendo como alguns projetistas de escritórios não levam isso em conta.
    • Fico me perguntando se, como no nosso caso, a maioria dos escritórios também chama isso de “assentos flexíveis”, mas na prática todo mundo tem seu lugar e, quando chega ao trabalho, senta sempre na mesma mesa, e em geral todos respeitam isso.
      Como a cadeira, a posição e o brilho do monitor, a altura da mesa etc. ficam ajustados para cada pessoa, o próprio conceito de hot desking vira uma piada. Eu preferia que desistissem oficialmente disso.

  • Quando trabalhei como consultor de integração de sistemas na área de serviços financeiros, precisei fazer muitas integrações com esses sistemas de core banking.
    Normalmente, negociar uma interface totalmente nova gerava tanto atrito técnico, de negócios e de conformidade regulatória que o projeto podia facilmente atrasar um ou dois anos ou mais, então tentávamos reutilizar pontos de integração existentes de projetos anteriores.
    A integração geralmente consistia em entregar documentos estruturados antes de um horário específico da noite para processamento em lote noturno. Documentos de dados baseados em offsets incluem, por design, áreas ainda não alocadas para futuras atualizações e usos; quando novas informações são necessárias, negocia-se quais bytes podem ser usados.
    Do lado da extração de dados, às vezes se procura uma API mais “moderna”, mas não se deve esperar algo muito granular como REST. Era comum ter reuniões com equipes de regulação e compliance para encontrar formas de evitar desenvolvimento novo e caro.
    Além disso, muitas vezes o pessoal de compliance era muito mais pragmático e orientado a soluções do que o pessoal de TI. Convencer nossa própria equipe de que a redação de uma norma não precisava necessariamente ser interpretada literalmente da forma mais restritiva possível era, muitas vezes, mais difícil do que chegar a um acordo com o pessoal de compliance.
    Ao imaginar essa camada de integração acumulada ao longo de décadas e centenas de projetos, dá para começar a entender por que a substituição do core system é tão difícil.

  • Minha sogra trabalhou a vida toda no departamento de TI de uma seguradora. Ela não programava muito, mas, com o tempo, virou uma fonte de conhecimento de domínio.
    Há muitas histórias antigas. Antes de sistemas computacionais de verdade, obviamente tudo era armazenado em documentos físicos, e o primeiro projeto dela após a faculdade foi visitar escritórios satélites para reorganizar o sistema de arquivos das filiais de acordo com uma nova estratégia definida pela matriz.
    Enquanto a equipe literalmente tirava todos os documentos, trocava as etiquetas e colocava tudo de volta, as atividades daquela filial paravam, e o projeto inteiro levou mais de um ano. Isso mudou um pouco minha perspectiva sobre o meu trabalho.

    • Pensando em como os bancos daquela época levavam o papel ao limite, é difícil imaginar a complexidade de um banco moderno. Não sei o bastante sobre finanças nem para saber por onde começar a ter uma noção.

  • Eu deveria ter conversado mais com minha avó antes de ela desenvolver demência. Eu sabia que ela era matemática e programadora, mas, numa conversa rápida alguns anos atrás, ela disse que trabalhava calculando órbitas de satélites na União Soviética.
    Espero que fossem ao menos satélites.

    • Estou numa situação parecida. Minha mãe trabalhou com simulações de software para o sistema AEGIS. Não era algo comum para uma mulher negra nos anos 1980.
      Aos 20 anos, formou-se em matemática em 3 anos e, nos anos 1970, programava computadores com cartões perfurados.
      Hoje ela nem consegue amarrar os sapatos de forma confiável. Espero que vocês registrem as conquistas e histórias de vida das pessoas que amam antes que seja tarde demais.
    • Se você já pensou em fazer algo assim, recomendo muito que faça. Se estiver pensando em como começar, recomendo o app StoryCorps.
      Ele é fácil de usar, tem muitas perguntas prontas e também permite criar suas próprias perguntas. Você grava direto no celular e, se quiser, também pode enviar a entrevista para a Biblioteca do Congresso dos EUA.
      https://storycorps.org/participate/storycorps-app/
    • Poderiam ter sido os dois: https://en.wikipedia.org/wiki/Fractional_Orbital_Bombardment_System#Development_history_and_deployment

  • Minha avó fez 95 anos este ano. Ela ainda vai todos os dias a um instituto de pesquisa no antigo bloco soviético e escreve simulações numéricas em Fortran e Maple.
    Os colegas dela ainda não querem que ela se aposente, e ela também adia a aposentadoria a cada ano. Ela tem um conhecimento excepcional de análise numérica e matemática, e tenho muito orgulho dela.

  • Meu primeiro emprego como programadora foi em uma empresa de transporte, onde havia muitos programadores com mais de 15 a 20 anos de casa, e muitos deles faziam principalmente a manutenção do COBOL que tocava o negócio.
    Entre esses programadores seniores havia muitas mulheres; no grupo sênior, a impressão era de que elas passavam de 50%. O triste era que, entre os programadores jovens, ainda havia um número razoável de mulheres, mas, em geral, eram homens.
    Como a empresa recrutava principalmente em faculdades de engenharia da região, parecia um caso interessante que mostrava como, com o tempo, diminuiu o número de mulheres entrando em cursos de engenharia de software.

    • Lembro de ter ouvido que, antigamente, programação de computadores era vista como algo parecido com datilografia ou trabalho de secretária, então no início atraía principalmente mulheres.