GRANDES HACKERS

Julho de 2004

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

Alguns meses atrás terminei um novo livro , e nas resenhas continuo notando palavras como "provocativo" e "polêmico". Sem falar em "idiota".

Não quis tornar o livro controverso. Estava tentando torná-lo eficiente. Não queria desperdiçar o tempo das pessoas contando coisas que elas já sabiam. É mais eficiente apenas dar a elas as diferenças. Mas suponho que isso certamente renderá um livro alarmante.

Edison

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

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

Variação na riqueza pode ser um sinal de variação na produtividade. (Em uma sociedade de um, eles são idênticos.) E isso é quase certamente uma coisa boa: se sua sociedade não tem variação na produtividade, provavelmente não é porque todo mundo é 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, quanto mais produtivo o melhor coletor de gravetos será 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 ela é 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 dado problema em um décimo do tempo. Mas e se o problema não for dado? Na programação, 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 em espécie. Não acho que isso seja algo intrínseco à programação, no entanto. Em todos os campos, a tecnologia amplia as diferenças na produtividade. Acho que o que está acontecendo na programação é que temos muita alavancagem tecnológica. Mas em todos os campos a alavanca está ficando maior, 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 eles 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 na verdade crescerá com o tempo. Quando você alcança o ponto em que 90% da produção de um grupo é criada por 1% de seus membros, você perde muito se algo (sejam ataques vikings ou planejamento central) arrastar sua produtividade para a média.

Se quisermos tirar o máximo proveito deles, precisamos entender essas pessoas especialmente produtivas. O que as motiva? O que elas precisam para fazer seus trabalhos? Como você as reconhece? Como você as faz vir e trabalhar para você? E então, é claro, há a pergunta: como você se torna um?

Mais 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 encantados em descobrir que as pessoas vão pagar por eles.

Às vezes, diz-se 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, você pode trabalhar no que quiser, e por essa razão os hackers são atraídos pela ideia de ganhar muito dinheiro. Mas enquanto eles ainda tiverem 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, esse é um fato da maior importância, porque significa que você não precisa pagar a grandes hackers nada parecido com o que eles valem. Um grande programador pode ser dez ou cem vezes mais produtivo que um programador comum, mas ele se considerará sortudo se receber três vezes mais. Como explicarei mais tarde, isso ocorre em parte porque grandes hackers não sabem o quão bons são. Mas também porque 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 recusarão a trabalhar em projetos com a infraestrutura errada.

Em uma startup para a qual trabalhei, uma das coisas pregadas em nosso quadro de avisos era um anúncio da IBM. Era uma foto 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 esta 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, você 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 aqueles que você poderia contratar para trabalhar em um projeto escrito em Python. E a qualidade dos seus hackers provavelmente importa mais do que a linguagem que você escolher. Embora, francamente, o fato de bons hackers preferirem 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 veem as linguagens 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ê tem que mover bits por uma rede, 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 Java acabou de ultrapassar Cobol como a linguagem mais popular. Como padrão, você não poderia desejar mais. Mas como 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 no controle. Isso é parte do que os torna bons hackers: quando algo está quebrado, eles precisam consertar. Você quer que eles sintam isso sobre o software que estão escrevendo para você. Você não deve se surpreender quando eles sentem o mesmo sobre o sistema operacional.

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

A Fronteira Final

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

A história em quadrinhos Dilbert tem muito a dizer sobre cubículos, e com razão. Todos os hackers que conheço os desprezam. A mera perspectiva de ser interrompido é suficiente para impedir que hackers trabalhem em problemas difíceis. Se você quer fazer um trabalho de verdade em um escritório com cubículos, você tem duas opções: trabalhar em casa, ou chegar 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 o ajude a trabalhar, não algo que você trabalha apesar disso.

