HACKERS E PINTORES

Maio de 2003

(Este ensaio é derivado de uma palestra convidada em Harvard, que incorporou uma palestra anterior em Northeastern.)

Quando terminei o mestrado em ciência da computação, fui para a escola de arte para estudar pintura. Muitas pessoas pareciam surpresas que alguém interessado em computadores também se interessasse por pintura. Eles pareciam achar que hackear e pintar eram tipos de trabalho muito diferentes - que hackear era frio, preciso e metódico, e que pintar era a expressão frenética de algum impulso primordial.

Ambas essas imagens estão erradas. Hackear e pintar têm muito em comum. Na verdade, de todos os diferentes tipos de pessoas que eu conheci, hackers e pintores estão entre os mais parecidos.

O que hackers e pintores têm em comum é que eles são ambos 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 per se, embora se no curso de tentar criar coisas boas eles descobrirem alguma nova técnica, tanto melhor.

Nunca gostei do termo "ciência da computação". A principal razão pela qual não gosto é que não existe tal coisa. Ciência da computação é uma miscelânea de áreas vagamente relacionadas reunidas por um acidente da história, como a Iugoslávia. Em uma extremidade, você tem pessoas que são realmente matemáticos, mas chamam o que eles estão fazendo de ciência da computação para que possam obter bolsas da DARPA. No meio, você tem pessoas trabalhando em algo como a história natural dos computadores - estudando o comportamento de algoritmos para rotear dados através de redes, por exemplo. E então na outra extremidade você tem os hackers, que estão tentando escrever software interessante, e para quem os computadores são apenas um meio de expressão, assim como o concreto é para os arquitetos ou a tinta para os pintores. É como se matemáticos, físicos e arquitetos tivessem que estar no mesmo departamento.

Às vezes, o que os hackers fazem é chamado de "engenharia de software", mas esse termo é tão enganoso. Bons designers de software não são mais engenheiros do que os arquitetos são. A fronteira entre arquitetura e engenharia não é claramente definida, mas ela existe. Ela fica entre o que e o como: os arquitetos decidem o que fazer, e os engenheiros descobrem como fazer.

O que e o como não devem ser mantidos muito separados. Você está pedindo problemas se tentar decidir o que fazer sem entender como fazer. Mas hackear certamente pode ser mais do que apenas decidir como implementar alguma especificação. No seu melhor, é criar a especificação - embora descubra-se que a melhor maneira de fazer isso é implementá-la.

Talvez um dia a "ciência da computação" será, como a Iugoslávia, dividida em suas partes componentes. Isso pode ser uma coisa boa. Especialmente se significasse independência para minha terra natal, o hacking.

Agrupar todos esses diferentes tipos de trabalho juntos em um departamento pode ser conveniente administrativamente, mas é confuso intelectualmente. Essa é a outra razão pela qual não gosto do nome "ciência da computação". Argumentavelmente, as pessoas no meio estão fazendo algo parecido com uma ciência experimental. Mas as pessoas nas duas extremidades, os hackers e os matemáticos, não estão realmente fazendo ciência.

Os matemáticos não parecem incomodados com isso. Eles felizmente se põem a trabalhar provando teoremas como os outros matemáticos lá no departamento de matemática, e provavelmente logo param de notar que o prédio em que trabalham diz "ciência da computação" na fachada. Mas para os hackers, esse rótulo é um problema. Se o que eles estão fazendo é chamado de ciência, isso os faz sentir que deveriam estar agindo de forma científica. Então, em vez de fazer o que realmente querem fazer, que é projetar um software bonito, os hackers em universidades e laboratórios de pesquisa sentem que deveriam estar escrevendo artigos de pesquisa.

No melhor dos casos, os artigos são apenas uma formalidade. Os hackers escrevem software legal, e então escrevem um artigo sobre ele, e o artigo se torna um substituto para a realização representada pelo software. Mas muitas vezes essa incompatibilidade causa problemas. É fácil se afastar da construção de coisas bonitas em direção à construção de coisas feias que se tornam assuntos mais adequados para artigos de pesquisa.

Infelizmente, coisas bonitas nem sempre se tornam os melhores assuntos para artigos.

