GRANDES HACKERS

Julho de 2004

(Esse ensaio é derivado de uma palestra na Oscon 2004.)

Há alguns meses, terminei um novo livro, e nas resenhas continuo notando palavras como "provocativo" e "controverso". Sem falar em "idiota".

Não tinha a intenção de tornar o livro controverso. Eu estava tentando torná-lo eficiente. Não queria desperdiçar o tempo das pessoas contando-lhes coisas que já sabiam. É mais eficiente apenas dar-lhes as diferenças. Mas suponho que isso acaba resultando em um livro alarmante.

Edisons

Não há controvérsia sobre qual ideia é a mais controversa: a sugestão de que a variação na riqueza pode não ser um problema tão grande quanto pensamos.

Não disse no livro que a variação na riqueza era em si uma coisa boa. Disse que em algumas situações pode ser um sinal de coisas boas. Uma dor de cabeça pulsante não é uma coisa boa, mas pode ser um sinal de algo bom - por exemplo, que você está recuperando a consciência após ser atingido na cabeça.

A variação na riqueza pode ser um sinal de variação na produtividade. (Em uma sociedade de um, elas são idênticas.) E isso é quase certamente uma coisa boa: se sua sociedade não tem variação na produtividade, provavelmente não é porque todos são Thomas Edison. Provavelmente é porque você não tem Thomas Edisons.

Em uma sociedade de baixa tecnologia, você não vê muita variação na produtividade. Se você tem uma tribo de nômades coletando gravetos para uma fogueira, quão mais produtivo será o melhor coletor de gravetos do que o pior? Um fator de dois? Enquanto que, quando você entrega às pessoas uma ferramenta complexa como um computador, a variação no que elas podem fazer com ele é enorme.

Essa não é uma ideia nova. Fred Brooks escreveu sobre isso em 1974, e o estudo que ele citou foi publicado em 1968. Mas acho que ele subestimou a variação entre programadores. Ele escreveu sobre produtividade em linhas de código: os melhores programadores podem resolver um determinado problema em um décimo do tempo. Mas e se o problema não for dado? Na programação, assim como em muitos campos, a parte difícil não é resolver problemas, mas decidir quais problemas resolver. A imaginação é difícil de medir, mas na prática ela domina o tipo de produtividade que é medida em linhas de código.

A produtividade varia em qualquer campo, mas há poucos em que ela varia tanto. A variação entre programadores é tão grande que se torna uma diferença de tipo. Não acho que isso seja algo intrínseco à programação, no entanto. Em todos os campos, a tecnologia amplifica as diferenças na produtividade. Acho que o que está acontecendo na programação é apenas que temos muito alavancagem tecnológica. Mas em todos os campos a alavanca está se tornando mais longa, então a variação que vemos é algo que mais e mais campos verão com o passar do tempo. E o sucesso das empresas, e dos países, dependerá cada vez mais de como lidam com isso.

Se a variação na produtividade aumenta com a tecnologia, então a contribuição dos indivíduos mais produtivos não será apenas desproporcionalmente grande, mas realmente crescerá com o tempo. Quando você chega ao ponto em que 90% da produção de um grupo é criada por 1% de seus membros, você perde muito se algo (seja invasões vikings, ou planejamento central) arrastar sua produtividade para a média.

Se quisermos obter o máximo deles, precisamos entender essas pessoas especialmente produtivas. O que as motiva? O que elas precisam para fazer seu trabalho? Como você as reconhece? Como você as faz vir e trabalhar para você? E então, claro, há a pergunta, como você se torna uma?

Mais do que Dinheiro

Conheço um punhado de super-hackers, então sentei e pensei sobre o que eles têm em comum. A qualidade que os define é provavelmente que eles realmente amam programar. Programadores comuns escrevem código para pagar as contas. Grandes hackers pensam nisso como algo que fazem por diversão, e que ficam felizes em descobrir que as pessoas estão dispostas a pagar-lhes por isso.

