[
Continuando a série de traduções, este texto é uma tradução autorizada do texto Hackers and Painters, de autoria de Paul Graham, executada para publicação no site SouNerd.com.
Quem realmente se interessa por como código fonte se relaciona a arte, programação, por cultura nerd ou assuntos nerd em geral (como dito das outras vezes) deveria ler os textos desse cara. Embora eu não concorde 100% com as idéias dele, o ponto de vista é bastante interessante.

Original: Maio de 2003
Tradução: Dezembro de 2004

Texto original: Hackers and Painters, 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.
]

–––

(Este ensaio é derivado de uma palestra dada em Harvard, que por sua vez incorpora uma anterior dada na Northeastern.)

Quando eu [(Paul)] terminei a graduação em ciência da computação eu fui para uma escola de arte estudar pintura. Muitas pessoas pareciam surpresas que alguém interessado em computadores também se interessaria por pintura. Eles pareciam acreditar que hackear e pintar eram tipos muito diferentes de trabalho– que hacking era frio, preciso e metódico, e que pintura era uma expressão frenética de alguma necessidade primal.

Ambas imagens estão erradas. Hacking e pintura têm muito em comum. De fato, de todos os diferentes tipos de pessoa que eu conheci, hackers e pintores estão entre os mais parecidos.

O que hackers e pintores têm em comum é que ambos são “criadores”. Junto com compositores, arquitetos e escritores, o que hackers e pintores estão tentando fazer é criar coisas boas. Eles não estão fazendo pesquisa por si só, embora se durante a tentativa de criar coisas boas eles descobrirem uma nova técnica, melhor ainda.

Eu nunca gostei do termo “ciência da computação”. O principal motivo pelo qual eu não gosto dele é que não existe tal coisa. Ciência da computação é um grande saco de áreas tenuamente relacionadas entre si que foram jogadas juntas por um acidente de história, como a Iugoslávia. De um lado você tem pessoas que na verdade são matemáticos, mas chamam o que eles estão fazendo de ciência da computação pra poder conseguir fomento da DARPA [- Defense Advanced Research Projects Agency, organização de pesquisa e desenvolvimento do Departamento de Defesa dos EUA]. No meio, você tem pessoas trabalhando com algo tipo “história natural” dos computadores — estudando o comportamento de algoritmos para rotear dados através de redes de computadores, por exemplo. E no outro extremo você tem os hackers, que estão tentando escrever software interessante, e para os quais os computadores são somente um meio de expressão, como o concreto é para os arquitetos ou a tinta é para os pintores. É como se matemáticos, físicos e arquitetos tivessem que ficar todos no mesmo departamento. [NT: Eu entendo o ponto de vista dele, mas não concordo completamente.]

Algumas vezes o que os hackers fazem é chamado de “engenharia de software”, mas esse termo é bem “enganoso”. Bons projetistas de software não são mais engenheiros do que os arquitetos são. O limiar entre arquitetura e engenharia não é exatamente definido, mas ele está lá. Ele cai entre “o que” e “como”: arquitetos decidem o que fazer, e os engenheiros descobrem como fazê-lo [NT: Essa distinção que o Paul faz, pra mim, por sis só já mostra que temos engenheiros de software e arquitetos de software].

“O que” e “como” não devem ser mantidos muito separados. Você está pedindo para ter problemas se você tentar decidir o que fazer sem entender como fazê-lo. Mas hacking pode certamente ser mais que apenas decidir como implementar uma especificação. No seu auge, seria a definição da especificação — embora é óbvio que a melhor maneira de criar essa definição é implementá-la.

Talvez um dia “ciência da computação” vá, assim como a Iugoslávia, ser quebrada em vários componentes. Isso pode ser uma coisa boa. Especialmente se isso significar independência para minha terra natal, hacking.

Empacotar todos estes tipos diferentes de trabalho juntos em um só departamento pode ser conveniente administrativamente, mas é confuso intelectualmente. É por esse motivo que não gosto do nome “ciência da computação”. Pode-se dizer que as pessoas no meio estão fazendo algo como uma ciência experimental. Mas as pessoas nas duas pontas, os hackers e os mathematicians, não estão realmente fazendo ciência.

Os matemáticos não parecem se importar com isso. Eles alegremente vão trabalhar em provar teoremas assim como os matemáticos no departamento de matemática, e provavelmente logo param de notar que o prédio onde trabalam diz “ciência da computação” na placa do lado de fora. Mas para os hackers esse rótulo é um problema. Se o que eles estão fazendo é chamado de ciência, isso faz com que eles se sintam como se devessem agir cientificamente. Então, ao invés de fazer o que eles realmente querem fazer, que é projetar softwares elegantes, hackers em universidades e laboratórios de pesquisa se sentem obrigadom a estar escrevendo artigos de pesquisa.