Primeiro, a pesquisa deve ser original - e como qualquer um que tenha escrito uma dissertação de doutorado sabe, a maneira de ter certeza de que você está explorando um território virgem é reivindicar um pedaço de terra que ninguém quer. Segundo, a pesquisa deve ser substancial - e sistemas desajeitados geram artigos mais substanciais, porque você pode escrever sobre os obstáculos que precisa superar para conseguir fazer as coisas. Nada gera problemas mais substanciais do que começar com as suposições erradas. A maior parte da IA é um exemplo dessa regra; se você supuser que o conhecimento pode ser representado como uma lista de expressões de lógica de predicados cujos argumentos representam conceitos abstratos, você terá muitos artigos a escrever sobre como fazer isso funcionar. Como Ricky Ricardo costumava dizer: "Lucy, você tem muita coisa a explicar".

A maneira de criar algo bonito é muitas vezes fazer pequenos ajustes em algo que já existe ou combinar ideias existentes de uma maneira ligeiramente nova. Esse tipo de trabalho é difícil de transmitir em um artigo de pesquisa.

Então, por que as universidades e os laboratórios de pesquisa continuam a julgar os hackers por publicações? Pela mesma razão que a "aptidão escolar" é medida por testes padronizados simplistas, ou a produtividade dos programadores é medida em linhas de código. Esses testes são fáceis de aplicar e não há nada tão tentador quanto um teste fácil que funciona mais ou menos.

Medir o que os hackers estão realmente tentando fazer, projetar software bonito, 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 possivelmente uma negativa, entre a capacidade das pessoas de reconhecer um bom design e sua confiança de que podem.

O único teste externo é o tempo. Com o tempo, as coisas bonitas tendem a prosperar e as feias tendem a ser descartadas. Infelizmente, os períodos de tempo envolvidos podem ser mais longos do que a vida humana. Samuel Johnson disse que levava cem anos para a reputação de um escritor se consolidar. Você tem que esperar que os amigos influentes do escritor morram e depois que todos os seus seguidores morram.

Acho que os hackers simplesmente têm que se resignar a ter um grande componente aleatório em suas reputações. Nisto eles não são diferentes de outros criadores. Na verdade, eles têm sorte em comparação. A influência da moda não é nem de longe tão grande na programação quanto é na pintura.

Há coisas piores do que as pessoas não entenderem seu trabalho. Um perigo maior é você mesmo não entender seu trabalho. Os campos relacionados são onde você vai procurar ideias. Se você se encontrar no departamento de ciência da computação, há uma tentação natural de acreditar, por exemplo, que a programação é a versão aplicada do que a teoria da computação é a teoria. Durante todo o tempo em que estive na pós-graduação, tive um incômodo sentimento na parte de trás da minha mente de que eu deveria saber mais teoria e que era muito negligente da minha parte ter esquecido tudo aquilo em três semanas após o exame final.

Agora eu percebo que estava enganado. Os hackers precisam entender a teoria da computação mais ou menos tanto quanto os pintores precisam entender a química da tinta. Você precisa saber como calcular a complexidade de tempo e espaço e sobre a completude de Turing. Você também pode querer se lembrar pelo menos do conceito de uma máquina de estado, caso precise escrever um analisador ou uma biblioteca de expressões regulares. Os pintores, na verdade, têm que se lembrar de muito mais sobre a química da tinta do que isso.

Descobri que as melhores fontes de ideias não são os outros campos que têm a palavra "computador" em seus nomes, mas os outros campos habitados por criadores. A pintura tem sido uma fonte muito mais rica de ideias do que a teoria da computação.

Por exemplo, fui ensinado na faculdade que se deve descobrir um programa completamente no papel antes mesmo de chegar perto de um computador. Descobri que não programava dessa maneira. Descobri que gostava de programar sentado na frente de um computador, não em um pedaço de papel. Pior ainda, em vez de escrever pacientemente um programa completo e me certificar de que estava correto, eu tendia a simplesmente vomitar código que estava irremediavelmente quebrado e gradualmente transformá-lo em forma. A depuração, eu aprendi, era uma espécie de passo final onde você pegava erros de digitação e descuidos. Da maneira como eu trabalhava, parecia que a programação consistia em depuração.

