$ portaldoshell

crônica · 6 min de leitura

Como era programar sem internet

A dúvida que fica com você por dias forma mais que a resposta que chega em segundos.

$ whoami
Julio Cezar Neves

Um programador de óculos, mão na testa, folheia uma listagem grossa numa sala de computadores antigos, com fitas magnéticas e um relógio na parede. Ao lado, um cachorro de óculos lê um livro de capa escura. Sobre a mesa, pilhas de papel, cartões perfurados e um teletipo imprimindo em formulário contínuo.

A escassez de respostas formou programadores melhores do que a abundância costuma formar. Digo isso com a autoridade de quem programou durante décadas sem internet e com o devido desconto da nostalgia. Naquela época, uma dúvida técnica tinha peso físico. Ela acompanhava o caminho de volta para casa e aparecia no meio do jantar com a mesma cara da véspera. Quem viveu isso sabe que estou sendo moderado, e quem chegou depois provavelmente acha que é exagero de veterano.

Programar sem internet era programar com escassez deliberada. Talento e vontade sobravam, e o que faltava era a resposta rápida. Essa escassez produzia um efeito colateral que a abundância de hoje ainda procura substituir: ela obrigava a pensar antes de perguntar. A pergunta chegava ao colega já mastigada, porque mastigar era a única alternativa disponível.

A documentação era levada a sério porque precisava ser. Livros técnicos e manuais de fabricante ocupavam espaço real nas mesas e eram estudados com a atenção que hoje reservamos para contrato de trabalho. Quando alguém encontrava uma explicação clara para um problema difícil, aquela página ganhava valor imediato e circulava entre colegas como moeda de troca. Valia porque era escassa.

Hoje a informação é tão abundante que virou descartável. Naquela época, ela precisava ser encontrada e, muitas vezes, copiada à mão. Quando algo é escasso, a gente cuida; quando é abundante, a gente confia que vai encontrar de novo. Essa confiança tem um custo que aparece só na hora do aperto, quando a página salva nos favoritos mudou de endereço.

Os computadores também impunham disciplina. Cada minuto de processamento custava caro, e o erro saía pelo preço do minuto multiplicado pela fila. Isso incentivava uma prática hoje em extinção, que era analisar o problema antes de apertar Enter. Boa parte do trabalho acontecia antes da execução, com o programa rodando primeiro na cabeça e só depois na máquina. A técnica continua funcionando, mas hoje concorre com dezenas de abas abertas ao mesmo tempo, e as abas costumam vencer.

Lembro dos cartões perfurados com uma clareza que me surpreende. Um programa era uma pilha física de cartões, e bastava um tropeço para transformar uma sequência organizada numa atividade recreativa de reordenação. Quem viveu isso desenvolveu uma relação especial com a organização, ou com a resignação, dependendo do dia e da altura da queda.

Os cartões davam ao programa uma existência física. Era possível segurá-lo nas mãos e também derrubá-lo no chão, o que transformava conceitos teóricos sobre sequência lógica em problemas concretos e urgentes. Computadores sempre foram excelentes professores e sempre cobraram caro pelas aulas. Numerar os cartões a caneta, na lateral da pilha, era o controle de versão da época, e funcionava melhor que muito repositório atual.

A relação com os colegas mais experientes também seguia outro protocolo. Toda equipe tinha suas referências técnicas, gente que acumulava anos de convivência com um sistema ou com um equipamento específico. A consulta a essas pessoas tinha ritual próprio e acontecia depois de várias tentativas, quando o problema já vinha estudado e com as hipóteses fracas descartadas. A conversa começava num nível em que valia a pena conversar.

Uma boa pergunta era tratada como recurso raro. Quando bem formulada, economizava o tempo de todo mundo; quando mal formulada, rendia uma aula involuntária sobre contexto, com duração proporcional à preguiça de quem perguntou. A tecnologia evoluiu bastante desde então, e o contexto continua cobrando ingresso. Muita gente resolvia o próprio problema no meio da tentativa de explicá-lo ao colega, o que talvez seja a forma mais antiga de depuração.

