MANTER UM PROGRAMA NA CABEÇA

Agosto de 2007

Um bom programador trabalhando intensivamente em seu próprio código pode mantê-lo em sua mente da mesma forma que um matemático mantém um problema no qual está trabalhando. Matemáticos não respondem a perguntas trabalhando-as no papel da maneira como as crianças em idade escolar são ensinadas a fazer. Eles fazem mais em suas cabeças: eles tentam entender um espaço de problema o suficiente para que possam andar por ele da mesma forma que você pode andar pela memória da casa em que cresceu. No seu melhor, a programação é a mesma coisa. Você mantém todo o programa em sua cabeça e pode manipulá-lo à vontade.

Isso é particularmente valioso no início de um projeto, porque inicialmente a coisa mais importante é ser capaz de mudar o que você está fazendo. Não apenas resolver o problema de uma maneira diferente, mas mudar o problema que você está resolvendo.

Seu código é seu entendimento do problema que você está explorando. Portanto, é apenas quando você tem seu código em sua cabeça que você realmente entende o problema.

Não é fácil colocar um programa em sua cabeça. Se você deixar um projeto por alguns meses, pode levar dias para realmente entendê-lo novamente quando você voltar a ele. Mesmo quando você está trabalhando ativamente em um programa, pode levar meia hora para carregá-lo em sua cabeça quando você começa a trabalhar a cada dia. E esse é o melhor caso. Programadores comuns trabalhando em condições típicas de escritório nunca entram nesse modo. Ou, para colocar de forma mais dramática, programadores comuns trabalhando em condições típicas de escritório nunca realmente entendem os problemas que estão resolvendo.

Mesmo os melhores programadores nem sempre têm todo o programa em que estão trabalhando carregado em suas cabeças. Mas existem coisas que você pode fazer para ajudar:

Evite distrações. As distrações são ruins para muitos tipos de trabalho, mas especialmente ruins para a programação, porque os programadores tendem a operar no limite dos detalhes que podem lidar.

O perigo de uma distração não depende de quanto tempo ela dura, mas de quão confusa ela deixa seu cérebro. Um programador pode sair do escritório e ir buscar um sanduíche sem perder o código em sua cabeça. Mas o tipo errado de interrupção pode limpar seu cérebro em 30 segundos.

Curiosamente, as distrações programadas podem ser piores do que as não programadas. Se você sabe que tem uma reunião em uma hora, nem mesmo começa a trabalhar em algo difícil.

Trabalhe em longos períodos. Como há um custo fixo cada vez que você começa a trabalhar em um programa, é mais eficiente trabalhar em algumas sessões longas do que em muitas curtas. Haverá, é claro, um ponto em que você ficará estúpido porque está cansado. Isso varia de pessoa para pessoa. Ouvi falar de pessoas que ficam hackeando por 36 horas seguidas, mas o máximo que consegui foi cerca de 18, e eu trabalho melhor em pedaços de no máximo 12.

O ideal não é o limite que você pode suportar fisicamente. Há uma vantagem, além de um custo, de dividir um projeto. Às vezes, quando você volta a um problema depois de um descanso, você descobre que sua mente inconsciente deixou uma resposta esperando por você.

Use linguagens sucintas. Linguagens de programação mais poderosas tornam os programas mais curtos. E os programadores parecem pensar nos programas, pelo menos parcialmente, na linguagem que estão usando para escrevê-los. Quanto mais sucinta a linguagem, mais curto o programa e mais fácil de carregar e manter em sua cabeça.

Você pode amplificar o efeito de uma linguagem poderosa usando um estilo chamado programação bottom-up, onde você escreve programas em múltiplas camadas, as inferiores atuando como linguagens de programação para as superiores. Se você fizer isso corretamente, só precisa manter a camada superior em sua cabeça.

Mantenha reescrevendo seu programa. Reescrever um programa muitas vezes resulta em um design mais limpo. Mas teria vantagens mesmo que não fosse: você precisa entender completamente um programa para reescrevê-lo, então não há melhor maneira de carregá-lo em sua cabeça.

Escreva um código relível. Todos os programadores sabem que é bom escrever código legível. Mas você mesmo é o leitor mais importante. Especialmente no início; um protótipo é uma conversa com você mesmo. E ao escrever para você mesmo, você tem diferentes prioridades. Se você está escrevendo para outras pessoas, você pode não querer tornar o código muito denso. Algumas partes de um programa podem ser mais fáceis de ler se você as espalhar, como um livro didático introdutório. Enquanto se você está escrevendo código para facilitar o recarregamento em sua cabeça, pode ser melhor optar pela brevidade.

Trabalhe em pequenos grupos. Quando você manipula um programa em sua cabeça, sua visão tende a parar na borda do código que você possui. Outras partes você não entende tão bem e, o que é mais importante, não pode tomar liberdades. Então, quanto menor o número de programadores, mais completamente um projeto pode mutar. Se há apenas um programador, como geralmente acontece no início, você pode fazer redesenhos abrangentes.

Não tenha várias pessoas editando o mesmo pedaço de código. Você nunca entende o código de outras pessoas tão bem quanto o seu próprio. Não importa o quão minuciosamente você o tenha lido, você apenas o leu, não o escreveu. Então, se um pedaço de código é escrito por vários autores, nenhum deles o entende tão bem quanto um único autor.