Dizem que grandes programadores são indiferentes ao dinheiro. Isso não é bem verdade. É verdade que tudo o que eles realmente se importam é em fazer um trabalho interessante. Mas se você ganha dinheiro suficiente, pode trabalhar no que quiser, e por essa razão os hackers são atraídos pela ideia de ganhar quantias realmente grandes de dinheiro. Mas enquanto ainda tiver que aparecer para trabalhar todos os dias, eles se importam mais com o que fazem lá do que com quanto são pagos por isso.

Economicamente, isso é um fato de grande importância, porque significa que você não precisa pagar grandes hackers nada parecido com o que eles valem. Um grande programador pode ser dez ou cem vezes mais produtivo do que um comum, mas ele se considerará sortudo por receber três vezes mais. Como explicarei mais tarde, isso é em parte porque grandes hackers não sabem quão bons são. Mas também é porque o dinheiro não é a principal coisa que eles querem.

O que os hackers querem? Como todos os artesãos, os hackers gostam de boas ferramentas. Na verdade, isso é um eufemismo. Bons hackers acham insuportável usar ferramentas ruins. Eles simplesmente se recusam a trabalhar em projetos com a infraestrutura errada.

Em uma startup para a qual trabalhei uma vez, uma das coisas fixadas em nosso quadro de avisos era um anúncio da IBM. Era uma imagem de um AS400, e a manchete dizia, eu acho, "hackers desprezam isso." [1]

Quando você decide qual infraestrutura usar para um projeto, você não está apenas tomando uma decisão técnica. Você também está tomando uma decisão social, e essa pode ser a mais importante das duas. Por exemplo, se sua empresa quer escrever algum software, pode parecer uma escolha prudente escrevê-lo em Java. Mas quando você escolhe uma linguagem, também está escolhendo uma comunidade. Os programadores que você poderá contratar para trabalhar em um projeto Java não serão tão inteligentes quanto os que você poderia conseguir para trabalhar em um projeto escrito em Python. E a qualidade dos seus hackers provavelmente importa mais do que a linguagem que você escolhe. Embora, francamente, o fato de que bons hackers preferem Python a Java deve lhe dizer algo sobre os méritos relativos dessas linguagens.

Os tipos de negócios preferem as linguagens mais populares porque as veem como padrões. Eles não querem apostar a empresa no Betamax. A questão sobre as linguagens, no entanto, é que elas não são apenas padrões. Se você precisa mover bits por uma rede, por todos os meios use TCP/IP. Mas uma linguagem de programação não é apenas um formato. Uma linguagem de programação é um meio de expressão.

Li que o Java acabou de ultrapassar o Cobol como a linguagem mais popular. Como padrão, você não poderia desejar mais. Mas como um meio de expressão, você poderia fazer muito melhor. De todos os grandes programadores que consigo pensar, conheço apenas um que programaria voluntariamente em Java. E de todos os grandes programadores que consigo pensar que não trabalham para a Sun, em Java, conheço zero.

Grandes hackers também geralmente insistem em usar software de código aberto. Não apenas porque é melhor, mas porque lhes dá mais controle. Bons hackers insistem em controle. Isso é parte do que os torna bons hackers: quando algo está quebrado, eles precisam consertá-lo. Você quer que eles se sintam assim em relação ao software que estão escrevendo para você. Você não deve se surpreender quando eles sentem o mesmo em relação ao sistema operacional.

Há alguns anos, um amigo capitalista de risco me contou sobre uma nova startup com a qual ele estava envolvido. Parecia promissora. Mas na próxima vez que conversei com ele, ele disse que haviam decidido construir seu software em Windows NT, e acabaram de contratar um desenvolvedor NT muito experiente para ser seu diretor técnico. Quando ouvi isso, pensei, esses caras estão condenados. Primeiro, o CTO não poderia ser um hacker de primeira linha, porque para se tornar um eminente desenvolvedor NT ele teria que usar o NT voluntariamente, várias vezes, e não consigo imaginar um grande hacker fazendo isso; e segundo, mesmo que ele fosse bom, teria dificuldade em contratar alguém bom para trabalhar para ele se o projeto tivesse que ser construído em NT. [2]

