HACKERS E PINTORES

Maio de 2003

(Este ensaio é derivado de uma palestra de convidado 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 para estudar pintura. Muitas pessoas pareciam surpresas que alguém interessado em computadores também se interessasse por pintura. Elas pareciam pensar que hacking e pintura eram tipos de trabalho muito diferentes — que hacking era frio, preciso e metódico, e que pintura era a expressão frenética de algum desejo primitivo.

Ambas as imagens estão erradas. Hacking e pintura têm muito em comum. Na verdade, de todos os diferentes tipos de pessoas que 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 propriamente dita, embora se no curso de tentar criar coisas boas eles descubram alguma técnica nova, 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. A ciência da computação é uma miscelânea de áreas tenuamente relacionadas, reunidas por um acidente da história, como a Iugoslávia. Em uma ponta, você tem pessoas que são realmente matemáticas, mas chamam o que estão fazendo de ciência da computação para que possam obter bolsas 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 por redes, por exemplo. E então, no outro extremo, você tem os hackers, que estão tentando escrever software interessante, e para quem os computadores são apenas 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 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. A fronteira entre arquitetura e engenharia não é nitidamente definida, mas está lá. Ela fica entre o que e como: arquitetos decidem o que fazer, e engenheiros descobrem como fazer.

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. Na melhor das hipóteses, é criar a especificação — embora acabe descobrindo 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 isso significasse independência para minha terra natal, o hacking.

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 ponta, os hackers e os matemáticos, não estão realmente fazendo ciência.

Os matemáticos não parecem incomodados com isso. Eles alegremente começam a trabalhar provando 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 eles estão fazendo é chamado de ciência, isso os faz sentir que deveriam estar agindo cientificamente. Então, em vez de fazer o que realmente querem fazer, que é projetar 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. Hackers escrevem softwares legais e, então, escrevem um artigo sobre eles, e o artigo se torna um proxy para a conquista representada pelo software. Mas, frequentemente, essa incompatibilidade causa problemas. É fácil se afastar da construção de coisas bonitas para a construção de coisas feias que se tornam assuntos mais adequados para artigos de pesquisa.

Infelizmente, coisas bonitas nem sempre são os melhores assuntos para artigos. Número um, 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 é demarcar um pedaço de terreno que ninguém quer. Número dois, a pesquisa deve ser substancial — e sistemas estranhos produzem artigos mais substanciais, porque você pode escrever sobre os obstáculos que precisa superar para fazer as coisas. Nada produz 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 lógicas 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 o que explicar."

A maneira de criar algo bonito é frequentemente fazer ajustes sutis em algo que já existe, ou combinar ideias existentes de uma forma 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 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 meio que funciona.

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, coisas bonitas tendem a prosperar, e coisas feias tendem a ser descartadas. Infelizmente, as quantidades de tempo envolvidas podem ser maiores do que as vidas humanas. Samuel Johnson disse que levou cem anos para a reputação de um escritor 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 só precisam 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 têm sorte em comparação. A influência da moda não é nem de longe tão grande no hacking quanto na pintura.

Há coisas piores do que ter pessoas que não entendem seu trabalho. Um perigo pior é que você mesmo não entenda seu trabalho. Campos relacionados são onde você vai em busca de ideias. Se você se encontra no departamento de ciência da computação, há uma tentação natural de acreditar, por exemplo, que hacking é a versão aplicada do que a ciência da computação teórica é a teoria. Durante todo o tempo em que estive na pós-graduação, tive uma sensação desconfortável no fundo da minha mente de que eu deveria saber mais teoria, e que foi muito negligente da minha parte ter esquecido tudo isso em menos de três semanas do 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 a completude de Turing. Você também pode querer lembrar pelo menos o conceito de uma máquina de estados, caso tenha que 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 muito mais rica de ideias do que a teoria da computação.

Por exemplo, na faculdade me ensinaram que é preciso descobrir um programa completamente no papel antes mesmo de chegar perto de um computador. Descobri que eu não programava dessa forma. Descobri que gostava de programar sentado na frente de um computador, não de 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 apenas vomitar um código que estava irremediavelmente quebrado e gradualmente batia nele para dar forma. Depuração, me ensinaram, era uma espécie de passagem final onde você pegava erros de digitação e descuidos. Do jeito que eu trabalhava, parecia que 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 meu lápis do jeito que 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ço. Até onde eu sei, o jeito que me ensinaram a programar na faculdade estava todo errado. Você deve descobrir 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 do jeito 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, borrar e manchar, não uma linguagem onde você tem que sentar com uma xícara de chá de tipos equilibrada no seu joelho e ter uma conversa educada com uma velha tia rigorosa 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. Todos nas ciências acreditam 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 fazer seu trabalho parecer 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 problemático se torna.

Uma página de fórmulas 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 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 sem relação. Assim como os hackers, eu acho.

Se universidades e laboratórios de pesquisa impedem que hackers façam o tipo de trabalho que eles querem fazer, talvez o lugar para eles seja nas empresas. Infelizmente, a maioria das empresas também não deixa os hackers fazerem o que eles querem. Universidades e laboratórios de pesquisa forçam os hackers a serem cientistas, e as empresas os forçam a serem engenheiros.

Eu só descobri isso recentemente. Quando o Yahoo comprou a Viaweb, eles me perguntaram o que eu queria fazer. Eu nunca gostei muito do lado empresarial 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.

Este parece ser o plano padrão em grandes empresas. Elas 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 administram uma empresa escolherem esses. Então, em vez de confiar o futuro do software a um hacker brilhante, a maioria das empresas configura as coisas para que sejam projetadas 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. 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 e baixos. Isso não é um problema para grandes empresas, porque elas não vencem fazendo ótimos produtos. Grandes empresas vencem sugando menos 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 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 muito 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 ainda conseguiu estabelecer qualquer fortificação. É aí que você pode ganhar muito adotando uma abordagem ousada para o design e tendo as mesmas pessoas projetando e implementando o produto. A própria Microsoft fez isso no começo. Assim como a Apple. E a Hewlett-Packard. Suspeito que quase toda startup de sucesso fez.

Então, uma maneira de construir um ótimo software é começar sua própria startup. Há dois problemas com isso, no entanto. Um é que em uma startup você tem que 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 do tempo variavam de tediosas a assustadoras. Tenho um parâmetro para isso, porque uma vez tive que sair de uma reunião do conselho para obturar algumas cáries. Lembro-me de sentar na cadeira do dentista, esperando a broca, e me sentir como se estivesse de férias.

O outro problema com startups é que não há muita 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 um, de fato, mas ninguém vai pagar por linguagens de programação agora. Se você quer ganhar dinheiro, você tende a ser forçado a trabalhar em problemas que são muito desagradáveis para qualquer um resolver de graça.

Todos os fabricantes enfrentam esse problema. Os preços são determinados pela oferta e demanda, e não há tanta demanda por coisas divertidas de se trabalhar quanto por coisas que resolvem os problemas mundanos de clientes individuais. Atuar em peças off-Broadway 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 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 de software, é um conceito conhecido por quase todos os criadores: o trabalho diurno. Essa frase começou com músicos, que se apresentam à noite. De forma mais geral, significa que você tem um tipo de trabalho que faz por dinheiro e outro por amor.

Quase todos os fabricantes têm empregos diurnos no início de suas carreiras. Pintores e escritores notoriamente têm. Se você tiver sorte, poderá conseguir um emprego diurno que esteja intimamente relacionado ao seu trabalho real. Músicos frequentemente parecem trabalhar em lojas de discos. Um hacker trabalhando em alguma linguagem de programação ou sistema operacional pode igualmente conseguir um emprego diurno usando-o. [1]

Quando digo que a resposta é que os hackers tenham empregos diários e trabalhem em softwares bonitos paralelamente, não estou propondo isso como uma ideia nova. É disso 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 fabricantes.

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 qualquer um que não o fizesse. Quando entrevistávamos programadores, a principal coisa com que nos importávamos era que tipo de software eles escreviam em seu tempo livre. Você não consegue fazer nada realmente bem a menos que ame isso, e se você ama hackear, inevitavelmente estará trabalhando em seus próprios projetos. [2]

Como os hackers são criadores e não 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 hacking?

Uma coisa que podemos aprender, ou pelo menos confirmar, do 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 seus próprios programas aos treze anos. Mesmo nas aulas da faculdade, 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, verá que cada pintura se baseia em coisas que foram aprendidas em anteriores. Quando há algo em uma pintura que funciona muito bem, você geralmente pode encontrar a versão 1 dela em uma forma menor em alguma pintura anterior.

Acho que a maioria dos criadores trabalha dessa forma. Escritores e arquitetos também parecem. Talvez fosse bom para os hackers agirem mais como pintores e regularmente começarem 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 é outro sinal de quão diferente o hacking é das ciências. Cientistas não aprendem ciência fazendo, mas fazendo laboratórios e conjuntos de problemas. Cientistas começam fazendo um trabalho perfeito, no sentido de que estão apenas tentando reproduzir o trabalho que outra pessoa já fez para eles. Eventualmente, eles chegam ao ponto em que podem fazer um trabalho original. Enquanto hackers, desde o início, estão fazendo um 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 pela qual os criadores aprendem é por meio 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 atentamente para a maneira como uma pintura é feita.

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

Hackers, da mesma forma, podem aprender a programar observando bons programas — não apenas 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 tornou mais fácil 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 de código aberto. A maioria das pessoas que lêem o código-fonte o lêem em fotocópias ilícitas do livro de John Lions, que, embora escrito em 1977, não teve permissão para 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 acabam sendo equivocados. Inúmeras pinturas, quando você as olha em raios-x, acabam tendo membros que foram movidos ou características faciais que foram reajustadas.

Aqui está um caso em que podemos aprender com a pintura. Acho que hacking também deveria funcionar dessa forma. Não é realista esperar que as especificações de um programa sejam perfeitas. É melhor admitir isso logo de cara e escrever programas de uma forma que permita que as especificações mudem rapidamente.

(A estrutura das grandes empresas dificulta que isso aconteça, então aqui está outro ponto em que as startups têm uma vantagem.)

Todo mundo agora provavelmente sabe sobre o perigo da otimização prematura. Acho que deveríamos estar igualmente preocupados 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 a mudança de ideia. A tipagem dinâmica é uma vitória aqui porque você não precisa se comprometer com representações de dados específicas logo de cara. Mas a chave para a flexibilidade, eu acho, é tornar a linguagem bem abstrata . O programa mais fácil de mudar é aquele que é bem 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 pintou cuidadosamente cada folha individual. Muitos pintores podem ter pensado, isso é apenas algo para colocar no fundo para emoldurar a cabeça dela. Ninguém vai olhar tão de perto para isso.

Não Leonardo. O quão duro ele trabalhava em parte de uma pintura não dependia nem um pouco 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, detalhes invisíveis se tornam visíveis. Quando as pessoas passam pelo retrato de Ginevra de Benci, sua atenção é frequentemente imediatamente capturada por ele, mesmo antes de olharem para o rótulo e perceberem que diz Leonardo da Vinci. Todos esses detalhes invisíveis se combinam para produzir algo que é simplesmente deslumbrante, como mil vozes quase inaudíveis, todas cantando em sintonia.

Um ótimo software, da mesma forma, requer uma devoção fanática à beleza. Se você olhar dentro de um bom software, verá que partes que ninguém deveria ver também são bonitas. Não estou dizendo que escrevo um ótimo software, mas sei que, quando se trata de código, me comporto de uma forma que me tornaria elegível para medicamentos prescritos se eu abordasse a vida cotidiana da mesma forma. Fico louco ao ver código mal recuado 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 seu caminho através dela de uma ponta a outra como alguém cavando uma vala. Mas se o hacker é um criador, temos que levar a inspiração em conta.

No hacking, assim 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 pela forma como você reage a eles. Quando você está dirigindo um carro com transmissão manual em uma colina, você tem que desacelerar a embreagem às vezes para evitar a parada. A desaceleração também pode evitar que a ambição pare. Tanto na pintura quanto no hacking, há algumas tarefas que são assustadoramente ambiciosas, e outras que são confortavelmente rotineiras. É uma boa ideia guardar algumas tarefas fáceis para momentos em que você, de outra forma, pararia.

Em hacking, isso pode literalmente significar salvar bugs. Eu gosto de debugar: é a única vez que hackear é tão direto quanto as pessoas pensam. 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 ganhar 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 foi 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 ele mesmo todas as figuras no teto da Capela Sistina.

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 os assistentes pintassem as outras e o fundo. Mas você nunca teve um cara pintando sobre o trabalho do outro.

Eu acho que esse é o modelo certo para colaboração em software também. Não vá longe demais. Quando um pedaço de código está sendo hackeado por três ou quatro pessoas diferentes, nenhuma das quais realmente é dona dele, ele acabará sendo como uma sala comum. Ele tenderá a parecer sombrio e abandonado, e acumulará lixo. A maneira certa de colaborar, eu acho, é dividir projetos em módulos nitidamente definidos, cada um com um dono definido, e com interfaces entre eles que são tão cuidadosamente projetadas e, se possível, tão articuladas quanto linguagens de programação.

Assim como a pintura, a maioria dos softwares é destinada a um público humano. E então hackers, assim como pintores, devem ter empatia para fazer um trabalho realmente bom. 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 significou na prática foi fazer o que outra pessoa queria, em vez do que eu queria. Isso, é claro, deu à empatia uma má fama, e eu fiz questão 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 abnegado. Longe disso. Entender como outra pessoa vê as coisas não implica que você agirá no interesse dela; 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.

Empatia é provavelmente a diferença mais importante entre um bom hacker e um ótimo. Alguns hackers são bem espertos, mas quando se trata de empatia são praticamente solipsistas. É difícil para essas pessoas projetarem 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 explicando uma questão técnica para alguém sem formação técnica. Provavelmente todos nós conhecemos pessoas que, embora inteligentes, são comicamente ruins nisso. Se alguém perguntar a elas em um jantar o que é uma linguagem de programação, elas dirão algo como ``Ah, 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 também não sabe o que essas coisas são.

Parte do que o software tem que fazer é se explicar. Então, para escrever um bom software, você tem que entender o quão pouco os usuários entendem. Eles vão chegar até o software sem nenhuma preparação, e é melhor que ele faça o que eles acham que fará, porque eles não vão ler o manual. O melhor sistema que já vi a esse respeito 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 aquela no começo de Structure and Interpretation of Computer Programs.

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

Você precisa ter empatia não apenas pelos seus usuários, mas pelos 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 tinham ideia de como ele funcionava. Conheço várias pessoas que juraram não usar mais Perl depois de tais experiências. [7]

A falta de empatia está associada à inteligência, a ponto de até mesmo haver uma moda para isso em alguns lugares. Mas não acho que haja nenhuma correlação. Você pode se sair bem em matemática e ciências naturais sem ter que aprender empatia, e as pessoas nessas áreas tendem a ser inteligentes, então as duas qualidades passaram a ser associadas. Mas há muitas pessoas idiotas que também são ruins em empatia. Basta ouvir as pessoas que ligam com perguntas em talk shows. Elas perguntam o que quer que estejam perguntando de uma forma 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 assim? Afinal, você só tem uma vida. Você pode muito bem gastá-la trabalhando em algo ótimo.

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

Então, embora eu admita que hackear não parece tão legal quanto pintar hoje em dia, 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 cedo. As pinturas feitas entre 1430 e 1500 ainda são insuperáveis. Shakespeare apareceu exatamente quando o teatro profissional estava nascendo,

e levou o meio tão longe 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 ficam tão animadas com ele 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. O quão legal o hacking vai se tornar vai depender do que podemos fazer com esse novo meio.

Notas

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

[2] Disseram-me que a Microsoft desencoraja os funcionários de contribuírem para projetos de código aberto, mesmo em seu tempo livre. Mas muitos 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: o mau gosto que você tinha no ensino médio.

[4] Aqui está um exemplo de empatia aplicada. Na Viaweb, se não pudéssemos decidir entre duas alternativas, perguntávamos: 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 e 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 o implementássemos nós mesmos, então hackeamos nossa própria versão naquela tarde.

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

[6] Bem, quase. Eles ultrapassaram um pouco a RAM disponível, causando muita inconveniência na troca de discos, mas isso poderia ser corrigido em poucos meses comprando uma unidade de 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 sobre a qual precise alertar os leitores, assim como em uma estrada há apenas setas em partes com curvas inesperadamente fechadas.

Agradeço a Trevor Blackwell, Robert Morris, Dan Giffin e Lisa Randall pela leitura dos rascunhos, e a Henry Leitner e Larry Finkelstein pelo convite para falar.