MANTENDO UM PROGRAMA NA CABEÇA

Agosto de 2007

Um bom programador trabalhando intensamente 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 perguntas trabalhando-as no papel da forma 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 bem o suficiente para que possam andar em volta dele da mesma forma que você pode andar em volta da memória da casa em que cresceu. Na melhor das hipóteses, a programação é a mesma. Você mantém o programa inteiro 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 para resolver o problema de uma maneira diferente, mas para mudar o problema que você está resolvendo.

Seu código é seu entendimento do problema que você está explorando. Então, é somente quando você tem seu código na cabeça que você 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 retornar 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 todos os dias. 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 entendem realmente os problemas que estão resolvendo.

Mesmo os melhores programadores nem sempre têm o programa inteiro 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 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 quanto ela embaralha seu cérebro. Um programador pode sair do escritório e ir buscar 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.

Estranhamente, 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 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. Claro que chegará um ponto em que você ficará estúpido porque está cansado. Isso varia de pessoa para pessoa. Ouvi falar de pessoas que hackearam por 36 horas seguidas, mas o máximo que consegui administrar foi cerca de 18, e 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 acabar com um projeto. Às vezes, quando você retorna a um problema após 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 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 cabeça.

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

Continue reescrevendo seu programa. Reescrever um programa geralmente produz um design mais limpo. Mas teria vantagens mesmo se não produzisse: você tem que entender um programa completamente para reescrevê-lo, então não há melhor maneira de carregá-lo na sua cabeça.

Escreva código relegível. 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 com você mesmo. E quando escreve para si mesmo, você tem prioridades diferentes. Se estiver escrevendo para outras pessoas, talvez não queira 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-texto introdutório. Enquanto isso, se estiver escrevendo código para facilitar a recarga na 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, mais importante, não pode tomar liberdades com elas. Então, quanto menor o número de programadores, mais completamente um projeto pode sofrer mutação. Se houver apenas um programador, como geralmente há no início, você pode fazer redesigns 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 o quão completamente 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 entenderia.

E é claro que você não pode redesenhar com segurança algo em que outras pessoas estão trabalhando. Não é só que você teria que pedir permissão. Você nem se permite pensar nessas 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 conforme você se familiariza com ele. Você pode começar a tratar as partes como caixas-pretas quando 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 ser capaz de abarcá-lo. Então, 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, elas são frequentemente superadas pelas vantagens de ser capaz de manter um programa na sua cabeça.

É impressionante como os programadores conseguem atingir 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 em horas vagas — o que acaba sendo mais produtivo porque não há distrações. Motivado pelo 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 é de fato 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 a variedade de nota para si mesmo. Ele trabalha em um pequeno grupo forçosamente, porque ele ainda não contou a ninguém sobre a ideia, ou parece tão pouco promissor 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 começo; ele só tem um hack legal que quer testar.

Ainda mais impressionante é o número de projetos oficialmente sancionados que conseguem fazer todas as oito coisas erradas . Na verdade, se você observar a maneira como o software é escrito na maioria das organizações, é quase como se estivessem deliberadamente tentando fazer as coisas erradas. Em certo sentido, estão. Uma das qualidades definidoras das organizações desde que existe tal coisa é tratar os indivíduos como partes intercambiáveis. Isso funciona bem para tarefas mais paralelizáveis, como lutar guerras. Durante a maior parte da história, um exército bem treinado de soldados profissionais poderia ser considerado capaz de derrotar 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 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 eles fossem intercambiáveis. Pode-se argumentar que um mercado é uma 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 forma diferente do resto. Talvez a solução ideal seja que as grandes empresas nem tentem desenvolver ideias internamente, mas simplesmente comprá -las. 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 muita coisa de qualquer maneira. 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 é motivada pelas demandas do trabalho que eles fazem. Não é porque eles são irresponsáveis que eles trabalham em longas maratonas durante as quais eles ignoram todas as outras obrigações, mergulham direto na programação em vez de escrever especificações primeiro e reescrevem códigos que já funcionam. Não é porque eles são hostis que eles preferem trabalhar sozinhos ou rosnar para as pessoas que colocam a cabeça na porta para dizer olá. Essa coleção aparentemente aleatória de hábitos irritantes tem uma única explicação: o poder de manter um programa na cabeça.

Quer entender isso possa ou não ajudar grandes organizações, certamente pode ajudar seus concorrentes. O ponto mais fraco em grandes empresas é que elas não deixam programadores individuais fazerem um ótimo trabalho. Então, se você é uma pequena startup, este é o lugar para atacá-los. Assuma o tipo de problema que precisa ser resolvido em um grande cérebro.

Agradecimentos a Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev e Stephen Wolfram pela leitura dos rascunhos.