Por muito tempo, me senti mal com isso, assim como uma vez me senti mal por não segurar o lápis da maneira como me ensinaram na escola primária. Se eu tivesse olhado para os outros criadores, os pintores ou os arquitetos, eu teria percebido que havia um nome para o que eu estava fazendo: esboçar. Pelo que posso dizer, a maneira como me ensinaram a programar na faculdade estava completamente errada. Você deve descobrir programas à medida que os está escrevendo, assim como escritores e pintores e arquitetos fazem.

Perceber isso tem implicações reais para o design de software. Isso significa que uma linguagem de programação deve, acima de tudo, ser maleável. Uma linguagem de programação é para pensar em programas, não para expressar programas que você já pensou. Deve ser um lápis, não uma caneta. O tipo estático seria uma ótima ideia se as pessoas realmente escrevessem programas da maneira como me ensinaram na faculdade. Mas não é assim que nenhum dos hackers que conheço escrevem programas. Precisamos de uma linguagem que nos permita rabiscar e borrar e manchar, não uma linguagem onde você tem que se sentar com uma xícara de chá de tipos equilibrada no joelho e fazer uma conversa educada com uma tia velha e rígida de um compilador.

Enquanto estamos no assunto de tipagem estática, identificar-se com os criadores nos salvará de outro problema que aflige as ciências: inveja da matemática. Todo mundo nas ciências acredita secretamente que os matemáticos são mais inteligentes do que eles. Acho que os matemáticos também acreditam nisso. De qualquer forma, o resultado é que os cientistas tendem a tornar seu trabalho o mais matemático possível. Em um campo como a física, isso provavelmente não faz muito mal, mas quanto mais você se afasta das ciências naturais, mais esse problema se torna.

Uma página de fórmulas simplesmente parece tão impressionante. (Dica: para impressionar ainda mais, use variáveis gregas.) E então há uma grande tentação de trabalhar em problemas que você pode tratar formalmente, em vez de problemas que são, digamos, importantes.

Se os hackers se identificassem com outros criadores, como escritores e pintores, eles não se sentiriam tentados a fazer isso. Escritores e pintores não sofrem de inveja da matemática. Eles sentem como se estivessem fazendo algo completamente diferente. Então são os hackers, eu acho.

Se as universidades e os laboratórios de pesquisa impedem os hackers de fazer o tipo de trabalho que eles querem fazer, talvez o lugar para eles esteja em empresas. Infelizmente, a maioria das empresas não deixará os hackers fazer o que eles querem também. As universidades e os laboratórios de pesquisa forçam os hackers a serem cientistas, e as empresas os forçam a serem engenheiros.

Eu mesmo descobri isso recentemente. Quando o Yahoo comprou a Viaweb, eles me perguntaram o que eu queria fazer. Nunca gostei muito do lado dos negócios e disse que só queria hackear. Quando cheguei ao Yahoo, descobri que o que hackear significava para eles era implementar software, não projetá-lo. Os programadores eram vistos como técnicos que traduziam as visões (se é que essa é a palavra) dos gerentes de produto em código.

Parece ser o plano padrão em grandes empresas. Eles fazem isso porque diminui o desvio padrão do resultado. Apenas uma pequena porcentagem de hackers pode realmente projetar software, e é difícil para as pessoas que comandam uma empresa identificá-los. Então, em vez de confiar o futuro do software a um hacker brilhante, a maioria das empresas organiza as coisas de modo que seja projetado por comitê, e os hackers apenas implementam o design.

Se você quiser ganhar dinheiro em algum momento, lembre-se disso, porque essa é uma das razões pelas quais as startups vencem. As grandes empresas querem diminuir o desvio padrão dos resultados do design porque querem evitar desastres. Mas quando você amortece as oscilações, você perde os pontos altos, assim como os baixos. Isso não é um problema para as grandes empresas, porque elas não vencem fazendo ótimos produtos. As grandes empresas vencem por serem menos ruins do que outras grandes empresas.