No melhor caso, os papers são só uma formalidade. Hackers escrevem um software legal, e então escrevem um artigo sobre ele, e o artigo se torna um proxy para a realização (o alcançado) representado pelo software. Mas quase sempre essa incompatibilidade causa problemas. É fácil se desviar de construir coisas elegantes em direção a construiri coisas feias que sejam um assunto mais adequado para a publicação de artigos.

Infelizmente, coisas bonitas e elegantes nem sempre são os melhores assuntos para papers. Primeiro, pesquisa tem que ser original — e como todos que escreveram uma tese de doutorado sabem, a maneira de ter certeza que se está explorando território virgem é escolher um pedaço de terra que ninguém quer. Segundo, pesquisa tem que ser substancial — e sistemas estranhos/esquisitos resultam em papers mais carnudos, pois se pode escrever muito sobre os obstáculos que se teve que superar de modo a conseuir ter as coisas prontase. Nada resulta em problemas mais densos/maciços do que começar com as premissas erradas. A maior parte da IA é um exemplo dessa regra; se você assume que o conhecimento pode ser representado como uma lista de expresões em lógica de predicados cujos argumentos representem conceitos abstratos, você terá um monte de papers pra escrever sobre como fazer isso funcionar. Como Ricky Ricardo [do seriado I Love Lucy] costumava dizer, “Lucy, você tem muito o que explicar”.

A maneira de se criar algo belo ou elegante, geralmente é se fazendo ajustes sutis em algo que já existe, ou combinar idéias existentes em uma maneira um pouco diferente. Esse tipo de trabalho é difícil de transformar em um artigo de pesquisa.

Então por que as universidades e centros de pesquisa continuam a julgar os hackers através de by publicaçõs? Pela mesma razão que “aptidão para estudo” é medido através de simple-minded testes padronizados, ou que a produção de programadores é medida em linhas de código. Estes testes são de fácil aplicação, e não há nada mais tentador que um teste fácil que meio que funciona.

Medir o que os hackers estão realmente tentando fazer, projetar software elegante, seria muito mais difícil. Você precisa de um bom senso de design para julgar um bom design. E não há correlação, exceto talvez uma negativa, entre a habilidade das pessoas de reconhecer um bom design e a confiança delas em poderem fazer isso.

O único teste externo é o tempo. Com o tempo, soluções elegantes tendem a crescer, e coisas feias tendem a ser descartadas. Infelizmente, as quantidades de tempo envolvidas podem ser maiores que o tempo de vida de um humano. Samuel Johnson [uma das maiores figuras literárias da Inglaterra] disse que levava cem anos pra reputação de um escrito convergir. Você tem que esperar que todos os amigos influentes do escritos morram, e depois que todos seus seguidores também morram.

Eu acho que hackers apenas tem que se negar a ter um grande componente aleatório em suas reputações. Nisso eles não são diferentes de outros “fazedores”. Na verdade, eles são sortudos se compararmos. A influência da moda não é nem de perto tão grande no ato de hackear quanto é na pintura.

Existem coisas piores que as pessoas entenderem mal seu trabalho. Um perigo pior é o que você mesmo vá entender errado seu próprio trabalho. Áreas relacionadas é onde você vai olhar procurando por idéais. Se você se encontra no departamento de ciência da computação, existe um tentação natural de acreditar, por exemplo, que hackear seja a versão aplicada do que quer que a ciência da computação teórica seja a teoria. Durante todo o tempo em que eu estive na faculdade eu tive o sentimento descomfortável, no fundo da minha mente, de que eu deveria saber mais teoria, e que era muito errado de minha parte ter esquecido todas aquelas coisas três semanas depois da prova final.

Agora eu percebo que eu estava enganado. Hackers tem que entender de teoria da computação tanto quanto pintores precisam entender sobre a química das tintas. ocê tem que saber como calcular complexidade de tempo e espaço e sobre completude de Turing. Você também pode querer lembrar pelo menos o conceito de máquina de estados, no caso de você ter que escrever um parser um uma biblioteca pra expressões regulares. Pintores, na verdade, tem que lembrar um bom bocado mais que isso sobre a química das tintas do que isso.

Eu descobri que as melhores fontes de idéais não são outras áreas que tenham a palavra “computador” no nome, mas outros campor habitados por criadores. Pintura tem sido uma fonte de idéais muito mais rica do que teoria da computação.

