HACKERS E PINTORES

Maio de 2003

(Este 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 ficaram surpresas que alguém interessado em computadores também estivesse interessado em pintura. Eles pareciam pensar que hackear e pintar eram tipos muito diferentes de trabalho - 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 tipos diferentes de pessoas que 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 em si, 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". O principal motivo pelo qual não gosto é que não existe tal coisa. Ciência da computação é um amontoado de áreas tenuamente 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 estão fazendo de ciência da computação para que possam obter 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 por meio de redes, por exemplo. E então, na outra extremidade, você tem os hackers, que estão tentando escrever softwares interessantes, 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 em o mesmo departamento.

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

O quê 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 se descubra que a melhor maneira de fazer isso é implementá-la.

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

Agrupar todos esses tipos diferentes 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". É discutível que as pessoas no meio estão fazendo algo como uma ciência experimental. Mas as pessoas em cada extremidade, 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 alegremente começam a trabalhar provando teoremas como os outros matemáticos no departamento de matemática, e provavelmente logo param de notar que o prédio onde trabalham diz "ciência da computação" no exterior. 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 devem estar agindo cientificamente. Então, em vez de fazer o que realmente querem fazer, que é projetar softwares bonitos, hackers em universidades e laboratórios de pesquisa sentem que devem estar escrevendo artigos de pesquisa.

No melhor dos casos, os artigos são apenas uma formalidade. Hackers escrevem softwares legais, e depois escrevem um artigo sobre isso, e o artigo se torna um proxy para a conquista representada pelo software. Mas muitas vezes essa incompatibilidade causa problemas. É fácil se afastar de construir coisas bonitas para construir coisas feias que se tornam assuntos mais adequados para artigos de pesquisa.

Infelizmente, coisas bonitas nem sempre fazem o melhores assuntos para artigos. Em primeiro lugar, a pesquisa deve ser original - e como qualquer pessoa que já escreveu uma dissertação de doutorado sabe, a maneira de ter certeza de que você está explorando território virgem é estacar um pedaço de terra que ninguém quer. Em segundo lugar, a pesquisa deve ser substancial - e sistemas desajeitados geram artigos mais substanciosos, porque você pode escrever sobre os obstáculos que precisa superar para fazer as coisas acontecerem. Nada gera problemas substanciosos como começar com as premissas 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 o que explicar".

A maneira de criar algo bonito é muitas vezes 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 "aptidão escolar" é medida por testes padronizados simples, 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.

Medir o que os hackers realmente estão tentando fazer, projetar softwares bonitos, seria muito mais difícil. Você precisa de um bom senso de design para julgar bom design. E não há correlação, exceto possivelmente uma negativa uma, entre a capacidade das pessoas de reconhecer o bem 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 a vida humana. 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 para 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. Nesse sentido, 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 as pessoas entenderem mal seu trabalho. Um perigo pior é que você mesmo entenderá mal seu trabalho. 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 hackear é a versão aplicada do que a ciência da computação teórica é a teoria de. Tudo o tempo que passei na pós-graduação, eu tinha uma sensação desconfortável no fundo da minha mente de que eu deveria saber mais teoria, e que era muito negligente da minha parte ter esquecido tudo isso coisas dentro de três semanas do exame final.

Agora eu percebo que eu estava enganado. Hackers precisam entender a teoria da computação quase tanto quanto os pintores precisam entender a química da tinta. Você precisa saber como calcular o tempo e complexidade espacial e sobre completude de Turing. Você também pode querer lembrar pelo menos o conceito de uma máquina de estado, caso precise escrever um analisador ou uma biblioteca de expressões regulares. Pintores, na verdade, têm que lembrar 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 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 pacientemente escrever um programa completo e me certificar de que estava correto, eu tendia a apenas vomitar código que estava irremediavelmente quebrado, e gradualmente o batia em forma. Depuração, fui ensinado, era um tipo de passagem final onde você pegava erros de digitação e descuidos. Do jeito que 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 meu lápis do jeito 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çar. Pelo que sei, o jeito que me ensinaram a programar na faculdade estava totalmente errado. Você deve descobrir programas enquanto os está escrevendo, assim como escritores, pintores e arquitetos fazem.

Perceber isso tem implicações reais para o design de software. Significa que uma linguagem de programação deve, acima de tudo, ser maleável. Uma linguagem de programação é para pensar de programas, não para expressar programas que você já pensou em. Deve ser um lápis, não uma caneta. A digitação 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 escrevem programas. Precisamos de uma linguagem que nos permita rabiscar, manchar e borrar, não uma linguagem onde você tem que se sentar com uma xícara de chá de tipos equilibrada no seu joelho e fazer uma conversa educada com uma tia rigorosa de um compilador.

Enquanto estamos falando de digitação 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 secretamente acreditam 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 seus trabalho parece o mais matemático possível. Em um campo como física, isso provavelmente não causa muito mal, mas quanto mais você se afasta das ciências naturais, mais um problema se torna .

Uma página de fórmulas parece tão impressionante. (Dica: para uma impressividade extra, 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 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 que estão fazendo algo completamente diferente. Então, são os hackers, eu acho.

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

Só 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.

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 realmente consegue projetar software, e é difícil para o as pessoas que administram uma empresa escolhem essas. Então, em vez de confiar o futuro do software para um hacker brilhante, a maioria das empresas configura as coisas para que seja projetado por um comitê, e os hackers simplesmente implementam o design.

Se você quiser ganhar dinheiro em algum momento, lembre-se disso, porque esta é uma das razões pelas quais as startups vencem. As grandes empresas querem diminuir o desvio padrão dos resultados do design porque elas querem evitar desastres. Mas quando você amortece as oscilações, você perde os pontos altos e os baixos. Isso não é um problema para grandes empresas, porque elas não vencem fazendo grandes produtos. As grandes empresas vencem sugando menos 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 serão capazes de 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 mão para combate corpo a corpo. Seria bem fácil escrever um melhor editor de texto do que o Microsoft Word, por exemplo, mas o Microsoft, dentro do castelo de seu monopólio de sistema operacional, provavelmente nem notaria se você fizesse.

O lugar para travar guerras de design é em novos mercados, onde ninguém ainda conseguiu estabelecer nenhuma fortificação. É aí que você pode ganhar muito adotando a abordagem ousada ao design e tendo as mesmas pessoas projetando e implementando o produto. A própria Microsoft fez isso no início. A Apple também. E Hewlett-Packard. Suspeito que quase todas as startups de sucesso tenham.

Então, uma maneira de construir um ótimo software é iniciar sua própria startup. No entanto, existem dois problemas com isso. Um é que em uma startup você tem que fazer muito além de escrever software. Na Viaweb, eu me considerava sortudo se eu 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 aterrorizantes. Tenho um ponto de referência para isso, porque eu uma vez tive que sair de uma reunião do conselho para ter algumas cáries preenchidas. Lembro-me de sentar de volta na cadeira do dentista, esperando pela broca, e sentindo como se estivesse de férias.

O outro problema com as startups é que não há muita sobreposição entre o tipo de software que gera dinheiro e o tipo que é interessante de escrever. As linguagens de programação são interessantes de escrever, e o primeiro produto da Microsoft foi um, na verdade, mas ninguém vai 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 que alguém resolva 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 usar um traje de gorila na cabine de alguém em um feira comercial. Escrever romances não paga tão bem quanto escrever cópia de anúncio para trituradores de lixo. E hackear linguagens de programação não paga tão bem quanto descobrir como conectar o legado de alguma empresa banco de dados 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 diário. Essa frase começou com os músicos, que se apresentam à noite. De forma mais geral, significa que você tem um tipo de trabalho que você faz por dinheiro, e outro por amor.

Quase todos os criadores têm empregos diários no início de suas carreiras. Pintores e escritores notoriamente fazem. Se você tiver sorte você pode conseguir um emprego diário que seja intimamente relacionado ao seu trabalho real. Músicos costumam parecer trabalhar em lojas de discos. Um hacker trabalhando em algum linguagem de programação ou sistema operacional pode da mesma forma ser capaz de conseguir um emprego diário usando-o. [1]

Quando digo que a resposta é que os hackers tenham empregos diários, e trabalhem em softwares bonitos no lado, não estou propondo isso como uma nova ideia. É disso que o hacking de código aberto é tudo sobre. O que estou dizendo é que o código aberto é provavelmente o certo modelo, porque foi confirmado independentemente por todos os outros criadores.

Parece surpreendente para mim que qualquer empregador seja relutante em deixar os hackers trabalharem em projetos de código aberto. Na Viaweb, teríamos sido relutantes em contratar qualquer pessoa que não fizesse. Quando entrevistamos programadores, o 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 você ame, e se você ama hackear, você inevitavelmente estará trabalhando em projetos próprios. [2]

Como os hackers são criadores em vez de cientistas, o lugar certo para procurar metáforas não está no 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, do exemplo da pintura é como aprender a hackear. Você aprende a pintar principalmente fazendo isso. O mesmo acontece com o hacking. A maioria dos hackers não aprende a hackear por fazer 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 hackear. [3]

Como os pintores deixam um rastro de trabalho atrás deles, você pode observá-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 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 parecem fazer também. Talvez seja bom para os 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 os hackers aprenderem a hackear fazendo isso é outro sinal de como o hacking é diferente das ciências. Cientistas não aprendem ciência fazendo isso, mas fazendo laboratórios e conjuntos de problemas. Os cientistas começam fazendo um trabalho que é perfeito, no sentido de que eles estão apenas tentando reproduzir um trabalho que outra pessoa 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; é simplesmente muito ruim. Então os hackers começam originais e ficam bons, e os cientistas começam bem e ficam originais.

A outra maneira que 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 tradição educação de pintores para copiar as obras dos grandes mestres, porque copiar força você a olhar de perto 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 depois tentando reproduzi-los. Raymond Chandler fez a mesma coisa com histórias de detetives.

Hackers, da mesma forma, podem aprender a programar olhando para bons programas - não apenas no que eles fazem, mas no 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 então era o Unix, mas mesmo este não era código aberto. A maioria das pessoas que lia o código-fonte lia em fotocópias ilícitas do livro de John Lions, que embora escrito em 1977, não foi autorizado a 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. Incontáveis ​​pinturas, quando você olha para elas em raios-x, acabam tendo membros que foram movidos ou traços faciais que foram reajustados.

Aqui está um caso em que podemos aprender com a pintura. Acho que o hacking também deve funcionar dessa forma. É irreal esperar que as especificações de um programa sejam perfeitas. Você está melhor se admitir isso de antemão e escrever programas em uma forma que permite 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 as startups têm uma vantagem.)

Presumivelmente, todos já sabem sobre o perigo da otimização prematura. Acho que devemos estar tão 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 a tinta a óleo, tornar fácil mudar de ideia. A digitação dinâmica é uma vitória aqui porque você não precisa se comprometer com representações de dados específicas de antemão. Mas a chave para a flexibilidade, eu acho, é tornar a linguagem muito abstrata. O programa mais fácil de mudar é aquele que é muito curto.

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

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

A implacável vence porque, no agregado, detalhes invisíveis tornam-se visíveis. Quando as pessoas passam pelo retrato de Ginevra de Benci, sua atenção é muitas vezes imediatamente atraída por ele, antes mesmo 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 impressionante, como mil vozes quase inaudíveis todas cantando em uníssono.

Grandes softwares, da mesma forma, exigem uma devoção fanática à beleza. Se você olhar para dentro de um bom software, descobrirá que partes que ninguém nunca deve ver também são bonitas. Não estou afirmando que escrevo um ótimo software, mas eu sei que quando se trata de código, eu me comporto de uma forma que me faria qualificado para medicamentos prescritos se eu abordasse o dia a dia vida da mesma forma. 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 nisso de uma ponta a outra como alguém cavando uma vala. Mas se o hacker é um criador, temos que levar a inspiração em consideração.

No hacking, como na pintura, o trabalho vem em ciclos. Às vezes você fica animado 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 consideração, porque eles são afetados por como você reage a eles. Quando você está dirigindo um carro com câmbio manual em uma colina, você tem que soltar a embreagem às vezes para evitar que ele pare. Soltar a embreagem também pode impedir que a ambição pare. Tanto na pintura quanto no hacking, existem alguns tarefas que são terrivelmente 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.

No hacking, isso pode literalmente significar guardar bugs. Eu gosto de depurar: é o única vez que o hacking é tão direto quanto as pessoas pensam que é. Você tem um problema totalmente restrito, e tudo o que você tem que fazer é resolver ele. Seu programa deve fazer x. Em vez disso, ele faz y. Onde está o erro? 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. Muitas das grandes obras de arte do passado são obra de múltiplas 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 todas as figuras no teto da Capela Sistina ele mesmo.

Pelo que sei, quando os 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 por cima do trabalho de outro.

Acho que este é o modelo certo para colaboração em software também. Não force muito. Quando um pedaço de código é está sendo hackeado por três ou quatro pessoas diferentes, nenhuma das quais realmente possui, acabará sendo como uma sala comum. Vai tender a se sentir sombrio e abandonado, e acumular sujeira. O certo maneira de colaborar, eu acho, é dividir projetos em módulos bem definidos, cada um com um proprietário definido, e com interfaces entre eles que são tão cuidadosamente projetados e, se possível, tão articulados quanto as linguagens de programação.

Como a pintura, a maioria dos softwares é destinada a um público humano. E assim, os hackers, como os pintores, devem ter empatia para fazer um trabalho realmente ótimo. 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 um mau nome, 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 abnegado. Longe disso. Entender como outra pessoa vê as coisas não implica que você agirá em seu interesse; em alguns 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 ótimo. Alguns hackers são bastante inteligentes, mas quando se trata de empatia são praticamente solipsistas. É difícil para tais pessoas projetarem softwares excelentes [5], porque elas não podem ver as coisas do ponto de vista do usuário.

Uma maneira de saber o quão boas as pessoas são em empatia é observar eles explicarem uma questão técnica para alguém sem um técnico fundo. Provavelmente todos nós conhecemos pessoas que, embora inteligentes, são simplesmente comicamente ruins nisso. Se alguém perguntar a eles em um jantar o que é uma linguagem de programação, eles dirão algo como "Ah, 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 não sabe o que essas coisas são também.

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 entender. Eles vão se aproximar do software sem preparação, e ele deve fazer o que eles adivinham que fará, porque eles são não vai ler o manual. O melhor sistema que já vi nesse sentido 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 lembrar apenas uma citação sobre programação, seria a que está no início de Estrutura e Interpretação de Computadores Programas.

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 com seus leitores. É em seu interesse, porque você será um deles. Muitos hackers escreveram um programa apenas para descobrir ao voltar a ele seis meses depois que ele não tem ideia como funciona. Conheço várias pessoas que juraram nunca mais usar Perl depois de tais experiências. [7]

A falta de empatia está associada à inteligência, a ponto de que até existe uma certa moda para isso em alguns lugares. Mas não acho que haja nenhuma 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 se tornaram associadas. Mas existem muitas pessoas burras que são ruins em empatia também. Basta ouvir as pessoas que ligam com perguntas sobre programas de entrevistas. Eles perguntam o que quer que estejam perguntando em uma forma tão indireta que os anfitriões muitas vezes têm que reformular a pergunta para eles.

Então, se o hacking funciona como pintura e escrita, é tão legal? Afinal, você só tem uma vida. Você pode muito bem passar trabalhando em algo ótimo.

Infelizmente, a pergunta é difícil de responder. Sempre há um grande atraso no 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 essas pinturas tão importantes quanto nós hoje. Teria parecido muito estranho para as pessoas da época que Federico da Montefeltro, o Duque de Urbino, um dia seria conhecido principalmente como o cara com o nariz estranho em uma pintura por 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 como 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 insuperáveis. 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 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 entusiasmadas com ele que exploram a maioria de suas possibilidades nas primeiras duas gerações. O hacking parece estar nessa fase agora.

A pintura não era, no tempo de Leonardo, tão legal quanto seu trabalho ajudou a torná-la. O quão legal o hacking se torna 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 diário. A maioria dos grandes pintores da história se sustentou pintando retratos.

[2] Fui informado de que a Microsoft desestimula funcionários de contribuir para projetos de código aberto, mesmo em seu tempo livre. Mas tantos dos melhores hackers trabalham em código aberto projetos agora que o principal efeito dessa política pode ser para garantir que eles não serão capazes de contratar nenhum primeiro programadores.

[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, nós 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 tínhamos, 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 o implementássemos nós mesmos, então montamos 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 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 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 que você precise avisar os leitores, assim como em uma estrada existem apenas setas em partes com curvas inesperadamente acentuadas.

Obrigado a Trevor Blackwell, Robert Morris, Dan Giffin e Lisa Randall por ler rascunhos disso, e a Henry Leitner e Larry Fink