Empresas como a Cisco se orgulham de que todos lá tenham um cubículo, até mesmo o CEO. Mas elas não são tão avançadas quanto pensam; obviamente, elas ainda veem o espaço do escritório como um distintivo de classificação. Observe também que a Cisco é famosa por fazer muito pouco desenvolvimento de produtos internamente. Elas obtêm novas tecnologias comprando as startups que as 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 para nós, a premissa era, e nós lhe daremos um lugar para trabalhar onde você pode realmente 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 bem o suficiente.

Se as empresas querem que os hackers sejam produtivos, elas devem olhar para o que eles fazem em casa. Em casa, os hackers podem organizar as coisas eles mesmos para que possam fazer o máximo. 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 e vizinhos com pessoas ao redor e um lugar para caminhar quando precisam refletir sobre algo, em vez de em caixas de vidro colocadas em hectares de estacionamentos. Eles têm um sofá onde podem tirar uma soneca quando se sentem cansados, em vez de ficarem sentados em coma em suas mesas, fingindo trabalhar. Não há uma equipe de pessoas com aspiradores de pó que rugem todas as noites durante os principais horários de hacking. Não há reuniões ou, Deus nos livre, retiros corporativos ou exercícios de formação de equipe. E quando você olha para o que eles estão fazendo naquele computador, você verá que isso reforça o que eu disse antes sobre ferramentas. Eles podem ter que usar Java e Windows no trabalho, mas em casa, onde eles 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 serem as linguagens mais populares podem ser enganosas. O que devemos observar, se quisermos saber quais ferramentas são melhores, é o que os hackers escolhem quando podem escolher livremente-- isto é, em projetos próprios. Quando você faz essa pergunta, descobre que os sistemas operacionais de código aberto já têm uma fatia dominante do mercado, 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 aplicativos abertamente sensuais como aviões furtivos ou software de efeitos especiais seriam interessantes para trabalhar. Mas qualquer aplicativo pode ser interessante se apresentar novos desafios técnicos. Então é difícil prever quais problemas os hackers vão gostar, porque alguns se tornam interessantes somente quando as pessoas que trabalham neles descobrem um novo tipo de solução. Antes do ITA (que escreveu o software dentro do Orbitz), as pessoas que trabalhavam em pesquisas de tarifas aéreas provavelmente achavam que era um dos aplicativos mais chatos imagináveis. Mas o ITA o tornou interessante ao redefinir o problema de uma forma 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 chata e sem importância. Mas os caras do Google não achavam que a busca era chata, e é por isso que eles a fazem tão bem.

Esta é uma área em que 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 levou os desenvolvedores mais longe do que qualquer cenoura ou vara poderia.

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

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

O problema não é tanto a gestão do dia a dia. Hackers realmente bons são praticamente autogerenciados. 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 pode tornar seus produtos bonitos apenas contratando um ótimo designer para projetá-los. Mas se você mesmo não tem bom gosto , como vai reconhecer um bom designer? Por definição, você não pode dizer pelo seu portfólio. E você não pode ir pelos prêmios que ele ganhou ou pelos empregos que teve, porque no design, como na maioria dos campos, eles tendem a ser movidos pela moda e bajulação, com a habilidade real em um distante terceiro lugar. Não há como contornar isso: você não pode gerenciar um processo destinado a produzir coisas bonitas sem saber o que é bonito. Os carros americanos são feios porque as montadoras americanas são administradas por pessoas de mau gosto.

Muitas pessoas neste país pensam em gosto como algo ilusório, ou mesmo frívolo. Não é nem uma coisa nem outra. Para impulsionar o design, um gerente deve ser o usuário mais exigente dos produtos de uma empresa. E se você tem realmente bom gosto, você pode, como Steve Jobs faz, fazer com que a satisfação seja o tipo de problema que as pessoas boas gostam de resolver.

Pequenos problemas desagradáveis

É bem fácil dizer que tipos de problemas não são interessantes: aqueles em que, em vez de resolver alguns problemas grandes e claros, você tem que resolver muitos pequenos desagradáveis. Um dos piores tipos de projetos é escrever uma interface para um pedaço de 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 hackers, esses tipos de projetos são a morte de mil cortes.