A Fronteira Final

Após o software, a ferramenta mais importante para um hacker é provavelmente seu escritório. Grandes empresas pensam que a função do espaço de escritório é expressar hierarquia. Mas os hackers usam seus escritórios para mais do que isso: eles usam seu escritório como um lugar para pensar. E se você é uma empresa de tecnologia, os pensamentos deles são seu produto. Portanto, fazer os hackers trabalharem em um ambiente barulhento e distraído é como ter uma fábrica de tintas onde o ar está cheio de fuligem.

A tira de quadrinhos Dilbert tem muito a dizer sobre cubículos, e com boa razão. Todos os hackers que conheço os desprezam. A mera perspectiva de ser interrompido é suficiente para impedir os hackers de trabalharem em problemas difíceis. Se você quer que um trabalho real seja feito em um escritório com cubículos, você tem duas opções: trabalhar em casa, ou entrar cedo ou tarde ou em um fim de semana, quando não há mais ninguém lá. As empresas não percebem que isso é um sinal de que algo está quebrado? Um ambiente de escritório deve ser algo que ajuda você a trabalhar, não algo que você trabalha apesar de.

Empresas como a Cisco se orgulham de que todos lá têm um cubículo, até mesmo o CEO. Mas eles não são tão avançados quanto pensam; obviamente ainda veem o espaço de escritório como um distintivo de hierarquia. Note também que a Cisco é famosa por fazer muito pouco desenvolvimento de produtos internamente. Eles obtêm nova tecnologia comprando as startups que a criaram - onde presumivelmente os hackers tinham um lugar tranquilo para trabalhar.

Uma grande empresa que entende o que os hackers precisam é a Microsoft. Uma vez vi um anúncio de recrutamento da Microsoft com uma grande imagem de uma porta. Trabalhe conosco, a premissa era, e nós lhe daremos um lugar para trabalhar onde você realmente pode fazer o trabalho. E você sabe, a Microsoft é notável entre as grandes empresas por ser capaz de desenvolver software internamente. Não bem, talvez, mas o suficiente.

Se as empresas querem que os hackers sejam produtivos, devem observar o que fazem em casa. Em casa, os hackers podem organizar as coisas por conta própria para que possam fazer o máximo possível. E quando trabalham em casa, os hackers não trabalham em espaços abertos e barulhentos; eles trabalham em salas com portas. Eles trabalham em lugares aconchegantes, com vizinhos ao redor e algum lugar para caminhar quando precisam refletir sobre algo, em vez de em caixas de vidro situadas em acres de estacionamentos. Eles têm um sofá onde podem tirar um cochilo quando se sentem cansados, em vez de sentar em coma em sua mesa, fingindo trabalhar. Não há uma equipe de pessoas com aspiradores de pó que passa todas as noites durante as horas de pico de hacking. Não há reuniões ou, Deus me livre, retiros corporativos ou exercícios de formação de equipe. E quando você olha para o que estão fazendo naquele computador, você descobrirá que isso reforça o que disse anteriormente sobre ferramentas. Eles podem ter que usar Java e Windows no trabalho, mas em casa, onde podem escolher por si mesmos, é mais provável que você os encontre usando Perl e Linux.

De fato, essas estatísticas sobre Cobol ou Java sendo a linguagem mais popular podem ser enganosas. O que devemos observar, se quisermos saber quais ferramentas são as melhores, é o que os hackers escolhem quando podem escolher livremente - ou seja, em projetos próprios. Quando você faz essa pergunta, descobre que sistemas operacionais de código aberto já têm uma participação de mercado dominante, e a linguagem número um é provavelmente Perl.

Interessante