Então, se você puder descobrir uma maneira de entrar em uma guerra de design com uma empresa grande o suficiente para que seu software seja projetado por gerentes de produto, eles nunca conseguirão acompanhá-lo. Essas oportunidades não são fáceis de encontrar, no entanto. É difícil envolver uma grande empresa em uma guerra de design, assim como é difícil envolver um oponente dentro de um castelo em combate corpo a corpo. Seria bem fácil escrever um processador de texto melhor do que o Microsoft Word, por exemplo, mas a Microsoft, dentro do castelo de seu monopólio de sistema operacional, provavelmente nem notaria se você fizesse isso.

O lugar para travar guerras de design é em novos mercados, onde ninguém conseguiu estabelecer ainda quaisquer fortificações. É aí que você pode vencer grande adotando uma abordagem ousada de design e tendo as mesmas pessoas que projetam e implementam o produto. A própria Microsoft fez isso no início. Assim como a Apple. E a Hewlett-Packard. Eu suspeito que quase todas as startups de sucesso fizeram isso.

Então, uma maneira de criar ótimo software é começar sua própria startup. Existem dois problemas com isso, no entanto. Um é que em uma startup você precisa fazer muito além de escrever software. Na Viaweb, eu me considerava sortudo se conseguisse hackear um quarto do tempo. E as coisas que eu tinha que fazer nos outros três quartos variavam de tediosas a aterrorizantes. Eu tenho um parâmetro para isso, porque tive que sair de uma reunião do conselho para tratar de algumas cáries. Lembro-me de estar sentado na cadeira do dentista, esperando pela broca, e me sentindo de férias.

O outro problema com startups é que há pouca sobreposição entre o tipo de software que dá dinheiro e o tipo que é interessante de escrever. Linguagens de programação são interessantes de escrever, e o primeiro produto da Microsoft foi uma, de fato, mas ninguém vai pagar por linguagens de programação agora. Se você quiser ganhar dinheiro, você tende a ser forçado a trabalhar em problemas que são muito desagradáveis para qualquer pessoa resolver gratuitamente.

Todos os criadores enfrentam esse problema. Os preços são determinados pela oferta e demanda, e simplesmente não há tanta demanda por coisas que são divertidas de trabalhar quanto há por coisas que resolvem os problemas mundanos dos clientes individuais. Atuar em peças fora da Broadway simplesmente não paga tão bem quanto usar uma fantasia de gorila no estande de alguém em uma feira comercial. Escrever romances não paga tão bem quanto escrever cópias de anúncios para trituradores de lixo. E hackear linguagens de programação não paga tão bem quanto descobrir como conectar o banco de dados herdado de uma empresa ao seu servidor web.

Acho que a resposta para esse problema, no caso do software, é um conceito conhecido por quase todos os criadores: o emprego durante o dia. Essa expressão começou com músicos, que se apresentam à noite. De maneira mais geral, significa que você tem um tipo de trabalho que faz por dinheiro e outro por amor.

Quase todos os criadores têm empregos durante o dia no início de suas carreiras. Pintores e escritores notoriamente fazem isso. Se você tiver sorte, poderá conseguir um emprego durante o dia que esteja intimamente relacionado ao seu trabalho real. Músicos muitas vezes parecem trabalhar em lojas de discos. Um hacker que trabalha em alguma linguagem de programação ou sistema operacional também pode conseguir um emprego durante o dia usando-o. [1]

Quando digo que a resposta é os hackers terem empregos durante o dia e trabalharem em software bonito no tempo livre, não estou propondo isso como uma nova ideia. Isso é do que o hacking de código aberto trata. O que estou dizendo é que o código aberto provavelmente é o modelo certo, porque foi independentemente confirmado por todos os outros criadores.

Parece surpreendente para mim que qualquer empregador relutaria em deixar os hackers trabalharem em projetos de código aberto. Na Viaweb, teríamos relutado em contratar alguém que não o fizesse. Quando entrevistávamos programadores, a principal coisa que nos importava era que tipo de software eles escreviam em seu tempo livre. Você não pode fazer nada realmente bem a menos que ame, e se você ama hackear, inevitavelmente estará trabalhando em projetos próprios. [2]

