[
Mais uma vez, continuando a série de traduções, este texto é uma tradução autorizada do ensaio Holding a Program in One’s Head, de autoria de Paul Graham, executada para publicação no site SouNerd.com.
Como sempre, não concordo 100% com todas idéias dele. Não concordo em especial com o ponto 7, e também não concordo tanto assim com parte do 3. Mas no geral o texto bate com as minhas observações e descreve bem o estado em que bons programadores entram, às vezes, chamado “zone“. É realmente um estado diferente em que se consegue entrar e que é extremamente produtivo. Vale a pena ler o ensaio todo.

Original: Agosto de 2007
Tradução: Fevereiro de 2008

Texto original: Holding a Program in One’s Head, autoria de Paul Graham.
Tradução por Börje Karlsson (borje dot karlsson at tellarin dot com).
Eventuais comentários entre colchetes são adições pelo tradutor, não existindo na versão original.
]

–––

Um bom programador trabalhando intensamente em seu próprio código pode mantê-lo em sua mente da maneira que um matemático mantém um problema em que está trabalhando. Matemáticos não respondem questões trabalhando-as no papel como as crianças pequenas são ensinadas a fazer na escola. Eles o fazem mais em suas cabeças: eles tentam entender o espaço do problema bem o suficiente para que possam passear por ele do mesmo modo que você pode passear pelas memórias da casa onde você cresceu. No melhor caso, acontece o mesmo com programação. Você mantém o programa inteiro na sua cabeça e você pode manipulá-lo a vontade.

Isto é especialmente valioso no começo de um projeto, pois inicialmente a coisa mais importante é poder (ter a habilidade de) modificar o que você está fazendo. Não apenas resolver o problema de um modo diferente, mas mudar o problema que se está solucionando.

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

Não é fácil colocar um programa na sua cabeça. Se você deixa um projeto de lado por alguns poucos meses, pode-se levar dias para realmente entendê-lo de novo quando você voltar a ele. Mesmo quando você está trabalhando ativamente em um programa pode-se levar cerca de meia hora para carregar tudo na sua cabeça ao começar a trabalhar cada dia. E este é o melhor caso. Programadores comuns trabalhando em escritórios em condições típicas nunca entram nesse estado/modo. Ou, pra dizer isto mais dramaticamente, programadores comuns trabalhando em escritórios em condições típicas nunca realmente entendem os problemas que estão tentando resolver.

Mesmo os melhores programadores não têm sempre o programa inteiro em que estão trabalhando carregado em suas mentes. Mas há algumas coisas que você pode fazer para ajudar isso a acontecer:

1. Evite distrações. Distrações são ruins para muitos tipos de trabalho, mas são especialmente ruins para programação, pois programadores tendem a operar no limite do nível de detalhes que podem gerenciar.
   
   O perigo de uma distração não depende de sua duração, mas do quanto ela confunde/embaralha seu cérebro. Um programador pode sair do escritório e ir comprar 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, distrações agendadas podem ser piores que as não-agendadas. Se você sabe que vai ter uma reunião daqui há meia hora, você nem sequer começa a trabalhar em algo difícil.
2. Trabalhe em longos períodos. Já que há um custo fixo a cada vez que você começa a trabalhar em um programa, é mais eficiente se trabalhar em algumas sessões mais longas do que em muitas sessões curtas. Lógico que vai chegar um ponto em que você fica meio estúpido por estar cansado. Isto varia de pessoa para pessoa. Já ouvi falar de pessoas hackeando por 36 horas direto, mas o máximo que eu [Paul] já consegui gerenciar foi mais ou menos 18, e eu [Paul] trabalho melhor em blocos/pedaços de 12. [Eu também trabalho melhor em blocos de cerca de 12 horas seguidas. Inclusive, quando estou nesse estado, freqüentemente esqueço de uma refeição até ser interrompido.]
   
   O ponto ótimo não é o limite do que você consegue aguentar fisicamente. Há tanto uma vantagem quanto um custo em se quebrar/dividir um projeto. Algumas vezes quando você retorna para um problema depois de um descanço, você descobre que o sua mente inconsciente deixou uma resposta esperando por você. [Já aconteceu comigo, por exmplo, de sonhar com a solução de determinados bugs.]