A característica distintiva dos probleminhas desagradáveis é 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] Então não é só a meticulosidade que faz bons hackers evitarem probleminhas desagradáveis. É mais uma questão de autopreservação. Trabalhar em probleminhas desagradáveis faz você ficar estúpido. Bons hackers evitam isso pela mesma razão que modelos evitam cheeseburgers.

Claro que alguns problemas têm inerentemente esse caráter. E por causa da oferta e demanda, eles pagam especialmente bem. Então, uma empresa que encontrasse uma maneira de fazer com que grandes hackers trabalhassem em problemas tediosos seria muito bem-sucedida. Como você faria isso?

Um lugar onde isso acontece é em startups. Na nossa startup, tínhamos Robert Morris trabalhando como administrador de sistemas. É 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 penoso para empresas das quais são fundadoras. [4]

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

Talvez você não precise ir a esse extremo. A programação bottom-up sugere outra maneira de dividir a empresa: ter pessoas inteligentes trabalhando como fabricantes de ferramentas. Se sua empresa faz software para fazer x, tenha um grupo que crie ferramentas para escrever software desse tipo e outro que use essas ferramentas para escrever os aplicativos. 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 os aplicativos reais não estariam fazendo coisas de baixo nível como alocar memória. Em vez de escrever Word diretamente em C, eles estariam conectando grandes blocos de Lego da linguagem Word. (Duplo, eu acredito, é o termo técnico.)

Aglomeração

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

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

Eu acho, porém, que todas as outras coisas sendo iguais, uma empresa que pode atrair grandes hackers terá uma grande vantagem. Há pessoas que discordariam disso. Quando estávamos fazendo as rondas de empresas de capital de risco na década de 1990, várias nos disseram que as empresas de software não ganhavam escrevendo grandes softwares, mas por meio de marcas, dominando canais e fazendo os negócios certos.

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

É um erro usar a Microsoft como modelo, porque toda a cultura deles deriva daquele golpe de sorte. A Microsoft é um ponto de dados ruim. Se você os joga fora, descobre que bons produtos tendem a vencer no mercado. O que os VCs devem procurar é a próxima Apple ou o próximo Google.

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

Reconhecimento

Então, quem são os grandes hackers? Como você sabe quando conhece um? Isso acaba sendo muito difícil. Nem mesmo os hackers conseguem dizer. Agora tenho quase certeza de que meu amigo Trevor Blackwell é um grande hacker. Você pode ter lido no Slashdot como ele fez seu próprio Segway . O mais notável sobre esse projeto foi que ele escreveu todo o software em um dia (em Python, aliás).

Para Trevor, isso é normal. Mas quando o conheci, pensei que ele era um completo idiota. Ele estava no escritório de Robert Morris balbuciando com ele sobre uma coisa ou outra, e eu me lembro de ficar atrás dele fazendo gestos frenéticos para Robert expulsar esse maluco do escritório para que pudéssemos ir almoçar. Robert diz que julgou Trevor mal no começo também. Aparentemente, quando Robert o conheceu, Trevor tinha acabado de começar um novo esquema que envolvia escrever tudo sobre cada aspecto de sua vida em uma pilha de fichas, que ele carregava consigo 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 hackers, apesar de sua reputação de alheios sociais, às vezes se esforçam bastante para parecer inteligentes. Quando eu estava na pós-graduação, eu costumava ficar no MIT AI Lab ocasionalmente. Era meio intimidador no começo. Todo mundo lá falava muito rápido. Mas depois de um tempo eu aprendi o truque de falar rápido. Você não precisa pensar mais rápido; basta usar o dobro de palavras para dizer tudo.

Com essa quantidade de ruído no sinal, é difícil dizer se são bons hackers quando você os conhece. Não consigo dizer, mesmo agora. Também não dá para dizer pelos currículos deles. Parece que a única maneira de julgar um hacker é trabalhar com ele em alguma coisa.