Porque os hackers são criadores em vez de cientistas, o lugar certo para procurar metáforas não está nas ciências, mas entre outros tipos de criadores. O que mais a pintura pode nos ensinar sobre hacking?

Uma coisa que podemos aprender, ou pelo menos confirmar, com o exemplo da pintura é como aprender a hackear. Você aprende a pintar principalmente fazendo. O mesmo vale para o hacking. A maioria dos hackers não aprende a hackear fazendo cursos universitários de programação. Eles aprendem a hackear escrevendo programas próprios aos 13 anos. Mesmo em aulas na faculdade, você aprende a hackear principalmente hackeando. [3]

Porque os pintores deixam um rastro de trabalho atrás deles, você pode vê-los aprender fazendo. Se você olhar para o trabalho de um pintor em ordem cronológica, você descobrirá que cada pintura se baseia em coisas que foram aprendidas em pinturas anteriores. Quando há algo em uma pintura que funciona muito bem, você geralmente pode encontrar a versão 1 disso em uma forma menor em alguma pintura anterior.

Acho que a maioria dos criadores trabalha dessa maneira. Escritores e arquitetos também parecem fazer isso. Talvez fosse bom para os hackers agir mais como os pintores e regularmente recomeçar do zero, em vez de continuar trabalhando por anos em um projeto e tentar incorporar todas as suas ideias posteriores como revisões.

O fato de os hackers aprenderem a hackear fazendo é outro sinal de quão diferente o hacking é das ciências. Os cientistas não aprendem ciência fazendo, mas fazendo laboratórios e listas de problemas. Os cientistas começam fazendo um trabalho que é perfeito, no sentido de que eles estão apenas tentando reproduzir o trabalho que alguém já fez para eles. Eventualmente, eles chegam ao ponto em que podem fazer um trabalho original. Enquanto os hackers, desde o início, estão fazendo um trabalho original; é apenas muito ruim. Então os hackers começam originais e ficam bons, e os cientistas começam bons e ficam originais.

A outra maneira como os criadores aprendem é com 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 dos pintores copiar as obras dos grandes mestres, porque copiar os força a olhar de perto a maneira como uma pintura é feita.

Os escritores também fazem isso. Benjamin Franklin aprendeu a escrever resumindo os pontos nos ensaios de Addison e Steele e, em seguida, tentando reproduzi-los. Raymond Chandler fez a mesma coisa com histórias de detetive.

Os hackers, da mesma forma, podem aprender a programar olhando para bons programas - não apenas o que eles fazem, mas também o código-fonte. Um dos benefícios menos divulgados do movimento de código aberto é que ele facilitou o aprendizado de programação. Quando eu aprendi a programar, tínhamos que confiar principalmente em exemplos em livros. O único grande pedaço de código disponível na época era o Unix, mas mesmo isso não era de código aberto. A maioria das pessoas que leram a fonte leu em fotocópias ilegais do livro de John Lions, que, embora escrito em 1977, não pôde ser publicado até 1996.

Outro exemplo que podemos tirar da pintura é a maneira como as pinturas são criadas por refinamento gradual. As pinturas geralmente começam com um esboço. Gradualmente, os detalhes são preenchidos. Mas não é apenas um processo de preenchimento. Às vezes, os planos originais se revelam errados. Inúmeras pinturas, quando você as examina com raios X, revelam-se ter membros que foram movidos ou características faciais que foram reajustadas.

Aqui está um caso em que podemos aprender com a pintura. Acho que o hacking também deve funcionar dessa maneira. É irrealista esperar que as especificações de um programa sejam perfeitas. Você fica melhor se admitir isso de antemão e escrever programas de uma maneira que permita que as especificações mudem no voo.

(A estrutura de grandes empresas torna isso difícil para elas fazerem, então aqui está outro lugar onde as startups têm uma vantagem.)

Todo mundo agora presumivelmente sabe sobre o perigo da otimização prematura. Acho que devemos nos preocupar tanto com o design prematuro - decidir muito cedo o que um programa deve fazer.

As ferramentas certas podem nos ajudar a evitar esse perigo. Uma boa linguagem de programação deve, como a tinta a óleo, facilitar a mudança de opinião. A digitação dinâmica é uma vitória aqui porque você não precisa se comprometer com representações de dados específicas desde o início. Mas a chave para a flexibilidade, acho eu, é tornar a linguagem muito abstrata. O programa mais fácil de mudar é aquele que é muito curto.