Junto com boas ferramentas, os hackers querem projetos interessantes. O que torna um projeto interessante? Bem, obviamente aplicações overtamente sexy como aviões stealth ou software de efeitos especiais seriam interessantes para trabalhar. Mas qualquer aplicação pode ser interessante se apresentar desafios técnicos novos. Portanto, é difícil prever quais problemas os hackers gostarão, porque alguns se tornam interessantes apenas quando as pessoas que trabalham neles descobrem um novo tipo de solução. Antes da ITA (que escreveu o software dentro da Orbitz), as pessoas que trabalhavam em buscas de tarifas aéreas provavelmente achavam que era uma das aplicações mais entediantes imagináveis. Mas a ITA tornou isso interessante ao redefinir o problema de uma maneira mais ambiciosa.

Acho que a mesma coisa aconteceu no Google. Quando o Google foi fundado, a sabedoria convencional entre os chamados portais era que a busca era entediante e sem importância. Mas os caras do Google não achavam a busca entediante, e é por isso que eles a fazem tão bem.

Esta é uma área onde os gerentes podem fazer a diferença. Como um pai dizendo a uma criança, aposto que você não consegue limpar seu quarto inteiro em dez minutos, um bom gerente pode às vezes redefinir um problema como um mais interessante. Steve Jobs parece ser particularmente bom nisso, em parte simplesmente por ter altos padrões. Havia muitos computadores pequenos e baratos antes do Mac. Ele redefiniu o problema como: faça um que seja bonito. E isso provavelmente fez os desenvolvedores se esforçarem mais do que qualquer cenoura ou bastão poderia.

Eles certamente entregaram. Quando o Mac apareceu pela primeira vez, você não precisava nem ligá-lo para saber que seria bom; você podia dizer pela caixa. Algumas semanas atrás, eu estava andando pela rua em Cambridge, e no lixo de alguém vi o que parecia ser uma capa de Mac. Olhei dentro, e havia um Mac SE. Levei-o para casa e o liguei, e ele inicializou. O rosto feliz do Macintosh, e então o Finder. Meu Deus, era tão simples. Era como ... Google.

Os hackers gostam de trabalhar para pessoas com altos padrões. Mas não é suficiente apenas ser exigente. Você tem que insistir nas coisas certas. O que geralmente significa que você tem que ser um hacker você mesmo. Eu vi artigos ocasionais sobre como gerenciar programadores. Na verdade, deveria haver dois artigos: um sobre o que fazer se você mesmo é um programador, e um sobre o que fazer se você não é. E o segundo poderia provavelmente ser condensado em duas palavras: desista.

O problema não é tanto a gestão do dia a dia. Hackers realmente bons são praticamente autogerenciáveis. O problema é que, se você não é um hacker, não consegue dizer quem são os bons hackers. Um problema semelhante explica por que os carros americanos são tão feios. Eu chamo isso de paradoxo do design. Você pode pensar que poderia tornar seus produtos bonitos apenas contratando um grande designer para projetá-los. Mas se você mesmo não tem bom gosto, como você vai reconhecer um bom designer? Por definição, você não pode dizer pelo portfólio dele. E você não pode se basear nos prêmios que ele ganhou ou nos empregos que teve, porque no design, assim como na maioria dos campos, esses tendem a ser impulsionados por moda e relacionamentos, com a habilidade real em um distante terceiro. Não há como escapar: você não pode gerenciar um processo destinado a produzir coisas bonitas sem saber o que é bonito. Carros americanos são feios porque as empresas automobilísticas americanas são dirigidas por pessoas com mau gosto.

Muitas pessoas neste país pensam no gosto como algo elusivo, ou mesmo frívolo. Não é nada disso. Para conduzir o design, um gerente deve ser o usuário mais exigente dos produtos de uma empresa. E se você tiver realmente bom gosto, pode, como Steve Jobs faz, fazer com que satisfazê-lo seja o tipo de problema que pessoas boas gostam de trabalhar.

Problemas Incômodos