Por exemplo, eu fui ensinado na faculdade que a pessoa tem que pensar no programa todo no papel antes de chegar perto dum computador. Eu percebi que eu não programava desse jeito. Percebi que eu gstava de programar sentando na frente dum computador, não de um pedaço de papel. Pior ainda, ao invés de pacientemente escrever um programa completo e ter certeza que ele estava correto, eu tinha a tendência de cuspir código que irremediávelmente tinha problemas, e gradualmente dar porrada nele até ele ficar do jeito que eu queria. Debugar, me ensinaram, era algum tipo de passagem final onde você encontrava erros de digitação e coisas que lhe escaparam ao olhar. Do jeito que eu trabalhava, parecia que programar era praticamente debugar.

Por muito tempo eu me senti mal por isso, assim como eu antigamente me sentia mal por não segurar o lápis do jeito que me ensinaram na alfabetização. Se eu pelo menos tivesse olhado para os outros “fazedores”, os pintores ou os arquitetos, eu teria percebido que havia um nome para o que estava fazen: rascunho. Até onde eu sei, a maneira como me ensinaram a programar na faculdade foi toda errada. Você deveria entender melhor os programas enquanto você os está escrevendo, assim como os escritores e pintores e arquitetos fazem. [Temos que lembrar aqui também que os rascunhos muitas vezes são jogados fora e se começa de novo.]

Perceber isso tem implicações reais no projeto de software. Isso significa que uma linguagem de programação deveria, acima de tudo, ser maleável. Uma linguagem de programação serve para pensar em programas, não pra expressar programas nos quais você já pensou tudo. Deveriam ser um lápis e não uma caneta. Tipos estáticos seriam ideais se as pessoas realmente escrevessem programas da menira que foram ensinadas na universidade. Mas não é assim que nenhum dos hackers que conheço escreve programas. Nós precisamos de uma linguagem que nos deixe rabiscar e borrar e manchar, não uma linguagem em que você tem que se sentar com uma xícara de tipos equilibrada no joelho e ficar consersando educadamente com um compilador tipo tia-velha-certinha.

Enquanto estanos no assunto de tipos estáticos, se identificar com os criadores vai nos salvar de um outro problema que aflige as ciências: inveja matemática. Todo mundo nas ciências secretamente acredita que os matemáticos são mais espertos do que eles são. Eu acho que os matemáticos tambem acreditam nisso. De qualquer modo, o resultado é que os cientistas tendem a fazer com que seu trabalho fique com a cara o mais matemática possível. Em uma área como física isso provavelmente não faz muito mal, mas quão mais longe você vai das ciências naturais, maior o problema se torna.

Uma página cheia de fórmulas causa realmente uma impressão. (Dica: para impressionar mais, use variáveis gregas.) E então há uma grande tentação para se trabalhar em problemas que se pode tratar formalmente, ao invés de problemas que sejam, digamos, importantes.

Se os hackers se identificassem com os outros criadores, como escritores ou pintores, eles não se sentiriam tentados a fazer isso. Escritores e pintores não sofrem de inveja matemática. Eles se sentem como se estivessem fazendo algo completamente não relacionado. Assim também são os hackers, na minha opinião.

Se as universidades e os laboratórios de pesquisa ficam impedindo-os de fazer o tipo de trabalho que eles querem fazer, talvez o lugar deles seja em empresas. Infelizmente, a maioria das empresas também não vai deixar os hackers fazerem o que ele querem. Universidades e laboratórios de pesquisa forçam os hackers a ser scientists, e empresas os forçam a ser engenheiros.

Eu mesmo só descobri isso bem recentemente. Quando o Yahoo comprou a Viaweb, ele me perguntaram o que eu queria fazer. Eu nunca gostei muito do lado comercial, e então eu disse que queria ficar hackeando. Quando eu cheguei no Yahoo, eu descobri que hackear pra eles significava implementar software, não projetá-lo. Programadores eram vistos como técnicos que traduziam as visões (se essa for a palavra) dos gerentes de produto em código.

Esse parece ser o plano padrão em grandes empresas. Eles fazem isso pois isso diminui o desvio padrão do resultado. Somente uma pequena percentagem dos hackers conseguem realmente projetar software, e é difícil pras pessoas dirigindo a empresa pra distingui-los. Então, ao invés de confiar o futuro de um software a um hacker brilhante, a maioria das empresas monta as coisas de modo que ele (o software) seja projetado por um commit, e os hackers meramente implementam o design.

Se você quer fazer dinheiro em algum momento, lembre disso, pois esse é um dos motivos pelos quais empresas startups se dão bem. Grandes empresas querem diminuir o desvio padrão com relação ao produto final pois elas querem evitar desastres. Mas quando você joga fora as ocilações, você perde os pontos altos junto com os baixos. Isso não é um problema pras grandes empresas, pois elas não ganham mercado por ter ótimos produtos. Grandes empreas ganham por serem menos piores qe outras grandes empresas.