E esta é a razão pela qual as áreas de alta tecnologia só acontecem em torno das universidades. O ingrediente ativo aqui não são tanto os professores, mas sim os alunos. As startups crescem em torno das 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.

Como você não pode dizer que é um grande hacker a não ser trabalhando com ele, os próprios hackers não conseguem dizer o quão bons eles são. Isso é verdade até certo ponto na maioria dos campos. Descobri que as pessoas que são ótimas em alguma coisa não estão tão convencidas de sua própria grandeza, mas sim mistificadas com o motivo pelo qual todos os outros parecem tão incompetentes.

Mas é particularmente difícil para hackers saberem o quão bons eles são, porque é difícil comparar o trabalho deles. 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 hackear é como escrever. Quem pode dizer qual dos dois romances é melhor? Certamente não os autores.

Com hackers, pelo menos, outros hackers podem dizer. Isso porque, diferentemente de romancistas, hackers colaboram em projetos. Quando você consegue resolver alguns problemas difíceis pela rede com alguém, você aprende bem rápido o quão duro eles revidam. Mas hackers não conseguem se ver trabalhando. Então, se você perguntar a um grande hacker o quão bom ele é, ele quase certamente responderá, eu 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 devem ser. Os hackers que se tornam famosos tendem a se tornar famosos por acidentes aleatórios de RP. 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 ridículo usá-los. Então, acho que 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 existe um Michael Jordan do hacking, ninguém sabe, nem ele mesmo.

Cultivo

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

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. Então, na medida em que você consegue preservar o hacking como algo que você ama, você provavelmente o fará bem. Tente manter o senso de admiração 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 é exclusiva dos hackers? Perguntei a alguns amigos, e a primeira coisa que eles mencionaram foi curiosidade. Eu sempre supus que todas as pessoas inteligentes eram 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 os programas são, na verdade, descrições gigantescas de como as coisas funcionam.

Vários amigos mencionaram a capacidade dos hackers de se concentrarem — sua capacidade, como um deles disse, de "desligar tudo que está fora de suas próprias cabeças". Eu certamente notei isso. E ouvi vários hackers dizerem que depois de beberem até meia cerveja eles não conseguem programar nada. Então talvez hackear exija alguma habilidade especial para focar. Talvez grandes hackers consigam carregar uma grande quantidade de contexto em suas cabeças, de modo que quando eles olham para uma linha de código, eles não veem apenas aquela linha, mas todo o programa ao redor dela. 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 conseguia 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 encarregadas das instalações, não tendo nenhuma concentração para quebrar, 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 de autismo forem verdadeiros, 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 levariam a 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. Os 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 chance de uma receita. Se for possível se tornar um grande hacker, a maneira de fazer isso pode ser fazer o seguinte acordo consigo mesmo: você nunca terá que trabalhar em projetos chatos (a menos que sua família passe fome de outra forma) e, em troca, você nunca se permitirá fazer um trabalho pela metade. Todos os grandes hackers que conheço parecem ter feito esse acordo, embora talvez nenhum deles tivesse escolha no assunto.

Notas

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

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

[3] Acho que é isso que as pessoas querem dizer quando falam sobre o "sentido da vida". À primeira vista, isso parece uma ideia estranha. A vida não é uma expressão; como ela poderia ter significado? Mas ela pode ter uma qualidade que parece muito com significado. Em um projeto como um compilador, você tem que resolver muitos problemas, mas todos os problemas 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 trabalhou em um ponto projetando geladeiras. (Ele tinha capital.)

[5] É difícil dizer exatamente o que constitui pesquisa no mundo da computação, mas, como uma primeira aproximação, é um 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 vem acontecendo há muito tempo na indústria da construção. Quando você tinha uma casa construída 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, como a chegada da editoração eletrônica, deu às pessoas a liberdade de experimentar de maneiras desastrosas, mas é certamente mais eficiente.

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

Obrigado a Jessica Livingston, Robert Morris e Sarah Harlin pela leitura de versões anteriores desta palestra.