3. Use linguagens sucintas. Linguagens de programação mais poderosas tornam os programas menores. E programadores parecem pensar em programas, pelo menos em parte, em função da linguagem que estão usando para escrevê-los. Quanto mais sucinta a linguagem, menor o programa, e mais fácil é carregá-lo e mantê-lo na sua cabeça.
   
   Você pode ampliar o efeito de uma linguagem poderosa ao usar um estilo chamado de programação de baixo pra cima (bottom-up programming), onde você escreve os programas em múltiplas camadas, onde as camadas mais baixas agem com um certo tipo de linguagem de programação para as camadas acima. Se você fizer isso do jeito certo, você só precisará manter a camada mais alta na sua cabeça.
4. Sempre reescreva seu programa. Reescrever um programa freqüentemente leva a um design mais limpo. Mas fazê-lo teria vantagens mesmo que não levasse: você tem que entender um programa completamente para reescrevê-lo, então não há maneira melhor de carregá-lo em sua cabeça.
5. Escreva código re-legí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 se está escrevendo para si mesmo se tem prioridades diferentes. Se você está escrevendo código para outras pessoas, você pode não querer que seu código fique denso demais. Algumas partes do programa podem ser mais fáceis de ler se você espaçar mais as coisas, como em um livro texto introdutório. Por outro lado, se você está escrevendo código para torná-lo mais fácil de recarregá-lo na sua cabeça, talvez seja melhor dar prioridade a “brevidade” (código menor).
6. Trabalhe em grupos pequenos. Quando você manipula um programa em sua cabeça, sua visão do problema tende a parar nas bordas do código que é seu (ou seja, você que escreveu). Você não entende outras partes do código tão bem, e mais importante, você não pode tomar liberdades com elas. Então, quanto menor o número de programadores, mais completamente um projeto pode mutar. Se há apenas um programador, como freqüentemente é o caso a princípio, você pode fazer re-designs englobando/envolvendo tudo. [SCRUM de uma pessoa! ]
7. 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 leu, você só o leu, você não o escreveu. Então, se um pedaço/trecho de código é escrito por vários autores, nenhum deles o entende tão bem quanto apenas um autor entenderia.
   
   E, claro, você não pode redesenhar/remodelar com segurança total algo em que outras pessoas estão trabalhando. Não é apenas por que você teria que pedir permissão. Você nem sequer se deixa pensar em tais coisas. Remodelar código com vários autores é como mudar leis; remodelar código que apenas você controla é como ver uma nova interpretação de uma imagem ambígua.
   
   Se você quer colocar várias pessoas para trabalhar em um projeto, divida-o em componentes e dê um para cada pessoa.
8. Comece pequeno. Um programa fica mais fácil de manter na cabeça a medida que você se familiariza com ele. Você pode começar a tratar certas partes como caixas pretas uma vez que você se sinta confiante de que já o explorou completamente. Mas quando você começa a trabalhar num projeto pela primeira vez, você é forçado a dar uma olhada e ver tudo. Se você começar com um problema grande demais, você pode nunca ser capaz de abarcá-lo perfeitamente. Assim, 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 de planejar, elas são freqüentemente anuladas pelas vantagens de se conseguir manter o programa todo na sua cabeça.