Então se você puder consiga um jeito de entrar numa “gerra de projeto” com uma empresa grande o suficiente para ter o software dela projetado por gerentes de produto, eles nunca conseguirão competir e se igualar a você. No entanto, essas oportunidades não são fáceis de encontrar. É difícil se engajar com um empresa grande numa guerra de design, assim como é difícil começar uma luta mano a mano com alguém que está dentro dum castelo e você fora. Seria relativamente fácil se escrever um processador de texto melhor que o Microsoft Word, por exemplo, mas a Microsoft, de dentro do castelo de sue monopólio de sistema operacional, provavelmente nem sequer perceberia se você o fizesse.

O lugar para lutar essas guerras de projeto é em novos mercados, onde ninguém ainda conseguiu estabelecer fortificações. É aí que você pode ganhar por tomar atitudes ousadas com relação a design, e tendo as mesmas pessoas projetando e implementando o produto. A Microsoft mesmo fez isso no começo. Assim como a Apple. E a Hewlett-Packard. Acredito que toda startup de sucesso fez isso.

Desse modo, uma maneira de se fazer software bom é começar a sua própria startup. Existem alguns problemas com isso, no entanto. Um é que numa startup você tem que fazer muito mais do que só escrever software. Na Viaweb eu me considerava um cara sortudo se eu conseguisse ficar hackeando um quarto do tempo. E as coisas que eu tinha que fazer nos outros três quartos do tempo iam de tediosas a amedrontadoras. Eu tenho um bom exemplo que mostra como é isso, pois uma vez eu tive que sair duma reunião da diretoria da empresa pra tapar uns buracos. Eu me lembro de estar lá sentado na cadeira do dentista, esperando pela broca, e me sentindo como se eu estivesse de férias.

O outro problema com empresas startup é que não tem muita interseção entre o tipo de software que dá dinheiro e o tipo que é interessante de escrever. Linguagen de programação são interessantes de escrever, e o primeiro produto da Microsoft foi uma, na verdade, mas ninguém vai pagar por uma linguagem de programação hoje em dia. Se você quer fazer dinheiro, você é meio que forçadoa trabalhar em problemas que sejam tão “nojentos” que ninguém queira trabalhar neles de graça.

Todos os “fazedores” se deparam com esse problema. Preços são determinados pela oferta e demanda, e simplesmente não há tanta demanda por coisas que sejam divertidas de se trabalhar quanto há por coisas que resolvam os problemas mundanos de clientes individuais. Atuar em peças fora do circuitão não paga tão bem quanto se vestir de gorilla no estande de alguma mega-empresa num trade show. Escrever romances não paga tão bem quanto escrever cópias de propaganda pra venda de trituradores de lixo. E hackear linguagens de programação não paga tão bem quanto descobrir como conectar uma base de dados legada duma certa empresa com o novo servidor Web que eles compraram.

Na minha opinião a resposta pra esse problema, no caso de software, é um conceito conhecido de todos os “fazedores”: o “day job”. Este termo começou com os músicos, que tocavam à noite. Em termos mais gerias, isso significa que você tem um tipo de trabalho que você faz por dinheiro, e outro que você faz por amor.

Praticamente todos os criadores tem day jobs no começo de suas carreiras. Pintores e escritores notoriamente têm. Se você for sortudo, você pode conseguir um bico que seja relativamente próximo do seu trabalho real. Músicos frequentemente tem trabalhaod em lojas de discos. Um hacker trabalhando em alguma linguagem de programação ou sistema operacional poderia do mesmo modo conseguir um bico pra trabalhar usando o que fez. [1]

Quando eu digo que a resposta para os hackers é fazer bicos, e trabalhar em software elegante por fora, não estou propondo isso como uma idéia nova. Hacking c/ software aberto é bem essa idéia. O que estou dizendo é que software de código aberto é provavelmente o modelo certo, pois ese foi o modelo confirmado independentemente pelos outros criadores.

Me parece surpreendente que qualquer empregador venha a relutar em permitir aos hackers trabalharem em projetos open-source. Na Viaweb, nós relutaríamos em contratar qualquer um que não o fizesse. Qaundo nós entrevistávamos programadores, a coisa principal com a qual nos preocupávamos era que tipo de software eles tinham escrito em seu tempo livre. Você não consegue fazer algo realmente bem a não ser que você ame o que faz, e se você ama hackear você inevitávelmente estará trabalhando em projetos próprios. [2]

Devido ao fato de hackers serem fazedores ao invés de cientistas, o lugar certo para procurar metáforas não é nas ciências, mas entre os outros tipos de fazedores. O que mais a pintura pode nos ensinar sobre hackear?