Isso parece um paradoxo, mas uma grande pintura tem que ser melhor do que precisa ser. Por exemplo, quando Leonardo pintou o retrato de Ginevra de Benci na National Gallery, ele colocou um arbusto de zimbro atrás da cabeça dela. Nele, ele cuidadosamente pintou cada folha individual. Muitos pintores poderiam ter pensado, isso é apenas algo para colocar no fundo para enquadrar a cabeça dela. Ninguém olhará tão de perto para isso.

Não Leonardo. Quão duro ele trabalhou em uma parte de uma pintura não dependia de forma alguma de quão de perto ele esperava que alguém olhasse para ela. Ele era como Michael Jordan. Implacável.

A implacabilidade vence porque, no agregado, os detalhes não vistos se tornam visíveis. Quando as pessoas passam pelo retrato de Ginevra de Benci, sua atenção é muitas vezes imediatamente presa a ele, mesmo antes de olharem para o rótulo e notarem que diz Leonardo da Vinci. Todos esses detalhes não vistos se combinam para produzir algo que é simplesmente deslumbrante, como mil vozes quase inaudíveis cantando em uníssono.

Um ótimo software, da mesma forma, requer uma devoção fanática à beleza. Se você olhar para dentro de um bom software, você encontrará que as partes que ninguém deve ver são lindas também. Não estou afirmando que escrevo um ótimo software, mas eu sei que quando se trata de código, me comporto de uma maneira que me tornaria elegível para medicamentos com receita se eu abordasse a vida cotidiana da mesma maneira. Me deixa louco ver código que está mal indentado, ou que usa nomes de variáveis feios.

Se um hacker fosse um mero implementador, transformando uma especificação em código, então ele poderia apenas trabalhar de um extremo ao outro como alguém cavando uma vala. Mas se o hacker é um criador, temos que levar em conta a inspiração.

Em programação, como em pintura, o trabalho vem em ciclos. Às vezes você fica empolgado com algum novo projeto e você quer trabalhar dezesseis horas por dia nele. Outras vezes nada parece interessante.

Para fazer um bom trabalho, você tem que levar esses ciclos em conta, porque eles são afetados por como você reage a eles. Quando você está dirigindo um carro com transmissão manual em uma colina, você tem que soltar a embreagem às vezes para evitar morrer. Soltar também pode evitar que a ambição morra. Tanto em pintura quanto em programação, existem algumas tarefas que são terrivelmente ambiciosas, e outras que são reconfortantemente rotineiras. É uma boa ideia reservar algumas tarefas fáceis para momentos em que você de outra forma morreria.

Em programação, isso pode literalmente significar guardar alguns bugs. Eu gosto de depurar: é a única vez que a programação é tão direta quanto as pessoas pensam que é. Você tem um problema totalmente restrito, e tudo o que você precisa fazer é resolvê-lo. Seu programa deve fazer x. Em vez disso, ele faz y. Onde ele dá errado? Você sabe que vai vencer no final. É tão relaxante quanto pintar uma parede.

O exemplo da pintura pode nos ensinar não apenas como gerenciar nosso próprio trabalho, mas como trabalhar juntos. Muita da grande arte do passado é o trabalho de várias mãos, embora possa haver apenas um nome na parede ao lado dela no museu. Leonardo era aprendiz no workshop de Verrocchio e pintou um dos anjos em seu Batismo de Cristo. Esse tipo de coisa era a regra, não a exceção. Michelangelo foi considerado especialmente dedicado por insistir em pintar todas as figuras no teto da Capela Sistina ele mesmo.

Tanto quanto eu sei, quando os pintores trabalhavam juntos em uma pintura, eles nunca trabalhavam nas mesmas partes. Era comum o mestre pintar as figuras principais e os assistentes pintar as outras e o fundo. Mas você nunca tinha um cara pintando sobre o trabalho de outro.

