HACKERS E PINTORES

Maio de 2003

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

Quando terminei a pós-graduação em ciência da computação, fui para a escola de arte estudar pintura. Muitas pessoas pareciam surpresas que alguém interessado em computadores também estivesse interessado em pintura. Elas pareciam pensar 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 primal.

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 descubram 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 é um saco de áreas tenuamente relacionadas jogadas juntas 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 estão fazendo de ciência da computação para poderem conseguir subsídios da DARPA. No meio você tem pessoas trabalhando em algo como a história natural dos computadores-- estudando o comportamento de algoritmos para roteamento de 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 todos no mesmo departamento.

Às vezes o que os hackers fazem é chamado de "engenharia de software," mas esse termo é igualmente enganoso. Bons designers de software não são mais engenheiros do que arquitetos são. A fronteira entre arquitetura e engenharia não é claramente definida, mas está lá. Ela cai entre o que e como: arquitetos decidem o que fazer, e engenheiros descobrem como fazê-lo.

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

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

Agrupar todos esses diferentes tipos de trabalho 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." Pode-se argumentar que as pessoas no meio estão fazendo algo como uma ciência experimental. Mas as pessoas em cada extremo, os hackers e os matemáticos, não estão realmente fazendo ciência.

Os matemáticos não parecem se incomodar com isso. Eles se dedicam felizmente a provar teoremas como os outros matemáticos do departamento de matemática, e provavelmente logo param de notar que o prédio em que trabalham diz "ciência da computação" do lado de fora. Mas para os hackers esse rótulo é um problema. Se o que estão fazendo é chamado de ciência, isso os faz sentir que deveriam agir de forma científica. Então, em vez de fazer o que realmente querem fazer, que é desenhar software bonito, 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. Hackers escrevem software legal e depois escrevem um artigo sobre isso, e o artigo se torna um proxy para a realização representada pelo software. Mas muitas vezes esse descompasso causa problemas. É fácil se desviar de construir coisas bonitas para construir coisas feias que fazem temas mais adequados para artigos de pesquisa.

Infelizmente, coisas bonitas nem sempre fazem os melhores temas para artigos. Número um, a pesquisa deve ser original-- e como qualquer um que já escreveu uma dissertação de doutorado sabe, a maneira de ter certeza de que você está explorando território virgem é reivindicar um pedaço de terreno que ninguém quer. Número dois, a pesquisa deve ser substantiva-- e sistemas complicados geram artigos mais substanciais, porque você pode escrever sobre os obstáculos que tem que superar para conseguir fazer as coisas. Nada gera problemas substanciais como começar com as suposições erradas. A maior parte da IA é um exemplo dessa regra; se você assumir 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 para escrever sobre como fazer isso funcionar. Como Ricky Ricardo costumava dizer, "Lucy, você tem muito a explicar."

A maneira de criar algo bonito é muitas vezes fazer ajustes sutis 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 universidades e laboratórios de pesquisa continuam a julgar hackers por publicações? Pela mesma razão que "aptidão escolar" é medida por testes padronizados simplistas, ou a produtividade de 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 de certa forma.

Medir o que 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, coisas bonitas tendem a prosperar, e coisas 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 convergir. Você tem que esperar que os amigos influentes do escritor morram, e então que todos os seus seguidores morram.

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

Existem coisas piores do que ter pessoas mal interpretando seu trabalho. Um perigo pior é que você mesmo mal interprete seu trabalho. Campos relacionados são onde você vai em busca de ideias. Se você se encontrar no departamento de ciência da computação, há uma tentação natural de acreditar, por exemplo, que hackear é a versão aplicada do que a ciência da computação teórica é a teoria de. Durante todo o tempo em que estive na pós-graduação, tive uma sensação desconfortável na parte de trás da minha mente de que deveria saber mais teoria, e que era muito negligente da minha parte ter esquecido todas aquelas coisas dentro de três semanas após o exame final.

Agora percebo que estava enganado. Hackers precisam entender a teoria da computação tanto quanto pintores precisam entender a química da tinta. Você precisa saber como calcular a complexidade de tempo e espaço e sobre completude de Turing. Você também pode querer lembrar pelo menos o conceito de uma máquina de estados, caso precise escrever um analisador ou uma biblioteca de expressões regulares. Pintores, na verdade, precisam lembrar muito mais sobre 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 de ideias muito mais rica do que a teoria da computação.

Por exemplo, fui ensinado na faculdade que se deve entender um programa completamente no papel antes de sequer se aproximar de um computador. Descobri que não programava dessa maneira. Descobri que gostava de programar sentado em frente a um computador, não a um pedaço de papel. Pior ainda, em vez de pacientemente escrever um programa completo e me assegurar de que estava correto, eu tendia a apenas despejar código que estava desesperadamente quebrado, e gradualmente moldá-lo. Depuração, fui ensinado, era uma espécie de passada final onde você pegava erros de digitação e descuidos. Do jeito que eu trabalhava, parecia que programar consistia em depurar.