Uma coisa nós podemos aprender a partir do exeplo da pintura, ou pelo menos confirmar, é sobre como aprender a hackear. Você aprende a pintar principalmente pintando. O mesmo pra hackear. A maioria dos hackers não aprende a hackear tendo aulas de programação na faculdade. Eles aprendem a hackear escrevendo programas deles mesmos aos treze anos. Mesmo nas aulas da faculdade, você aprende a hackear hackeando. [3]

Uma vez que os pintores deixam uma trilha de trabalho por onde passam, você consegue ver ele aprenderem enquanto fazem. Se você observar o trabalho de um pintor em ordem cronológica, você vai perceber que cada pintura se apóia em coisas que foram aprendidas em pinturas prévias. Quando há algo em uma pintura que funciona muito bem, você geralmente consegue encontrar a versão 1 dessa coisa de uma maneira menor em alguma pintura anterior.

Acho que a maioria dos criadores funciona desse jeito. Escritores e arquitetos parecem fazê-lo também. Talvez fosse bom para os hackers que eles agissem mais como pintores, e regularmente começar de novo do nada, ao invés de continuar a trabalhar por anos no mesmo projeto, e tentar incorporar todas as novas idéias como revisões.

O fato de hackers aprederem a hackear através da prática é outro exemplo de quão diferente hacking é das ciências. Cientistas não aprendem ciência fazendo, mas trabalhando num laboratório ou trabalhando num conjunto de problemas. Cientistas começam fazendo um trabalho que é perfeito, no sentido de que ele só estão tentando reproduzir um trabalho que já foi feito por alguém antes pra eles. Com o passar do treinamento, eles chegam ao ponto em que podem fazer um trabalho original. Enquanto hackers, desde o começo, estão fazendo trabalho original/novo; só que fazendo isso mau. Então hackers começam com trabalho original, e vão ficando bons, e cientistas começam bons, e depois fazem coisas originais.

A outra maneira dos fazedores aprenderem é por exemplos. Para um pintor, um museu é uma biblioteca de referência de técnicas. Por centenas de anos tem sido parte da educação tradicional de pintores copiar os trabalhos dos grandes mestres, pois copiar força você a olhar de perto, prestar bastante atenção, à maneira com que a pintura foi feita.

Escritores também fazem isso. Benjamin Franklin aprendeu a escrever fazendo resumos sobre os pontos principais dos ensaios de Addison e Steele [fundadores da revista The Spectator] e depois tentando reproduzí-los. Raymond Chandler [escrito famoso de histórias e romances criminais e de detetive] fez o mesmo com histórias de detetive.

Hackers, do mesmo modo, podem aprender a programar olhando pra bons programas — não somente para o que eles fazem, mas para o código fonte também. Um dos bebefícios do movimento opens-source que menos recebe publicidade é o de que ele torna mais fácil aprender a programar. Quando eu aprendi a programar, nós tinhamos que nos basear, na maior parte, em exemplos de livros. O único grande pedaço de código disponível na época era o Unix, mas mesmo ele não era código aberto. A maioria das pessoas que leram o çodigo, o leram de xerox ilícitas do livro do John Lions [Commentary on UNIX 6th Edition, with Source Code, que tinha o código completo da 6a edição do kernel do Unix], o qual apesar de escrito em 1977 não teve permissão para ser publicado até 1996.

Outro exemplo que podemos tomar a partir da pintura é a maneira como os quadros são criados através de refinamento gradual. Pinturas geralmente começam com um rabisco. Gradualmente os detalhes vão sendo preenchidos. Mas não é simplesmente um processo de ir preenchendo os buracos. Algumas vezes o plano original se mostra um engano. Incontáveis pinturas, quando examinadas com o uso de raios X, mostram que tiveram as posições de membro modificadas ou características faciais que foram re-ajustadas.

Aqui está um caso onde e pode aprender com a pintura. Na minha opinião, hacking deveria acontecer assim também. É muito irreal esperar que as especificações de um programa sejam perfeitas. Você estará numa situação muito melhor se admitir isso de cara, e escrever os programas de tal modo que permita a mudança das especificações on the fly.

(A estrutura de grandes empresas faz com que isso seja difícil para elas fazerem, esa é uma outra situação em que pequenas empresas startup têm vantagens.)

Todo mundo hoje em dia teoricamente conhece os perigos de tentar fazer otimizações prematuras. Acredito que deveríamos ser tão preocupados com isso quanto com design prematuro — decidir muito cedo o que um programa deva fazer.