É bem fácil dizer que tipos de problemas não são interessantes: aqueles em que, em vez de resolver alguns grandes e claros problemas, você tem que resolver muitos pequenos e incômodos. Um dos piores tipos de projetos é escrever uma interface para um software que está cheio de bugs. Outro é quando você tem que personalizar algo para as necessidades complexas e mal definidas de um cliente individual. Para os hackers, esses tipos de projetos são a morte de mil cortes.

A característica distintiva dos problemas incômodos é que você não aprende nada com eles. Escrever um compilador é interessante porque ensina o que é um compilador. Mas escrever uma interface para um software cheio de bugs não ensina nada, porque os bugs são aleatórios. [3] Portanto, não é apenas a meticulosidade que faz bons hackers evitarem problemas incômodos. É mais uma questão de autopreservação. Trabalhar em problemas incômodos torna você estúpido. Bons hackers evitam isso pela mesma razão que modelos evitam hambúrgueres.

Claro que alguns problemas têm esse caráter inerentemente. E devido à oferta e à demanda, eles pagam especialmente bem. Portanto, uma empresa que encontrasse uma maneira de fazer grandes hackers trabalharem em problemas tediosos seria muito bem-sucedida. Como você faria isso?

Um lugar onde isso acontece é em startups. Em nossa startup, tivemos Robert Morris trabalhando como administrador de sistemas. Isso é como ter os Rolling Stones tocando em um bar mitzvah. Você não pode contratar esse tipo de talento. Mas as pessoas farão qualquer quantidade de trabalho árduo para empresas das quais são os fundadores. [4]

Empresas maiores resolvem o problema dividindo a empresa. Elas conseguem que pessoas inteligentes trabalhem para elas estabelecendo um departamento de P&D separado onde os funcionários não precisam trabalhar diretamente nos problemas incômodos dos clientes. [5] Nesse modelo, o departamento de pesquisa funciona como uma mina. Eles produzem novas ideias; talvez o resto da empresa consiga usá-las.

Você pode não precisar ir a esse extremo. Programação de baixo para cima sugere outra maneira de dividir a empresa: fazer as pessoas inteligentes trabalharem como fabricantes de ferramentas. Se sua empresa faz software para fazer x, tenha um grupo que construa ferramentas para escrever software desse tipo, e outro que use essas ferramentas para escrever as aplicações. Dessa forma, você pode conseguir que pessoas inteligentes escrevam 99% do seu código, mas ainda mantê-las quase tão isoladas dos usuários quanto estariam em um departamento de pesquisa tradicional. Os fabricantes de ferramentas teriam usuários, mas seriam apenas os próprios desenvolvedores da empresa. [6]

Se a Microsoft usasse essa abordagem, seu software não estaria tão cheio de buracos de segurança, porque as pessoas menos inteligentes escrevendo as aplicações reais não estariam fazendo coisas de baixo nível como alocar memória. Em vez de escrever o Word diretamente em C, estariam conectando grandes blocos de Lego da linguagem Word. (Duplo, acredito, é o termo técnico.)

Agrupamento

Junto com problemas interessantes, o que bons hackers gostam é de outros bons hackers. Grandes hackers tendem a se agrupar - às vezes espetacularmente, como no Xerox Parc. Portanto, você não atrairá bons hackers em proporção linear ao quão bom um ambiente você cria para eles. A tendência de se agrupar significa que é mais como o quadrado do ambiente. Portanto, é o vencedor leva tudo. Em qualquer momento, há apenas cerca de dez ou vinte lugares onde os hackers mais querem trabalhar, e se você não é um deles, você não terá apenas menos grandes hackers, terá zero.

Ter grandes hackers não é, por si só, suficiente para fazer uma empresa bem-sucedida. Funciona bem para o Google e a ITA, que são dois dos pontos quentes no momento, mas não ajudou a Thinking Machines ou a Xerox. A Sun teve um bom desempenho por um tempo, mas seu modelo de negócios é um elevador descendo. Nessa situação, mesmo os melhores hackers não podem salvá-lo.