É surpreendente como muitas vezes programadores conseguem atingir os oito pontos por acidente. Alguém tem uma idéia para um novo projeto, mas como não é oficialmente sancionada, a pessoa tem que fazê-lo fora do horário de trabalho. Que por sua vez acabam sendo mais produtivas por não haverem distrações. Guiada pelo entusiasmo pelo novo projeto, a pessoa trabalha nele por muitas horas de cada vez. Como inicialmente ele é só um experimento, ao invés de usar uma linguagem de “produção”, a pessoa usa uma mera linguagem de “scripting”, a qual é na verdade bem mais poderosa. A pessoa re-escreve o programa completamente várias vezes; o que não seria justificável em um projeto oficial, mas esse é um trabalho de amor e a pessoa quer que seja perfeito. E como ninguém vai vê-lo além dela, a pessoa omite qualquer tipo de comentários a não ser os do tipo anotação-para-si-mesmo. A pessoa trabalha a força em um pequeno grupo, já que ela ou não contou a ninguém sobre a idéia ou o projeto parece tão não-promissor que ninguém tem permissão de trabalhar nele. Mesmo que haja um grupo, eles não poderiam ter várias pessoas editando o mesmo código, pois ele muda rapidamente demais para que isso seja possível. E o projeto começa pequeno porque a idéia é pequena a princípio; a pessoa apenas quer testar alguma idéia de um hack legal.

Ainda mais surpreendentes são os números de projetos sancionados oficialmente que conseguem fazer todas as oito coisas erradas. Na verdade, se você olhar o modo como software é escrito na maioria das organizações, é quase como se elas estivessem deliberadamente tentando fazer as coisas da forma errada. E, de certo modo, elas estão. Uma das qualidades que definem uma organização desde que existe tal coisa é o fato de tratarem indivíduos como partes intercambiáveis. Isto funciona bem para tarefas mais paralelizáveis, como travar guerras. No decorrer da maior parte da História, pôde-se contar que um exército bem treinado/doutrinado poderia derrotar um exército de guerreiros individuais, não importando quão valorosos. Mas ter idéias não é um processo tão paralelizável. E é isso que programas são: idéias.

Não é apenas uma verdade que organizações não gostem da idéia de depender de gênios individuais, é uma tautologia. É parte da definição de uma organização não gostar. Pelo menos do nosso conceito atual de organização.

Pode ser que pudéssemos definir um novo tipo de organização que combinasse os esforços de indivíduos sem requerer que eles sejam intercambiáveis. Pode-se argumentar que um mercado é uma organização dessa forma, embora possa ser mais correto/exato descrever um mercado como um caso degenerado ? como o que você tem por padrão quando organização não é possível.

Provavelmente o melhor que vamos conseguir é algum tipo de hack, como fazer com que as partes de programação de uma organização funcionem de forma diferente do resto. Talvez a solução ótima seja que as grandes empresas nem sequer tentem desenvolver idéias internamente, mas simplesmente as comprem. Mas independentemente de que qual 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”. Essas palavram puxam para lados opostos. Qualquer bom programador em uma grande organização/empresa vai estar em desacordo com ela, pois organizações são projetadas para impedir/atrapalhar o que os programadores “querem”.

Mesmo assim, bons programadores conseguem fazer muita coisa. Mas freqüentemente é necessário praticamente um ato de rebelião contra as organizações que os empregam. Talvez ajudasse se mais pessoas entendessem que a maneira como os programadores se comportam é guiada pelas demandas do trabalho que eles fazem. Não é porque eles são irresponsáveis que eles trabalham em longas compulsões durante as quais eles ignoram/descartam todas as suas outras obrigações, pulam direto na programação ao invés de escrever especificações primeiro e re-escrevem código que já funciona. Não é por serem anti-sociais que eles preferem trabalhar sozinhos, ou que grunhem para quem bota a cabeça na porta pra dizer oi. Esta, aparentemente aleatória, coleção de hábitos chatos tem uma única explicação: o poder de manter um programa na cabeça.

Independente de se entender isso pode ou não ajudar grandes organizações, isto pode certamente ajudar seus competidores. O ponto mais fraco das empresas grandes é que elas não permitem que programadores individuais realizem um grande trabalho. Então se você é uma pequena startup, este é o lugar onde atacá-las. Ataque o tipo de problemas que tem que ser resolvido por um cérebro grande.

[Paul Graham:] 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 [do original] desse texto.

— Börje Karlsson (tellarin)
https://tellarin.com/borje
https://www.twitter.com/tellarin