As ferramentas certas podem nos ajudar a evitar esse perigo. Uma boa linguagem de programação deveria, assim como tinta a óleo, fazer com que fosse fácil mudar de idéia. Tipagem dinâmica é um ganho aqui pois você não tem que se comprometer com representações específicas dos dados logo de cara. Mas a chave para a flexibilidade, eu acho, é fazer a linguagem bem abstrata. O programa mais fácil de ser modificado é aquele que é bem pequeno.

Isto parece um paradoxo, mas uma grande pintura tem que ser melhor do que ela tem que ser. Por exemplo, quando Leonardo [da Vinci] pintou o retrato de Ginevra de Benci que está na National Gallery [em Washington D. C., EUA], ele colocou um junipero por trás da cabeça dela. Nele ele cuidadosamente pintou cada uma das folhas. Muitos pintores devem ter pensado: isto é apenas algo para ser colocado como pano de fundo para enquadrar a cabeça dela, ninguém vai prestar atenção nele.

Mas não Leonardo. Quão pesado ele trabalhou naquela parte da pintura não dependia de quão de perto ele achava que as pessoas olhariam pra ela. Ele foi como Michael Jordan. Implacável.

Ser implacável/incansável faz diferença porque, no todo, os detalhes despercebidos se tornam visíveis. Quando as pessoas passam na frente do retrato de Ginevra de Benci, a atenção delas é quase sempre aprisionada pelo quadro, mesmo antes deles olharem na etiqueta e perceber que nela está escrito Leonardo da Vinci. Todos aqueles detalhes imperceptíveis se combinam para produzir algo que é simplesmente atordoante, como milhares de vozes quase inaudíveis todas cantando no tom.

Bom software, do mesmo modo, requer uma devoçõ fanática para a beleza/elegância. Se você olhar dentro dum software bom, você percebe que mesmo partes que não deveriam ser vistas por ninguém são bonitas. Não estou dizendo que eu escreva software bom, mas eu sei que quando é hora de fazer código eu me comporto de uma maneira que me faria elegível a ter remédios pesados receitados a mim por um médico se eu abordasse os problemas do dia a dia da mesma maneira. Eu fico doido só de ver código que esteja mal identado, ou que use nomes de variáveis feios.

Se um hacker fosse apenas um mero implementador, transformando uma especificação em código, aí ele poderia apenas ir trabalhando duma ponta a outra como alguém que cava uma vala. Mas se o hacker é um criador, nós temos que levar a inspiração em conta.

No hackear, assim como na pintura, o trabalho vem em ciclos. Algumas vezes você se empolga com um novo projeto e você quer trabalhar dezesseis horas por dia nele. Outras vezes nada parece interessante.

Para se fazer um bom trabalho você tem que lever esses ciclos em consideração, pois eles são afetados por como você reage a eles. Quando você está dirigindo um carro com transmissão manual numa montanha, você tem que tirar o pé às vezes para evitar parar. Tirar o pé pode do mesmo modo impedir a ambição de travar. Tanto na pintura quando no hackear existem algumas tarefas que são terrivelmente ambiciosas, e outras que são recomfortantemente rotineiras. É uma boa idéia guardar algumas tarefas fáceis pra quando você estiver travado.

Quando programando, isso quer dizer literalmente economizar bugs. Eu gosto de debugar: é o momento onde hacking é tão direto quanto as pessoas pensam que é. Você tem um problema bem restrito, e tudo que você tem que fazer é resolvê-lo. Seu programa deveria fazer X. Mas ao invés disso, ele faz Y. O que é que está dando errado? Você sabe que eventualmete você será o vencedor no final. É tão relaxante quando pintar uma parede. [Pelo menos ele (o Paul) acha isso, né? ;)]

O exemplo da pintura pode nos ensinar não somente como gerenciar nosso próprio trabalho, mas como trabalhar em grupo. Muitas das grandiosas obras de arte do passado foram executadas por múltiplas mãos, embora possa só ter um nome na parede perto delas nos museus. Leonardo foi um aprendiz na oficina de Verrocchio [Andrea del Verrocchio, pintor e escultor florentino tido como o pintor mais influente de seu período] e pintou um dos anjos no quadro Batismo de Cristo dele. Este tipo de coisa era uma regra, não uma exceção. Michelangelo era considerado especialmente dedicado por insitir em pintar sozinho todas as figuras no teto da Capela Sistina.

Até onde eu sei, quando pintores trabalhavam juntos na mesma pintura, eles nunca trabalhavam nas mesma partes. Era prática comum o mestre pintar os personagens principais e os assistentes pintarem as outras e o fundo. Mas você nunca tinha um cara pintando por cima do trabalho do outro.

