MANTENDO UM PROGRAMA NA CABEÇA

Agosto de 2007

Um bom programador que trabalha intensivamente em seu próprio código pode mantê-lo na mente da mesma forma que um matemático mantém um problema em que está trabalhando. Matemáticos não respondem perguntas resolvendo-as no papel como as crianças na escola são ensinadas a fazer. Eles fazem mais em suas cabeças: tentam entender um espaço de problema o suficiente para que possam caminhar ao redor dele, assim como você pode caminhar pela memória da casa em que cresceu. No seu melhor, programar é a mesma coisa. Você mantém todo o programa na 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 para resolver o problema de uma maneira diferente, mas para mudar o problema que você está resolvendo.

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

Não é fácil colocar um programa na 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 na sua cabeça quando você começa a trabalhar a cada dia. E isso no melhor dos casos. 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 há coisas que você pode fazer para ajudar:

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

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

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

Trabalhe em longas sessões. Como há um custo fixo cada vez que você começa a trabalhar em um programa, é mais eficiente trabalhar em algumas longas sessões do que em muitas curtas. Haverá, é claro, um ponto em que você fica burro porque está cansado. Isso varia de pessoa para pessoa. Já ouvi falar de pessoas programando por 36 horas seguidas, mas o máximo que consegui gerenciar foi cerca de 18, e eu trabalho melhor em blocos de no máximo 12.

O ótimo não é o limite que você pode suportar fisicamente. Há uma vantagem, assim como um custo, em dividir um projeto. Às vezes, quando você retorna a um problema após um descanso, descobre que sua mente inconsciente deixou uma resposta esperando por você.

Use linguagens sucintas. Linguagens de programação mais potentes tornam os programas mais curtos. E os programadores parecem pensar em 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 é carregá-lo e mantê-lo na sua cabeça.

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

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

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

Trabalhe em pequenos grupos. Quando você manipula um programa na 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, mais importante, não pode se dar ao luxo de brincar. Portanto, quanto menor o número de programadores, mais completamente um projeto pode mutar. Se houver apenas um programador, como muitas vezes 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. Não importa quão minuciosamente você o leu, você apenas o leu, não o escreveu. Portanto, se um pedaço de código é escrito por vários autores, nenhum deles o entende tão bem quanto um único autor entenderia.

E, claro, você não pode redesenhar algo em que outras pessoas estão trabalhando com segurança. Não é apenas que você teria que pedir permissão. Você nem se permite 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 na 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, é forçado a ver tudo. Se você começar com um problema muito grande, pode nunca conseguir compreendê-lo completamente. Portanto, se você precisa escrever um programa grande e complexo, a melhor maneira de 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, muitas vezes são superadas pelas vantagens de ser capaz de manter um programa na sua cabeça.

É impressionante como os programadores conseguem acertar todos os oito pontos por acidente. Alguém tem uma ideia para um novo projeto, mas como não é oficialmente sancionado, ele tem que fazê-lo fora do horário—o que acaba sendo mais produtivo porque não há distrações. Impulsionado por seu entusiasmo pelo novo projeto, ele trabalha nele por muitas horas seguidas. Como é 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 os do tipo nota para si mesmo. Ele trabalha em um pequeno grupo por força das circunstâncias, porque ou não contou a mais ninguém sobre a ideia ainda, ou parece tão sem promessas que ninguém mais é autorizado a 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 um hack legal que quer experimentar.

Ainda mais impressionante é o número de projetos oficialmente sancionados que conseguem fazer todas as oito coisas erradas. De fato, se você olhar para a maneira como o software é escrito na maioria das organizações, é quase como se estivessem tentando deliberadamente fazer as coisas erradas. Em certo sentido, estão. Uma das qualidades definidoras das organizações desde que existem é tratar indivíduos como partes intercambiáveis. Isso funciona bem para tarefas mais paralelizáveis, como lutar em guerras. Durante a maior parte da história, um exército bem treinado de soldados profissionais poderia ser contado para vencer um exército de guerreiros individuais, não importa quão valorosos. 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 fazê-lo. Do nosso conceito atual de uma organização, pelo menos.

Talvez pudéssemos definir um novo tipo de organização que combinasse os esforços de indivíduos sem exigir que fossem intercambiáveis. Pode-se argumentar que um mercado é tal forma de organização, embora possa ser mais preciso descrever um mercado 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 funcionarem de maneira diferente do resto. Talvez a solução ideal seja que grandes empresas nem tentem desenvolver ideias internamente, mas simplesmente as comprem. Mas independentemente de qual seja a solução, 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 estará em desacordo com ela, porque as organizações são projetadas para impedir o que os programadores buscam.

Bons programadores conseguem fazer muito mesmo assim. Mas muitas vezes isso 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 demandas do trabalho que realizam. Não é porque são irresponsáveis que trabalham em longas maratonas 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 são antipáticos que preferem trabalhar sozinhos ou rosnar para pessoas que aparecem na porta para dizer olá. Esta coleção aparentemente aleatória de hábitos irritantes tem uma única explicação: o poder de manter um programa na cabeça.

Se entender isso pode ajudar grandes organizações ou não, certamente pode ajudar seus concorrentes. O ponto mais fraco nas grandes empresas é que elas não permitem que programadores individuais façam um grande trabalho. Portanto, se você é uma pequena startup, este é o lugar para atacá-las. Enfrente o tipo de problemas que precisam ser resolvidos em um grande cérebro.

Obrigado 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 disso.