Quando comecei a trabalhar com Unix, encontrei uma filosofia que carrego até hoje: ferramentas simples e combináveis, cada uma fazendo bem uma única coisa, com o resultado nascendo da composição. A ideia parece óbvia, como todas as boas ideias depois que alguém as inventa. O pipe do shell resume essa filosofia em um caractere. O Unix me ensinou que a elegância técnica depende de clareza, e a complexidade costuma ser o disfarce de quem ainda está procurando a clareza.

Uma solução bem construída pode ser entendida por outras pessoas. Uma solução elaborada demais costuma exigir a presença permanente do autor para continuar funcionando. Daí nasce uma situação que existe até hoje em versão atualizada: alguns profissionais se tornam indispensáveis e outros apenas incompreensíveis. O mercado costuma confundir os dois por tempo suficiente para o estrago ficar pronto.

Sem internet, o aprendizado exigia paciência de outro calibre. Uma dúvida podia ficar aberta por dias, até a resposta chegar por telefone ou surgir num grupo de usuários que se reunia pessoalmente para trocar experiências. Algumas respostas apareciam só depois de muita tentativa malsucedida, com um nível de frustração que hoje teria diagnóstico. Naquela época, isso se chamava trabalho.

O erro fazia parte do processo, como faz até hoje, e mantinha os mesmos hábitos. Escolhia o pior momento para aparecer e trazia a informação mais incompleta possível. A tecnologia muda depressa, e os problemas preservam certas tradições com uma fidelidade admirável. Quem passou por isso aprendeu a desconfiar do programa que funciona de primeira, porque o erro costuma estar apenas esperando o momento mais caro.

Havia também outra relação com a leitura. Ler documentação fazia parte da profissão e, em alguns ambientes, da sobrevivência. Hoje encontro profissionais competentes com acesso instantâneo a uma quantidade impressionante de conhecimento, e percebo que muitos tratam a busca como a etapa final do raciocínio. Prefiro tratá-la como etapa intermediária: primeiro entender, depois confirmar. Quem inverte a ordem costuma chegar a certezas muito bem formatadas.

Em quase seis décadas trabalhando com computadores, vi equipamentos desaparecerem e conceitos definitivos serem substituídos por outros conceitos igualmente definitivos. A palavra "definitivo" tem uma carreira bastante instável na tecnologia. Talvez por isso eu tenha aprendido a apostar em princípios, que envelhecem melhor que os modismos. Clareza e organização eram úteis quando os computadores ocupavam salas inteiras e continuam úteis agora que cabem no bolso.

O traço comum entre os melhores profissionais que conheci foi sempre a disposição para aprender, e a ferramenta da vez entrava como detalhe. A época sem internet, com toda a sua lentidão, produzia esse aprendizado de um jeito que deixava marca. Cada resposta conquistada ampliava a compreensão do sistema e da própria profissão, num grau que a resposta encontrada em três segundos raramente alcança.

Hoje temos acesso instantâneo ao conhecimento e ferramentas inteligentes à disposição, e agradeço por isso com sinceridade. Ainda assim, mantenho uma admiração específica por aquele período, porque foi ele que me ensinou que a dúvida que fica com você por dias forma mais que a resposta que chega em segundos. Talvez os computadores fossem lentos, e talvez nós também fôssemos. Essa última hipótese ainda merece investigação.

PS: Se você trabalhou antes da internet comercial, conte nos comentários qual era a sua principal fonte de consulta técnica, fosse um livro surrado ou aquele colega que sabia tudo do sistema. Tenho interesse genuíno nessa resposta. Suspeito que alguns comentários vão virar documento histórico sem a menor intenção de fazê-lo.

$ cat comentarios.log

lendo o log…

$ ./comentar.sh --artigo como-era-programar-sem-internet

* obrigatório. Todo comentário passa pelo root antes de entrar no log, e o root daqui é humano.