Eu acho que esse é o modelo certo para colaboração no desenvolvimento de software também. Não force muito. Quando um pedaço de código está sendo hackeado por três ou quatro pessoas diferentes, e nenhum deles realmente é dono daquele pedaço, ele vai acabar parecendo com uma sala comum. Vai tender a parecer meio “triste” e abandonado, e acumular troços. A maneira certa de colaborar, na minha opinião, é dividir o projeto em módulos com divisão bem definida, cada um com um dono definitivo, e com interfaces entre eles que sejam projetadas com tanto cuidado e, se possível, que sejam tão articuladas quanto linguagens de programação.

Como na pintura, a maior parte dos programas é criada para seres humanos. E desse modo os hackers, assim como os pintores, devem ter uma certa empatia para poder fazer realmente um grande trabalho. Você tem que conseguir ver as coisas do ponto de vista do usuário.

Quando eu era criança, sempre me diziam pra ver as coisas do ponto de vista de alguma outra pessoa. O que isso sempre significava na práctica era pra fazer algo do jetio que a outra pessoa gostaria, e não do jetio que eu queria. Esse fato, é claro, fez com que “empatia” fosse algo que eu não queria, e eu fiz um esforço pra não cultivá-la.

Cara, eu estava errado. Acabou que ver as coisas do ponto de vista de outras pessoas é praticamente o segredo para o sucesso. Isso não significa necessariamente fazer auto-sacrifícios. Longe disso. Entender como alguém vê as coisas não implica em você agir de acordo com os interesses do outro; em algumas situações — na guerra, por exemplo — você quer fazer exatamente o oposto. [4]

A maioria dos criadores cria coisas para uma audiência humana. E para prender a tenção de uma audiência você tem que entender o que eles querem. Praticamente todos as maiores pinturas do mundo são pinturas de pessoas, por exemplo, pois as pessoas são o assunto no qual as pessoas estão interessadas.

Empatia é provavelmente a principal e mais importante diferença entre um bom hacker e um ótimo. Alguns hackers são bem espertos, mas quando se trata de empatia eles são practicamente solipsistas [o cara que acha que o mundo é ele]. É difícil para tais pessoas projetar um software realmente bom [5], pois eles não conseguem ver as coisas do ponto de vista do usuário.

Uma maneira de dizer o quão boa uma pessoa é com relação a empatia é vê-la explicar uma questão técnica para alguém que não tem um background técnico. Todos nós provavelmete conhecemos pessoas que, embora de outro modo espertas, são simplismete comicamente péssimas nesse tipo de situação. Se alguém perguntar a elas num jantar o que é uma linguagem d eprogramação, eles vão dizer algo tipo “Oh, uma linguagem de alto nível que o compilador usa como entrada pra gerar código objeto.” Linguagem de alto nível? Compilador? Código objeto? Alguém que não sabe o que é uma linguagem de programação obviamente também não sabe o que essas coisas são.

Parte do que um programa tem que fazer é se auto-explicar. Então para se escrever bons softwares você tem que entender quão pouco os usuários entendem. Eles vão chegar no programa sem nenhuma preparação, e é bm que ele faça o que elas acham que ele vai fazer, pois elas não vão ler o manual de jeito nenhum. O melhor sistema que eu já vi nesse sentido foi o Macintosh original, em 1985. Ele fazia o que um software/computador quase nunca faz: simplesmente funcionava. [6]

Código fonte, também, deveria ser auto-explicativo. Se eu pudesse fazer as pessoas lembrar de apenas uma citação/frase sobre programação, ela seria aquela no começo do livro Structure and Interpretation of Computer Programs [livro da MIT Press escrito em 1985 por dois professores do MIT - Hal Abelson e Jerry Sussman - e Julie Sussman].

Programas deveriam ser escritos para pessoas lerem, e só por acaso para serem executados por uma máquina.

Você tem que ter empatia não só com seus usuários, mas com seus leitores. É do seu interesse, pois você será um deles também. Muitos hackers já escreveram um programa e descobriram que ao voltar pra ele seis meses depois, não faziam idéia de como ele funcionava. Eu conheço várias pessoas que xingaram Perl depois de tais experiências. [7]

Falta de empatia é associada com com inteligência, até o ponto em que é até meio que uma moda em alguns lugares. Mas eu não acho que haja a;guma correlação. Você pode se dar bem em matemática e em ciências naturais sem ter que aprender a ter empatia, e as pessoas nesses campos tendem a ser espertas, então as duas qualidades acabaram meio que sendo associadas. Mas há muitas pessoas burras que são ruins de empatia também. Preste atenção por exemplo às pessoas que ligam pra fazer perguntas num talk show. Elas perguntam o que quer que seja que elas estão perguntando duma maneira tão enrolada que quase sempre os apresentadores tem que parafrasear a pergunta para elas.