Por muito tempo me senti mal por isso, assim como uma vez me senti mal por não segurar meu lápis da maneira que me ensinaram na escola primária. Se eu tivesse apenas olhado para os outros criadores, os pintores ou os arquitetos, eu teria percebido que havia um nome para o que eu estava fazendo: esboçando. Até onde posso dizer, a maneira como me ensinaram a programar na faculdade estava toda errada. Você deve entender os programas enquanto os escreve, assim como escritores, 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. A tipagem estática seria uma boa ideia se as pessoas realmente escrevessem programas da maneira que me ensinaram na faculdade. Mas não é assim que nenhum dos hackers que conheço escreve programas. Precisamos de uma linguagem que nos deixe rabiscar e borrar e manchar, não uma linguagem onde você tem que sentar com uma xícara de tipos equilibrada em seu joelho e fazer conversa educada com uma estrita tia velha de um compilador.

Enquanto estamos no assunto da tipagem estática, identificar-se com os criadores nos salvará de outro problema que aflige as ciências: a inveja da matemática. Todos na ciência acreditam secretamente que 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 fazer seu trabalho parecer o mais matemático possível. Em um campo como a física, isso provavelmente não causa muito dano, mas quanto mais longe você se afasta das ciências naturais, mais problema isso se torna.

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

Se 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 não relacionado. Assim são os hackers, eu acho.

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

Descobri isso recentemente. Quando o Yahoo comprou Viaweb, eles me perguntaram o que eu queria fazer. Eu nunca gostei muito do lado comercial 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. Programadores eram vistos como técnicos que traduziam as visões (se essa é a palavra) dos gerentes de produto em código.

Esse 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 dirigem 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 ele seja projetado por um 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 startups vencem. Grandes empresas querem diminuir o desvio padrão dos resultados de design porque querem evitar desastres. Mas quando você amortiza oscilações, você perde os altos tanto quanto os baixos. Isso não é um problema para grandes empresas, porque elas não vencem fazendo grandes produtos. Grandes empresas vencem por serem menos ruins do que outras grandes empresas.

Então, se você conseguir 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 acompanhar você. 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 bastante 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ê o fizesse.

O lugar para lutar guerras de design é em novos mercados, onde ninguém conseguiu ainda estabelecer fortificações. É lá que você pode ganhar muito adotando a abordagem ousada de design, e tendo as mesmas pessoas tanto projetando quanto implementando o produto. A Microsoft fez isso no início. A Apple também. E a Hewlett-Packard. Suspeito que quase toda startup de sucesso fez.

Então, uma maneira de construir um grande software é começar sua própria startup. Existem dois problemas com isso, no entanto. Um é que em uma startup você tem que fazer muito mais 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 os outros três quartos do tempo variavam de tediosas a aterrorizantes. Tenho um parâmetro para isso, porque uma vez tive que sair de uma reunião de diretoria para fazer alguns tratamentos dentários. Lembro-me de estar sentado na cadeira do dentista, esperando pela broca, e sentindo que estava de férias.

O outro problema com startups é que não há muita sobreposição entre o tipo de software que gera 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, na verdade, mas ninguém pagará por linguagens de programação agora. Se você quiser ganhar dinheiro, tende a ser forçado a trabalhar em problemas que são muito desagradáveis para alguém resolver de graça.

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 de clientes individuais. Atuar em peças off-Broadway simplesmente não paga tão bem quanto vestir um traje de gorila no estande de alguém em uma feira comercial. Escrever romances não paga tão bem quanto escrever textos publicitários para trituradores de lixo. E hackear linguagens de programação não paga tão bem quanto descobrir como conectar o banco de dados legado de alguma 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 trabalho diurno. Essa frase começou com músicos, que se apresentam à noite. Mais geralmente, significa que você tem um tipo de trabalho que faz por dinheiro, e outro por amor.

Quase todos os criadores têm empregos diurnos no início de suas carreiras. Pintores e escritores notoriamente têm. Se você tiver sorte, pode conseguir um emprego diurno 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 pode igualmente conseguir um emprego diurno usando-a. [1]

Quando digo que a resposta é que hackers tenham empregos diurnos, e trabalhem em software bonito como um projeto paralelo, não estou propondo isso como uma nova ideia. Isso é do que se trata o hacking de código aberto. O que estou dizendo é que o código aberto é provavelmente o modelo certo, porque foi confirmado independentemente por todos os outros criadores.

Parece surpreendente para mim que qualquer empregador relutaria em deixar 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 isso, e se você ama hackear, inevitavelmente estará trabalhando em projetos próprios. [2]

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