Acho, no entanto, que todas as outras coisas sendo iguais, uma empresa que pode atrair grandes hackers terá uma enorme vantagem. Há pessoas que discordariam disso. Quando estávamos fazendo as rodadas de empresas de capital de risco na década de 1990, várias nos disseram que as empresas de software não ganhavam escrevendo um ótimo software, mas através de marca, dominando canais e fazendo os negócios certos.

Eles realmente pareciam acreditar nisso, e acho que sei por quê. Acho que o que muitos VCs estão procurando, pelo menos inconscientemente, é o próximo Microsoft. E, claro, se a Microsoft é seu modelo, você não deve estar procurando empresas que esperam vencer escrevendo um ótimo software. Mas os VCs estão enganados ao procurar o próximo Microsoft, porque nenhuma startup pode ser a próxima Microsoft a menos que alguma outra empresa esteja disposta a se curvar no momento certo e ser a próxima IBM.

É um erro usar a Microsoft como modelo, porque toda a sua cultura deriva daquela única sorte. A Microsoft é um mau ponto de dados. Se você os descartar, descobrirá que bons produtos tendem a vencer no mercado. O que os VCs deveriam estar procurando é o próximo Apple, ou o próximo Google.

Acho que Bill Gates sabe disso. O que o preocupa sobre o Google não é o poder de sua marca, mas o fato de que eles têm hackers melhores. [7]

Reconhecimento

Então, quem são os grandes hackers? Como você sabe quando encontra um? Isso acaba sendo muito difícil. Mesmo os hackers não conseguem dizer. Estou quase certo agora de que meu amigo Trevor Blackwell é um grande hacker. Você pode ter lido no Slashdot como ele fez seu próprio Segway. A coisa notável sobre esse projeto foi que ele escreveu todo o software em um dia (em Python, por sinal).

Para Trevor, isso é normal. Mas quando o conheci pela primeira vez, pensei que ele era um completo idiota. Ele estava em pé no escritório de Robert Morris tagarelando com ele sobre algo ou outro, e me lembro de estar atrás dele fazendo gestos frenéticos para Robert para espantar esse maluco de seu escritório para que pudéssemos almoçar. Robert diz que também subestimou Trevor no início. Aparentemente, quando Robert o conheceu pela primeira vez, Trevor tinha acabado de começar um novo esquema que envolvia escrever tudo sobre cada aspecto de sua vida em um monte de cartões de índice, que ele carregava com ele para todo lugar. Ele também tinha acabado de chegar do Canadá, e tinha um forte sotaque canadense e um mullet.

O problema é agravado pelo fato de que os hackers, apesar de sua reputação de desatenção social, às vezes se esforçam bastante para parecerem inteligentes. Quando eu estava na pós-graduação, costumava frequentar o MIT AI Lab ocasionalmente. Era meio intimidante no começo. Todos lá falavam tão rápido. Mas depois de um tempo, aprendi o truque de falar rápido. Você não precisa pensar mais rápido; apenas use o dobro de palavras para dizer tudo.

Com essa quantidade de ruído no sinal, é difícil identificar bons hackers quando você os encontra. Eu não consigo dizer, mesmo agora. Você também não pode dizer pelos currículos deles. Parece que a única maneira de julgar um hacker é trabalhar com ele em algo.

E essa é a razão pela qual áreas de alta tecnologia só acontecem em torno de universidades. O ingrediente ativo aqui não são tanto os professores, mas os alunos. Startups crescem em torno de universidades porque as universidades reúnem jovens promissores e os fazem trabalhar nos mesmos projetos. Os inteligentes aprendem quem são os outros inteligentes, e juntos eles criam novos projetos próprios.

Porque você não pode identificar um grande hacker exceto trabalhando com ele, os hackers em si não conseguem dizer quão bons são. Isso é verdade em um grau na maioria dos campos. Descobri que pessoas que são ótimas em algo não estão tão convencidas de sua própria grandeza quanto estão perplexas sobre por que todos os outros parecem tão incompetentes.