Então, se hacking é como pintura e escrita, é também tão cool? Afinal, você só tem uma vida. Você deveria gastá-la trabalhando em algo grande.

Infelizmente, essa pergunta é difícil de responder. Sempre há um grande vão de tempo até o prestígio. É como a luz duma estrela distante. Pintura hoje em dia tem prestígio por causa das grandes obras que pessoas fizeram há quinhentos anos atrás. Naquele tempo, ninguém achava que essas pinturam eram tão importantes quanto se acha hoje. Teria parecido muito estranho para as pessoas daquele tempo que Federico de Montefeltro, o Duque de Urbino, fosse um dia conhecido basicamente como o cara com o nariz estranho numa pintura de Piero della Francesca.

Então embora eu admita que hacking não aprece tão cool quanto pintura agora, nós devemos nos lembrar que pintura não era tão cool nos seus dias de glória como é hoje.

O que nós podemos dizer com certeza é que esses são os dias de glória do hackear. Na maioria das áreas o trabalho inovador é feito logo no começo. As pinturas criadas entre 1430 e 1500 ainda são insuperáveis. Shakespeare apareceu bem na época em que o teatro profissional estava nascendo, e influenciou tanto a mídia que todo escritor de peça desde então tem tido ue viver à sombra dele. Albrecht Dürer fez o mesmo com gravuras(engraving), e Jane Austen [escritora de "Sensibilidade e Bom Senso" e "Orgulho e Preconceito" entre outros] com os romances (novel).

De novo e de novo nós vemos o mesmo padrão. Uma nova mídia aparece, e algumas pessoas ficam tão excitadas/empolgadas com ela que elas exploram a maioria das possibiliades da mídia nas primeiras gerações. Hacking parece estar nessa fase atualmente.

A pintura não era, na época de Leonardo, tão cool quanto o seu trabalho ajudou-a a ser. Quão cool hacking vai se tornar vai depender do que nós conseguirmos fazer com essa nova mídia.

Notas:

[1] O maior dano que a fotografia causou a pintura pode ter sido o fato de que ela matou seu melhor bico (day job). A maioria dos grandes pintores na história se mantinha através da pintura de retratos.

[2] Me disseram que a Microsoft desencoraja seus funcionários de contruir para projeto de código aberto, mesmo que seja no tempo livre deles. Mas tantos dos melhores hackers trabalham em projetos open-source hoje em dia que o principal efeito dessa política pode se tornar garantir que eles não conseguirão contratar mais nenhum programador de primeira linha.

[3] O que você aprende sobre programação na faculdade é bem parecido com o que você aprende sobre livros, roupas ou namorar: que mal gosto você tinha no colégio.

[4] Aqui vai um exemplo de empatia aplicada. Na Viaweb, se nós não conseguissemos decidir entre duas alternativas, nós perguntaríamos, o que os nossos competidores odiariam mais? Uma vez um dos nossos competidores adicionou uma funcionalidade (feature) ao software deles que era basicamente inútil, mas como ela era uma das poucas que eles tinham e nós não, eles fizeram o maior estardalhaço sobre a mesma na imprensa. Nós podiamos ter tentado explicar que aquela funcinalidade era inútil, mas nós decidimos que iria irritar/incomodar mais nosso competidor de nós implementássemos também a funcionalidade, então nós hackeamos nossa própria versão naquela mesma tarde.

[5] Exceto editores de texto e compiladores. Hackers não precisam de empatia para projetá-los, pois eles mesmo são seus usuários típicos.

[6] Bem, quase. Eles de algum modo excederam a RAM disponível, causando um inconveniente por causa de muito swapping de disco, mas isso pôde ser corrigido em alguns meses com a compra de um drive de disco adicional.

[7] A maneira de se fazer programas fáceis de ler não é estufando-os com comentários. Eu levaria a citação de Abelson and Sussman um passo além. Linguagens de programação deveriam ser projetadas para expressar algoritmos, e só por acaso para dizer aos computadores como executá-los. Uma boa linguagem de programação deveria ser melhor para explicar software do que inglês (ou português ou qualquer outra língua). Você só deveria precisar de comentários quando há algum tipo de percalço da qual você precise tornar os leitores cientes, assim como numa estrada só existem aquelas várias placas seguidas com setas quando se aproxima uma curva muito fechada.

[Paul Graham:] Agradecimentos a Trevor Blackwell, Robert Morris, Dan Giffin e Lisa Randall por lerem rascunhos deste ensaio [o original], e a Henry Leitner e Larry Finkelstein por me convidarem para dar as palestras.

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