Uma coisa que podemos aprender, ou pelo menos confirmar, com o exemplo da pintura é como aprender a hackear. Você aprende a pintar principalmente fazendo isso. O mesmo vale para hackear. 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 treze anos. Mesmo em aulas universitárias, você aprende a hackear principalmente hackeando. [3]

Como 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, descobrirá que cada pintura se baseia em coisas que foram aprendidas nas 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 parecem fazer o mesmo. Talvez seja bom para hackers agir mais como pintores, e começar regularmente 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 que hackers aprendem a hackear fazendo isso é outro sinal de quão diferente o hacking é das ciências. Cientistas não aprendem ciência fazendo-a, mas fazendo laboratórios e conjuntos de problemas. Cientistas começam fazendo um trabalho que é perfeito, no sentido de que estão apenas tentando reproduzir o trabalho que alguém mais já fez por eles. Eventualmente, eles chegam ao ponto em que podem fazer trabalho original. Enquanto hackers, desde o início, estão fazendo trabalho original; é apenas muito ruim. Então hackers começam originais, e ficam bons, e cientistas começam bons, e ficam originais.

A outra maneira que os criadores aprendem é a partir de 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 força você a olhar de perto a maneira como uma pintura é feita.

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

Hackers, da mesma forma, podem aprender a programar olhando para bons programas-- não apenas para o que eles fazem, mas o código fonte também. Um dos benefícios menos divulgados do movimento de código aberto é que ele facilitou aprender a programar. Quando 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 código aberto. A maioria das pessoas que leu o código leu em cópias ilícitas 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 é meramente um processo de preenchimento. Às vezes os planos originais acabam sendo errôneos. Incontáveis pinturas, quando você as olha em raios-X, acabam tendo membros que foram movidos ou características faciais que foram ajustadas.

Aqui está um caso onde podemos aprender com a pintura. Acho que o hacking deve funcionar assim também. É irrealista esperar que as especificações para um programa sejam perfeitas. Você está melhor se admitir isso desde o início, e escrever programas de uma maneira que permita que as especificações mudem em tempo real.

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

Todos agora presumivelmente sabem 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 tinta a óleo, facilitar mudar de ideia. A tipagem dinâmica é uma vitória aqui porque você não precisa comprometer-se com representações de dados específicas desde o início. Mas a chave para a flexibilidade, eu acho, é tornar a linguagem muito abstrata. O programa mais fácil de mudar é um que é muito curto.

Isso soa como 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 emoldurar sua cabeça. Ninguém olhará tão de perto.

Não Leonardo. O quão duro ele trabalhou em parte de uma pintura não dependia nem um pouco de quão de perto ele esperava que alguém olhasse para isso. Ele era como Michael Jordan. Incansável.

A incansabilidade vence porque, no agregado, detalhes não vistos se tornam visíveis. Quando as pessoas passam pelo retrato de Ginevra de Benci, sua atenção é muitas vezes imediatamente capturada por ele, mesmo antes de olharem para o rótulo e notarem que diz Leonardo da Vinci. Todos aqueles detalhes não vistos se combinam para produzir algo que é simplesmente deslumbrante, como mil vozes mal audíveis cantando em harmonia.

Um grande software, da mesma forma, requer uma devoção fanática à beleza. Se você olhar dentro de um bom software, descobrirá que partes que ninguém deve ver também são bonitas. Não estou afirmando que escrevo um grande software, mas eu sei que quando se trata de código eu me comporto de uma maneira que me tornaria elegível para medicamentos prescritos se eu abordasse a vida cotidiana da mesma forma. Isso 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 simplesmente trabalhar de um lado para o outro como alguém cavando uma vala. Mas se o hacker é um criador, temos que levar a inspiração em conta.

No hacking, como na pintura, o trabalho vem em ciclos. Às vezes você fica animado com algum novo projeto e 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 que o motor morra. Soltar também pode evitar que a ambição morra. Tanto na pintura quanto no hacking, há algumas tarefas que são aterradoramente ambiciosas, e outras que são confortavelmente rotineiras. É uma boa ideia guardar algumas tarefas fáceis para momentos em que você, de outra forma, estagnaria.

No hacking, isso pode literalmente significar guardar bugs. Eu gosto de depurar: é a única vez que hackear é tão direto 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, faz y. Onde ele se perde? 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. Muito da grande arte do passado é o trabalho de múltiplas mãos, embora possa haver apenas um nome na parede ao lado dela no museu. Leonardo foi um aprendiz na oficina 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.

Até onde sei, quando pintores trabalhavam juntos em uma pintura, eles nunca trabalhavam nas mesmas partes. Era comum que o mestre pintasse as figuras principais e que assistentes pintassem as outras e o fundo. Mas você nunca tinha um cara pintando sobre o trabalho de outro.