Acho que esse é o modelo certo para a colaboração em software também. Não force demais. Quando um pedaço de código está sendo hackeado por três ou quatro pessoas diferentes, nenhuma das quais realmente o possui, ele acabará se parecendo com uma sala comum. Ele tenderá a se sentir sombrio e abandonado, e acumular sujeira. A maneira certa de colaborar, acho, é dividir projetos em módulos claramente definidos, cada um com um proprietário definido, e com interfaces entre eles que sejam tão cuidadosamente projetadas e, se possível, tão articuladas quanto as linguagens de programação.

Como a pintura, a maior parte do software é destinada a um público humano. E, portanto, os hackers, como os pintores, devem ter empatia para fazer um trabalho realmente excelente. Você precisa ser capaz de ver as coisas do ponto de vista do usuário.

Quando eu era criança, sempre me diziam para ver as coisas do ponto de vista de outra pessoa. O que isso sempre significava na prática era fazer o que outra pessoa queria, em vez do que eu queria. Isso, é claro, deu à empatia uma má reputação, e eu me esforcei para não cultivá-la.

Puxa, eu estava errado. Resulta que olhar as coisas do ponto de vista dos outros é praticamente o segredo do sucesso. Isso não significa necessariamente ser abnegado. Longe disso. Entender como outra pessoa vê as coisas não implica que você agirá em seu interesse; em algumas situações - em guerra, por exemplo - você quer fazer exatamente o oposto. [4]

A maioria dos criadores faz coisas para um público humano. E para envolver uma audiência, você precisa entender o que eles precisam. Quase todas as maiores pinturas são pinturas de pessoas, por exemplo, porque as pessoas são o que as pessoas se interessam.

A empatia é provavelmente a única diferença mais importante entre um bom hacker e um ótimo. Alguns hackers são bastante inteligentes, mas quando se trata de empatia, são praticamente solipsistas. É difícil para essas pessoas projetar um ótimo software [5], porque elas não conseguem ver as coisas do ponto de vista do usuário.

Uma maneira de saber o quão boas as pessoas são em empatia é observá-las explicar uma questão técnica para alguém sem formação técnica. Provavelmente todos conhecemos pessoas que, embora de outra forma inteligentes, são simplesmente comicamente ruins nisso. Se alguém lhes pergunta em uma festa de jantar o que é uma linguagem de programação, eles dirão algo como "Oh, uma linguagem de alto nível é o que o compilador usa como entrada para gerar código de objeto". Linguagem de alto nível? Compilador? Código de objeto? Alguém que não sabe o que é uma linguagem de programação obviamente também não sabe o que são essas coisas.

Parte do que o software precisa fazer é se explicar. Então, para escrever um bom software, você precisa entender o quão pouco os usuários entendem. Eles vão se aproximar do software sem nenhum preparo, e ele deve fazer o que eles adivinham que fará, porque eles não vão ler o manual. O melhor sistema que já vi nesse aspecto foi o Macintosh original, em 1985. Ele fez o que o software quase nunca faz: simplesmente funcionou. [6]

O código-fonte também deve se explicar. Se eu pudesse fazer as pessoas se lembrarem de apenas uma citação sobre programação, seria a que está no início de Structure and Interpretation of Computer Programs.

Os programas devem ser escritos para que as pessoas leiam, e apenas incidentalmente para que as máquinas executem.

Você precisa ter empatia não apenas com seus usuários, mas também com seus leitores. É do seu interesse, porque você será um deles. Muitos hackers escreveram um programa apenas para descobrir, ao retornar a ele seis meses depois, que não têm ideia de como ele funciona. Conheço várias pessoas que juraram nunca mais usar Perl depois de experiências assim. [7]

A falta de empatia está associada à inteligência, a ponto de haver até mesmo uma moda por ela em alguns lugares. Mas não acho que haja qualquer correlação. Você pode se sair bem em matemática e ciências naturais sem ter que aprender empatia, e as pessoas nesses campos tendem a ser inteligentes, então as duas qualidades acabaram se associando. Mas há muitas pessoas burras que também são ruins em empatia. Basta ouvir as pessoas que ligam com perguntas em programas de rádio. Eles fazem a pergunta que quer que seja de uma maneira tão indireta que os apresentadores muitas vezes precisam reformular a pergunta para eles.