E, é claro, você não pode redesenhar com segurança algo em que outras pessoas estão trabalhando. Não é apenas que você teria que pedir permissão. Você nem mesmo deixa a si mesmo pensar em tais coisas. Redesenhar código com vários autores é como mudar leis; redesenhar código que você controla sozinho é como ver a outra interpretação de uma imagem ambígua.

Se você quiser colocar várias pessoas para trabalhar em um projeto, divida-o em componentes e dê cada um a uma pessoa.

Comece pequeno. Um programa fica mais fácil de manter em sua cabeça à medida que você se familiariza com ele. Você pode começar a tratar partes como caixas pretas assim que se sentir confiante de que as explorou completamente. Mas quando você começa a trabalhar em um projeto, você é forçado a ver tudo. Se você começar com um problema muito grande, você pode nunca conseguir abrangê-lo completamente. Então, se você precisa escrever um programa grande e complexo, o melhor caminho para começar pode não ser escrever uma especificação para ele, mas escrever um protótipo que resolva um subconjunto do problema. Quaisquer que sejam as vantagens do planejamento, elas são frequentemente superadas pelas vantagens de poder manter um programa em sua cabeça.

É impressionante como os programadores muitas vezes conseguem atingir os oito pontos por acidente. Alguém tem uma ideia para um novo projeto, mas porque não é oficialmente sancionado, ele tem que fazê-lo em horas extras - que se revelam mais produtivas porque não há distrações. Impulsionado por seu entusiasmo pelo novo projeto, ele trabalha nele por muitas horas seguidas. Porque inicialmente é apenas um experimento, em vez de uma linguagem "de produção", ele usa uma mera linguagem "de script" - que é, na verdade, muito mais poderosa. Ele reescreve completamente o programa várias vezes; isso não seria justificável para um projeto oficial, mas este é um trabalho de amor e ele quer que seja perfeito. E como ninguém vai vê-lo exceto ele, ele omite quaisquer comentários, exceto o tipo "nota para si mesmo". Ele trabalha em um pequeno grupo por necessidade, porque ele ou não contou a ninguém mais sobre a ideia ainda, ou ela parece tão pouco promissora que ninguém mais tem permissão para trabalhar nela. Mesmo que haja um grupo, eles não poderiam ter várias pessoas editando o mesmo código, porque ele muda rápido demais para que isso seja possível. E o projeto começa pequeno porque a ideia é pequena no início; ele apenas tem uma maneira legal de tentar algo.

Ainda mais impressionantes são o número de projetos oficialmente sancionados que conseguem fazer as oito coisas erradas. Na verdade, se você olhar para a maneira como o software é escrito na maioria das organizações, é quase como se eles estivessem deliberadamente tentando fazer as coisas erradas. Em certo sentido, eles estão. Uma das qualidades definidoras das organizações desde que existem tais coisas é tratar os indivíduos como peças intercambiáveis. Isso funciona bem para tarefas mais paralelizáveis, como guerras. Durante a maior parte da história, um exército bem treinado de soldados profissionais podia ser contado para vencer um exército de guerreiros individuais, não importa o quão valorosos fossem. Mas ter ideias não é muito paralelizável. E é isso que os programas são: ideias.

Não é apenas verdade que as organizações não gostam da ideia de depender do gênio individual, é uma tautologia. Faz parte da definição de uma organização não o fazer. De nosso conceito atual de organização, pelo menos.

Talvez pudéssemos definir um novo tipo de organização que combinasse os esforços dos indivíduos sem exigir que eles fossem intercambiáveis. Pode-se argumentar que um mercado é uma forma de organização, embora possa ser mais preciso descrevê-lo como um caso degenerado - como o que você obtém por padrão quando a organização não é possível.

Provavelmente o melhor que faremos é algum tipo de hack, como fazer as partes de programação de uma organização funcionar de maneira diferente do resto. Talvez a solução ideal seja as grandes empresas nem mesmo tentarem desenvolver ideias internamente, mas simplesmente comprá-las. Mas, independentemente do que a solução venha a ser, o primeiro passo é perceber que há um problema. Há uma contradição na própria frase "empresa de software". As duas palavras estão puxando em direções opostas. Qualquer bom programador em uma grande organização vai estar em desacordo com ela, porque as organizações são projetadas para impedir o que os programadores se esforçam.

Bons programadores conseguem fazer muito mesmo assim. Mas muitas vezes requer praticamente um ato de rebelião contra as organizações que os empregam. Talvez ajude se mais pessoas entenderem que a maneira como os programadores se comportam é impulsionada pelas exigências do trabalho que eles fazem. Não é porque eles são irresponsáveis que eles trabalham em longas sessões durante as quais ignoram todas as outras obrigações, mergulham diretamente na programação em vez de escrever especificações primeiro e reescrevem código que já funciona. Não é porque eles são antipáticos que preferem trabalhar sozinhos ou rosnar para as pessoas que entram na porta para dizer oi. Essa aparente coleção aleatória de hábitos irritantes tem uma única explicação: o poder de manter um programa em sua cabeça.

Seja ou não que entender isso possa ajudar grandes organizações, certamente pode ajudar seus concorrentes. O ponto mais fraco em grandes empresas é que elas não deixam que programadores individuais façam um ótimo trabalho. Então, se você é uma pequena startup, este é o lugar para atacá-los. Assuma o tipo de problemas que precisam ser resolvidos em uma única mente brilhante.

Agradecimentos a Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev e Stephen Wolfram por lerem rascunhos deste texto.