Mas é particularmente difícil para os hackers saberem quão bons são, porque é difícil comparar seu trabalho. Isso é mais fácil na maioria dos outros campos. Nos cem metros, você sabe em 10 segundos quem é o mais rápido. Mesmo em matemática parece haver um consenso geral sobre quais problemas são difíceis de resolver, e o que constitui uma boa solução. Mas hacking é como escrever. Quem pode dizer qual de dois romances é melhor? Certamente não os autores.

Com os hackers, pelo menos, outros hackers podem dizer. Isso porque, diferentemente dos romancistas, os hackers colaboram em projetos. Quando você consegue acertar alguns problemas difíceis na rede com alguém, você aprende bem rápido quão forte eles os acertam de volta. Mas os hackers não podem se observar trabalhando. Então, se você perguntar a um grande hacker quão bom ele é, ele quase certamente responderá, não sei. Ele não está apenas sendo modesto. Ele realmente não sabe.

E nenhum de nós sabe, exceto sobre pessoas com quem realmente trabalhamos. O que nos coloca em uma situação estranha: não sabemos quem nossos heróis deveriam ser. Os hackers que se tornam famosos tendem a se tornar famosos por acidentes aleatórios de PR. Ocasionalmente, preciso dar um exemplo de um grande hacker, e nunca sei quem usar. Os primeiros nomes que vêm à mente sempre tendem a ser pessoas que conheço pessoalmente, mas parece sem graça usá-los. Então, eu penso, talvez eu devesse dizer Richard Stallman, ou Linus Torvalds, ou Alan Kay, ou alguém famoso assim. Mas não tenho ideia se esses caras são grandes hackers. Nunca trabalhei com eles em nada.

Se há um Michael Jordan do hacking, ninguém sabe, incluindo ele.

Cultivo

Finalmente, a pergunta que os hackers têm se perguntado: como você se torna um grande hacker? Não sei se é possível fazer de si mesmo um. Mas certamente é possível fazer coisas que o tornam estúpido, e se você pode se tornar estúpido, provavelmente pode também se tornar inteligente.

A chave para ser um bom hacker pode ser trabalhar no que você gosta. Quando penso nos grandes hackers que conheço, uma coisa que eles têm em comum é a extrema dificuldade de fazê-los trabalhar em qualquer coisa que não queiram. Não sei se isso é causa ou efeito; pode ser ambos.

Para fazer algo bem, você tem que amar isso. Portanto, na medida em que você pode preservar o hacking como algo que ama, é provável que você o faça bem. Tente manter o senso de maravilha que você tinha sobre programação aos 14 anos. Se você está preocupado que seu trabalho atual esteja apodrecendo seu cérebro, provavelmente está.

Os melhores hackers tendem a ser inteligentes, é claro, mas isso é verdade em muitos campos. Existe alguma qualidade que seja única para os hackers? Perguntei a alguns amigos, e a coisa número um que mencionaram foi curiosidade. Sempre presumi que todas as pessoas inteligentes fossem curiosas - que a curiosidade era simplesmente a primeira derivada do conhecimento. Mas aparentemente os hackers são particularmente curiosos, especialmente sobre como as coisas funcionam. Isso faz sentido, porque programas são, de fato, gigantescas descrições de como as coisas funcionam.

Vários amigos mencionaram a capacidade dos hackers de se concentrar - sua capacidade, como um colocou, de "desligar tudo fora de suas próprias cabeças." Eu certamente notei isso. E ouvi vários hackers dizerem que, após beber até mesmo meio copo de cerveja, não conseguem programar de jeito nenhum. Portanto, talvez o hacking exija alguma habilidade especial de foco. Talvez grandes hackers consigam carregar uma grande quantidade de contexto em suas cabeças, de modo que, quando olham para uma linha de código, veem não apenas aquela linha, mas todo o programa ao seu redor. John McPhee escreveu que o sucesso de Bill Bradley como jogador de basquete se deveu em parte à sua extraordinária visão periférica. "Visão perfeita" significa cerca de 47 graus de visão periférica vertical. Bill Bradley tinha 70; ele podia ver a cesta quando estava olhando para o chão. Talvez grandes hackers tenham alguma habilidade inata semelhante. (Eu trapaceio usando uma linguagem muito densa, que encolhe a quadra.)