Acho que esse é o modelo certo para colaboração em software também. Não leve isso muito longe. 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á sendo como uma sala comum. Ele tende a parecer sombrio e abandonado, e acumular lixo. A maneira certa de colaborar, eu acho, é dividir projetos em módulos definidos com clareza, 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 linguagens de programação.

Como a pintura, a maioria do software é destinado a um público humano. E assim hackers, como pintores, devem ter empatia para fazer um trabalho realmente grande. Você tem que ser capaz de ver as coisas do ponto de vista do usuário.

Quando eu era criança, sempre me diziam para olhar 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á fama, e eu fiz um ponto de não cultivá-la.

Rapaz, eu estava errado. Acontece que olhar as coisas do ponto de vista de outras pessoas é praticamente o segredo do sucesso. Não significa necessariamente ser auto-sacrificial. Longe disso. Entender como outra pessoa vê as coisas não implica que você agirá em seu interesse; em algumas situações-- na guerra, por exemplo-- você quer fazer exatamente o oposto. [4]

A maioria dos criadores faz coisas para um público humano. E para envolver um público você tem que 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 estão interessadas.

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

Uma maneira de dizer quão boas as pessoas são em empatia é observar como explicam uma questão técnica para alguém sem um contexto técnico. Provavelmente todos nós conhecemos pessoas que, embora sejam inteligentes de outras formas, são apenas cômicas nesse aspecto. Se alguém lhes pergunta em uma festa 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 objeto." Linguagem de alto nível? Compilador? Código objeto? Alguém que não sabe o que é uma linguagem de programação obviamente não sabe o que essas coisas são, também.

Parte do que o software tem que fazer é explicar-se. Então, para escrever um bom software, você tem que entender o quão pouco os usuários entendem. Eles vão se aproximar do software sem preparação, e é melhor que ele faça o que eles adivinharem 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 explicar-se. Se eu pudesse fazer as pessoas lembrar de apenas uma citação sobre programação, seria a que está no início de Structure and Interpretation of Computer Programs.

Programas devem ser escritos para pessoas lerem, e apenas incidentalmente para máquinas executarem.

Você precisa ter empatia não apenas por seus usuários, mas por seus leitores. Está em seu interesse, porque você será um deles. Muitos hackers escreveram um programa apenas para descobrir ao voltar a ele seis meses depois que não têm ideia de como funciona. Conheço várias pessoas que juraram não usar Perl após experiências assim. [7]

A falta de empatia está associada à inteligência, a tal ponto que há até uma certa moda por isso em alguns lugares. Mas não acho que haja qualquer correlação. Você pode se sair bem em matemática e nas 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 entrevistas. Elas fazem o que quer que estejam perguntando de uma maneira tão indireta que os apresentadores muitas vezes têm que reformular a pergunta para elas.

Então, se hackear funciona como pintar e escrever, é tão legal? Afinal, você só tem uma vida. Você pode muito bem passar isso trabalhando em algo grandioso.

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

Então, enquanto admito que hackear não parece tão legal quanto pintar agora, devemos lembrar que a pintura em si 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 são insuperadas. Shakespeare apareceu exatamente quando o teatro profissional estava nascendo,

e empurrou o meio tanto que todo dramaturgo desde então teve que viver em sua sombra. Albrecht Durer fez a mesma coisa com a gravura, e Jane Austen com o romance.

Repetidamente vemos o mesmo padrão. Um novo meio aparece, e as pessoas estão tão empolgadas com isso que exploram a maioria de suas possibilidades nas primeiras gerações. O hacking parece estar nessa fase agora.

A pintura não era, na época de Leonardo, tão legal quanto seu trabalho ajudou a torná-la. Quão legal o hacking se revela dependerá do que podemos fazer com esse novo meio.

Notas

[1] O maior dano que a fotografia causou à pintura pode ser o fato de que matou o melhor emprego diurno. A maioria dos grandes pintores da história sustentou a si mesmos pintando retratos.

[2] Fui informado de que a Microsoft desencoraja 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 programadores de primeira linha.

[3] O que você aprende sobre programação na faculdade é muito parecido com o que você aprende sobre livros ou roupas ou encontros: o mau gosto que 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 mais odiariam? Em um ponto, 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, eles fizeram muito disso na imprensa especializada. Poderíamos ter tentado explicar que o recurso era inútil, mas decidimos que irritaria mais nosso concorrente se nós simplesmente implementássemos nós mesmos, então hackeamos nossa própria versão naquela tarde.

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

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

[7] A maneira de tornar os programas fáceis de ler não é encher eles de comentários. Eu levaria a citação de Abelson e Sussman um passo adiante. 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 deveria 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ê precisa avisar os leitores, assim como em uma estrada só há setas em partes com curvas inesperadamente acentuadas.

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