Então, se o hacking funciona como a pintura e a escrita, é tão legal? Afinal, você só tem uma vida. Você pode muito bem gastá-la trabalhando em algo grandioso.

Infelizmente, a pergunta é difícil de responder. Sempre há um grande atraso de prestígio. É como a luz de uma estrela distante. A pintura tem prestígio agora por causa do ótimo trabalho que as pessoas fizeram há quinhentos anos. Na época, ninguém achava que essas pinturas eram tão importantes quanto achamos hoje. Teria parecido muito estranho para as pessoas da época que Federico da Montefeltro, o Duque de Urbino, um dia fosse conhecido principalmente como o cara com o nariz estranho em uma pintura de Piero della Francesca.

Então, embora eu admita que o hacking não parece tão legal quanto a pintura agora, devemos lembrar que a própria pintura não parecia tão legal em seus dias de glória quanto parece agora.

O que podemos dizer com alguma confiança é que estes são os dias de glória do hacking. Na maioria dos campos, o grande trabalho é feito no início. As pinturas feitas entre 1430 e 1500 ainda não foram superadas. Shakespeare apareceu assim que o teatro profissional estava nascendo e empurrou o meio tão longe que todo dramaturgo desde então teve que viver à sua sombra. Albrecht Durer fez o mesmo com a gravura e Jane Austen com o romance.

Repetidamente, vemos o mesmo padrão. Um novo meio aparece e as pessoas ficam tão entusiasmadas com ele que exploram a maior parte de suas possibilidades nas primeiras gerações. O hacking parece estar nesta fase agora.

A pintura não era, no tempo de Leonardo, tão legal quanto seu trabalho ajudou a torná-la. Quão legal o hacking vai se tornar dependerá do que podemos fazer com este novo meio.

Notas

[1] O maior dano que a fotografia fez à pintura pode ser o fato de ter matado o melhor bico de obra. A maioria dos grandes pintores da história se sustentava pintando retratos.

[2] Disseram-me que a Microsoft desencoraja os funcionários de contribuir para projetos de código aberto, mesmo em seu tempo livre. Mas tantos dos melhores hackers trabalham em projetos de código aberto agora que o principal efeito dessa política pode ser garantir que eles não consigam contratar nenhum programador de primeira linha.

[3] O que você aprende sobre programação na faculdade é muito parecido com o que você aprende sobre livros, roupas ou namoro: que mau gosto você tinha no ensino médio.

[4] Aqui está um exemplo de empatia aplicada. Na Viaweb, se não conseguíssemos decidir entre duas alternativas, perguntaríamos: o que nossos concorrentes odiariam mais? Em certo momento, um concorrente adicionou um recurso ao seu software que era basicamente inútil, mas como era um dos poucos que eles tinham que nós não tínhamos, eles fizeram muito alarde sobre isso na imprensa do setor. Poderíamos ter tentado explicar que o recurso era inútil, mas decidimos que irritaria mais nosso concorrente se simplesmente o implementássemos nós mesmos, então hackearíamos nossa própria versão naquela mesma tarde.

[5] Exceto editores de texto e compiladores. Os hackers não precisam de empatia para projetar esses, porque eles próprios são usuários típicos.

[6] Bem, quase. Eles ultrapassaram um pouco a RAM disponível, causando muita troca de disco inconveniente, mas isso poderia ser corrigido em alguns meses comprando um disco adicional.

[7] A maneira de tornar os programas fáceis de ler não é enchê-los de comentários. Eu levaria a citação de Abelson e Sussman um passo adiante. As linguagens de programação devem ser projetadas para expressar algoritmos e apenas incidentalmente para dizer aos computadores como executá-los. Uma boa linguagem de programação deve ser melhor para explicar software do que o inglês. Você só deve precisar de comentários quando houver algum tipo de gambiarra que você precise avisar os leitores, assim como em uma estrada há apenas setas em partes com curvas inesperadamente acentuadas.

Agradecimentos a Trevor Blackwell, Robert Morris, Dan Giffin e Lisa Randall por lerem rascunhos deste texto, e a Henry Leitner e Larry Finkelstein por me convidarem para falar.