Isso poderia explicar a desconexão sobre cubículos. Talvez as pessoas responsáveis pelas instalações, não tendo nenhuma concentração a ser destruída, não tenham ideia de que trabalhar em um cubículo parece para um hacker como ter o cérebro em um liquidificador. (Enquanto Bill, se os rumores sobre autismo forem verdade, sabe muito bem.)

Uma diferença que notei entre grandes hackers e pessoas inteligentes em geral é que os hackers são mais politicamente incorretos. Na medida em que há um aperto de mão secreto entre bons hackers, é quando eles se conhecem bem o suficiente para expressar opiniões que os fariam ser apedrejados até a morte pelo público em geral. E posso ver por que a incorreção política seria uma qualidade útil na programação. Programas são muito complexos e, pelo menos nas mãos de bons programadores, muito fluidos. Em tais situações, é útil ter o hábito de questionar suposições.

Você pode cultivar essas qualidades? Não sei. Mas você pode pelo menos não reprimi-las. Então aqui está minha melhor tentativa de uma receita. Se é possível fazer de si mesmo um grande hacker, a maneira de fazer isso pode ser fazer o seguinte acordo consigo mesmo: você nunca tem que trabalhar em projetos entediantes (a menos que sua família morra de fome de outra forma), e em troca, você nunca permitirá que faça um trabalho mal feito. Todos os grandes hackers que conheço parecem ter feito esse acordo, embora talvez nenhum deles tenha tido escolha na questão.

Notas

[1] Para ser justo, tenho que dizer que a IBM faz hardware decente. Eu escrevi isso em um laptop da IBM.

[2] Eles realmente acabaram se mostrando condenados. Eles fecharam alguns meses depois.

[3] Acho que é isso que as pessoas querem dizer quando falam sobre o "significado da vida." À primeira vista, isso parece uma ideia estranha. A vida não é uma expressão; como poderia ter significado? Mas pode ter uma qualidade que se parece muito com significado. Em um projeto como um compilador, você tem que resolver muitos problemas, mas os problemas todos se encaixam em um padrão, como em um sinal. Enquanto que, quando os problemas que você tem que resolver são aleatórios, eles parecem ruído.

[4] Einstein em um momento trabalhou projetando refrigeradores. (Ele tinha participação.)

[5] É difícil dizer exatamente o que constitui pesquisa no mundo da computação, mas como uma primeira aproximação, é software que não tem usuários.

Não acho que seja a publicação que faz os melhores hackers quererem trabalhar em departamentos de pesquisa. Acho que é principalmente não ter que ter uma reunião de três horas com um gerente de produto sobre problemas de integração da versão coreana do Word 13.27 com o clipe de papel falante.

[6] Algo semelhante tem acontecido há muito tempo na indústria da construção. Quando você mandava construir uma casa há algumas centenas de anos, os construtores locais construíam tudo nela. Mas cada vez mais o que os construtores fazem é montar componentes projetados e fabricados por outra pessoa. Isso deu, como a chegada da publicação em desktop, liberdade às pessoas para experimentar de maneiras desastrosas, mas é certamente mais eficiente.

[7] O Google é muito mais perigoso para a Microsoft do que a Netscape foi. Provavelmente mais perigoso do que qualquer outra empresa já foi. Não menos porque estão determinados a lutar. Em sua página de listagem de empregos, eles dizem que um de seus "valores fundamentais" é "Não seja malvado." De uma empresa que vende óleo de soja ou equipamentos de mineração, tal declaração seria meramente excêntrica. Mas acho que todos nós no mundo da computação reconhecemos contra quem isso é uma declaração de guerra.

Agradecimentos a Jessica Livingston, Robert Morris e Sarah Harlin por lerem versões anteriores desta palestra.