GRANDES HACKERS

Julho de 2004

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

Alguns meses atrás, terminei um novo livro, e em resenhas, continuo notando palavras como "provocativo" e "controverso". Para não falar em "idiota".

Eu não pretendia tornar o livro controverso. Eu estava tentando torná-lo eficiente. Eu não queria desperdiçar o tempo das pessoas contando-lhes coisas que eles já sabiam. É mais eficiente apenas dar-lhes as diferenças. Mas suponho que isso vá render um livro alarmante.

Edisons

Não há controvérsia sobre qual ideia é mais controversa: a sugestão de que a variação na riqueza pode não ser tão grande problema 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 poderia 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á se recuperando da consciência depois de ter sido atingido na cabeça.

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 todos são Thomas Edison. Provavelmente é porque você não tem nenhum Thomas Edison.

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 será o melhor coletor de gravetos em comparação com o pior? Um fator de dois? Enquanto quando você entrega às pessoas uma ferramenta complexa como um computador, a variação no que eles 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 os 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 domina o tipo de produtividade 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 natureza. Eu não acho que isso seja algo intrínseco à programação, no entanto. Em todos os campos, a tecnologia amplia as diferenças de 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á ficando 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 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 só será 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 ataques vikings, ou planejamento central) reduzir sua produtividade à média.

Se quisermos tirar 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 trabalhar para você? E então, claro, há a questão: como você se torna uma delas?

Mais do que Dinheiro

Eu conheço alguns super-hackers, então me sentei e pensei sobre o que eles têm em comum. Sua qualidade definitiva é provavelmente que eles realmente amam programar. Programadores comuns escrevem código para pagar as contas. Grandes hackers pensam nisso como algo que eles fazem por diversão, e pelo qual ficam encantados em descobrir que as pessoas pagarão por isso.

Grandes programadores às vezes são considerados indiferentes ao dinheiro. Isso não é bem verdade. É verdade que tudo o que realmente lhes importa é fazer um trabalho interessante. Mas se você ganhar o 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 desde que ainda tenham que comparecer ao trabalho todos os dias, eles se importam mais com o que fazem lá do que com quanto são pagos por isso.

Economicamente, este é um fato da maior importância, pois significa que você não precisa pagar aos grandes hackers nem de longe o que eles valem. Um grande programador pode ser dez ou cem vezes mais produtivo que um comum, mas ele se considerará sortudo por receber três vezes mais. Como explicarei mais tarde, isso se deve em parte ao fato de que os grandes hackers não sabem o 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 recusarão a trabalhar em projetos com a infraestrutura errada.

Em uma startup para a qual trabalhei uma vez, uma das coisas afixadas em nosso quadro de avisos era um anúncio da IBM. Era uma imagem de um AS400 e o título dizia, acho, "hackers o desprezam". [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 quiser escrever um software, pode parecer uma escolha prudente escrevê-lo em Java. Mas ao escolher uma linguagem, você também está escolhendo uma comunidade. Os programadores que você poderá contratar para trabalhar em um projeto em 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 de seus hackers provavelmente é mais importante do que a linguagem que você escolher. Embora, francamente, o fato de que bons hackers preferem Python a Java deveria lhe dizer algo sobre os méritos relativos dessas linguagens.

Os empresários preferem as linguagens mais populares porque veem as linguagens como padrões. Eles não querem apostar a empresa no Betamax. A coisa sobre as linguagens, no entanto, é que elas não são apenas padrões. Se você precisa mover bits pela rede, use TCP/IP, sem dúvida. 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 acaba de ultrapassar o 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 conheço, sei de apenas um que programaria voluntariamente em Java. E de todos os grandes programadores que conheço que não trabalham para a Sun, no Java, sei de 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 faz 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 sentirem 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 promissor. Mas na próxima vez que falei com ele, ele disse que eles haviam decidido construir seu software no Windows NT e acabaram de contratar um desenvolvedor muito experiente do NT 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 desenvolvedor eminente do NT ele teria que usar o NT voluntariamente, várias vezes, e eu não conseguia 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 no NT. [2]

A Fronteira Final

Depois do software, a ferramenta mais importante para um hacker provavelmente é o seu escritório. As grandes empresas acham que a função do espaço de escritório é expressar o status. Mas os hackers usam seus escritórios para mais do que isso: eles os usam como um lugar para pensar. E se você é uma empresa de tecnologia, seus pensamentos são o seu produto. Então fazer os hackers trabalharem em um ambiente barulhento e distrativo é 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 que os hackers trabalhem em problemas difíceis. Se você quiser fazer um trabalho real em um escritório com cubículos, você tem duas opções: trabalhar em casa ou chegar cedo ou tarde ou em um final de semana, quando ninguém mais estiver lá. As empresas não percebem que isso é um sinal de que algo está errado? Um ambiente de escritório deve ser algo que ajude você a trabalhar, não algo com o qual você trabalhe apesar disso.

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

Uma grande empresa que entende o que os hackers precisam é a Microsoft. Certa vez, vi um anúncio de recrutamento da Microsoft com uma grande imagem de uma porta. Trabalhe para nós, dizia a premissa, e nós lhe daremos um lugar para trabalhar onde você realmente possa fazer o trabalho. E você sabe, a Microsoft é notável entre as grandes empresas por ser capaz de desenvolver software internamente. Talvez não muito bem, mas 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 de maneira 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 com vizinhos, com pessoas por perto e algum lugar para caminhar quando precisam refletir sobre algo, em vez de em caixas de vidro em meio a acres de estacionamentos. Eles têm um sofá no qual podem tirar uma soneca quando se sentirem cansados, em vez de ficarem sentados em um estado de coma em sua mesa, fingindo trabalhar. Não há equipe de pessoas com aspiradores de pó que rugem durante todas as noites, nas principais horas de programação. Não há reuniões ou, Deus o livre, retiros corporativos ou exercícios de integração de equipe. E quando você olhar para o que eles estão fazendo naquele computador, você descobrirá que reforça o que eu disse anteriormente sobre ferramentas. Eles podem ter que usar Java e Windows no trabalho, mas em casa, onde podem escolher por si mesmos, você provavelmente os encontrará usando Perl e Linux.

De fato, essas estatísticas sobre Cobol ou Java serem a linguagem mais popular podem ser enganosas. O que deveríamos 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, você descobre que os sistemas operacionais de código aberto já têm uma participação de mercado dominante, e a linguagem número um provavelmente é o Perl.

Interessante

Além de boas ferramentas, os hackers querem projetos interessantes. O que torna um projeto interessante? Bem, obviamente, aplicativos abertamente sexy, como aviões furtivos ou software de efeitos especiais, seriam interessantes de se 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 apenas quando as pessoas que trabalham neles descobrem um novo tipo de solução. Antes da ITA (que escreveu o software dentro do Orbitz), as pessoas que trabalhavam em buscas de tarifas aéreas provavelmente achavam que era uma das aplicações mais entediantes do mundo. Mas a ITA o tornou 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 pesquisa era entediante e sem importância. Mas os caras do Google não achavam a pesquisa 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 um filho: "Aposto que você não consegue arrumar todo o seu quarto em dez minutos", um bom gerente às vezes pode 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: fazer um que seja bonito. E isso provavelmente impulsionou os desenvolvedores mais do que qualquer cenoura ou chicote poderia.

Eles certamente entregaram. Quando o Mac apareceu pela primeira vez, você nem precisava ligá-lo para saber que seria bom; você podia dizer pelo design. Há algumas semanas, eu estava andando pela rua em Cambridge e vi o que parecia ser uma bolsa de transporte do Mac no lixo de alguém. Olhei dentro e havia um Mac SE. Levei-o para casa e o conectei, e ele iniciou. O rosto feliz do Macintosh e, em seguida, o Finder. Meu Deus, era tão simples. Era apenas como... o Google.

Os 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 você mesmo. Eu vi alguns artigos ocasionais sobre como gerenciar programadores. Na verdade, deveria haver dois artigos: um sobre o que fazer se você mesmo for um programador, e outro sobre o que fazer se você não for. E o segundo provavelmente poderia ser resumido em duas palavras: desista.

O problema não é tanto a gestão do dia a dia. Os hackers realmente bons são praticamente autogestionários. O problema é que, se você não for um hacker, não conseguirá identificar 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ê poderia pensar que você poderia tornar seus produtos bonitos simplesmente contratando um ótimo designer para projetá-los. Mas se você mesmo não tiver 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 ir pelos prêmios que ele ganhou ou pelos empregos que ele teve, porque no design, assim como na maioria dos campos, esses tendem a ser impulsionados pela moda e pelo networking, com a habilidade real em terceiro lugar. Não há como evitar: 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 empresas de carros americanas são administradas por pessoas com mau gosto.

Muitas pessoas neste país consideram o gosto algo elusivo ou até mesmo fútil. Não é nem um nem outro. Para impulsionar o design, um gerente deve ser o usuário mais exigente dos produtos de uma empresa. E se você tiver um gosto realmente bom, você pode, como Steve Jobs faz, fazer a satisfação sua o tipo de problema que as boas pessoas gostam de trabalhar.

Pequenos Problemas Desagradáveis

É bastante 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 e desagradáveis. Um dos piores tipos de projetos é escrever uma interface para um software cheio de bugs. Outro é quando você precisa personalizar algo para as necessidades complexas e mal definidas de um cliente individual. Para os hackers, esse tipo de projeto é a morte de mil cortes.

A característica distintiva dos pequenos problemas desagradáveis é que você não aprende nada com eles. Escrever um compilador é interessante porque te ensina o que é um compilador. Mas escrever uma interface para um software cheio de bugs não te ensina nada, porque os bugs são aleatórios. [3] Então não é apenas o perfeccionismo que faz os bons hackers evitarem pequenos problemas desagradáveis. É mais uma questão de autopreservação. Trabalhar em pequenos problemas desagradáveis te torna estúpido. Os bons hackers os evitam pela mesma razão que os modelos evitam cheeseburgers.

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

Uma das situações em que isso acontece é em startups. Em nossa startup, tínhamos Robert Morris trabalhando como administrador de sistemas. É como ter os Rolling Stones tocando em um bar mitzvá. 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. Eles conseguem atrair pessoas inteligentes para trabalhar para eles, 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 possa usá-las.

Você pode não precisar chegar a esse extremo. Programação bottom-up sugere outra maneira de dividir a empresa: fazer com que as pessoas inteligentes trabalhem como fabricantes de ferramentas. Se sua empresa produz software para fazer x, tenha um grupo que constrói ferramentas para escrever software desse tipo e outro que usa 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 teria tantos buracos de segurança, porque as pessoas menos inteligentes que escrevem os aplicativos reais não estariam fazendo coisas de baixo nível, como alocar memória. Em vez de escrever o Word diretamente em C, eles estariam montando grandes blocos de Lego do idioma do Word. (Duplo, acredito, é o termo técnico.)

Aglomeração

Junto com problemas interessantes, o que os bons hackers gostam é de outros bons hackers. Os grandes hackers tendem a se aglomerar - às vezes de forma espetacular, como na Xerox Parc. Portanto, você não atrairá bons hackers na proporção linear de quão bom é o ambiente que você cria para eles. A tendência de aglomeração significa que é mais como o quadrado do ambiente. Entã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 ótimos hackers não é, por si só, suficiente para fazer uma empresa ter sucesso. 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 uma boa corrida por um tempo, mas seu modelo de negócios é um elevador descendente. Nessa situação, mesmo os melhores hackers não podem salvá-lo.

Eu acho, no entanto, que todas as outras coisas sendo iguais, uma empresa que pode atrair ótimos hackers terá uma enorme vantagem. Existem 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 venciam escrevendo ótimo software, mas através de marca, dominar canais e fazer 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 por empresas que esperam vencer escrevendo ótimo software. Mas os VCs estão enganados em procurar o próximo Microsoft, porque nenhuma startup pode ser o próximo Microsoft, a menos que outra empresa esteja disposta a se curvar no momento certo e ser o próximo IBM.

É um erro usar a Microsoft como modelo, porque toda a sua cultura deriva daquele único golpe de sorte. A Microsoft é um mau ponto de dados. Se você os jogar fora, você 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 com o Google não é o poder de 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 encontra um? Isso se revela muito difícil. Mesmo os hackers não conseguem dizer. Tenho certeza 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, aliás).

Para Trevor, isso é normal. Mas quando o conheci pela primeira vez, achei que ele era um completo idiota. Ele estava no escritório de Robert Morris, tagarelando sobre alguma coisa, e me lembro de ficar atrás dele fazendo gestos frenéticos para Robert expulsar esse maluco de seu escritório para que pudéssemos ir almoçar. Robert diz que também julgou mal Trevor no início.

O problema é agravado pelo fato de que os hackers, apesar de sua reputação de insensibilidade social, às vezes se esforçam bastante para parecer inteligentes. Quando eu estava na pós-graduação, costumava ficar no Laboratório de IA do MIT de vez em quando. Era meio intimidante no início. Todos 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; basta usar o dobro de palavras para dizer tudo.

Com essa quantidade de ruído no sinal, é difícil reconhecer os bons hackers quando os encontramos. Eu não consigo, nem 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 de as áreas de alta tecnologia só acontecerem em torno de universidades. O ingrediente ativo aqui não são tanto os professores, mas os alunos. As startups crescem em torno de universidades porque elas reúnem jovens promissores e os fazem trabalhar em projetos comuns. Os mais inteligentes aprendem quem são os outros mais inteligentes, e juntos eles elaboram novos projetos próprios.

Porque você não pode reconhecer um grande hacker, a não ser trabalhando com ele, os próprios hackers não sabem o quão bons são. Isso é verdade em certo grau na maioria dos campos. Descobri que as pessoas que são ótimas em algo não estão tão convencidas de sua própria grandeza quanto perplexas com o fato de todos os outros parecerem tão incompetentes.

Mas é particularmente difícil para os hackers saberem o quão bons são, porque é difícil comparar o trabalho deles. Isso é mais fácil na maioria dos outros campos. Nos 100 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 os hackers, pelo menos, outros hackers podem dizer. Isso porque, diferentemente dos romancistas, os hackers colaboram em projetos. Quando você consegue atingir alguns problemas difíceis pela rede com alguém, você aprende muito rapidamente o quão bem eles os resolvem de volta. Mas os hackers não podem se observar trabalhando. Então, se você perguntar a um grande hacker o 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 as pessoas com as quais realmente trabalhamos. O que nos coloca em uma situação estranha: não sabemos quem deveriam ser nossos heróis. Os hackers que se tornam famosos tendem a se tornar famosos por acidentes aleatórios de relações públicas. Ocasionalmente, preciso dar um exemplo de um grande hacker, e nunca sei quem usar. Os primeiros nomes que me vêm à mente sempre tendem a ser pessoas que conheço pessoalmente, mas parece sem graça usá-las. Então, 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 existe um Michael Jordan do hacking, ninguém sabe, nem mesmo ele.

Cultivo

Finalmente, a pergunta que todos os hackers têm se perguntado: como se tornar um grande hacker? Não sei se é possível se transformar em um. Mas certamente é possível fazer coisas que o tornam estúpido, e se você pode se tornar estúpido, você 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 eles 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ê pode preservar o hacking como algo que você ama, você provavelmente fará isso bem. Tente manter o senso de maravilha que você tinha sobre programação aos 14 anos. Se você está preocupado que seu trabalho atual está apodrecendo seu cérebro, provavelmente está.

Os melhores hackers tendem a ser inteligentes, é claro, mas isso é verdade em muitos campos. Existe alguma qualidade única para os hackers? Perguntei a alguns amigos, e a principal coisa que eles mencionaram foi curiosidade. 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, em efeito, grandes descrições de como as coisas funcionam.

Vários amigos mencionaram a habilidade dos hackers de se concentrar - sua habilidade, como um deles colocou, de "sintonizar tudo fora de suas próprias cabeças". Certamente notei isso. E ouvi vários hackers dizerem que depois de beber até mesmo meio copo de cerveja eles não conseguem programar de jeito nenhum. Então talvez o hacking realmente exija alguma habilidade especial de foco. Talvez os grandes hackers possam carregar uma grande quantidade de contexto em suas cabeças, de modo que quando olham para uma linha de código, eles veem não apenas essa linha, mas todo o programa ao redor dela. John McPhee escreveu que o sucesso de Bill Bradley como jogador de basquete se devia 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 os grandes hackers tenham alguma habilidade inata semelhante. (Eu facho usando uma linguagem muito densa, que encolhe a quadra.)

Isso poderia explicar o desconexo sobre cubículos. Talvez as pessoas encarregadas das instalações, não tendo nenhuma concentração a quebrar, não têm ideia de que trabalhar em um cubículo para um hacker se sente como ter seu cérebro em um liquidificador. (Enquanto Bill, se os rumores de autismo forem verdadeiros, sabe muito bem.)

Uma diferença que notei entre os grandes hackers e as pessoas inteligentes em geral é que os hackers são mais politicamente incorretos. Na medida em que existe uma senha secreta entre bons hackers, é quando eles se conhecem o suficiente para expressar opiniões que os levariam a serem 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. Nessas situações, é útil ter um 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á meu melhor palpite de uma receita. Se é possível se transformar em um grande hacker, o caminho pode ser fazer o seguinte acordo consigo mesmo: você nunca terá que trabalhar em projetos chatos (a menos que sua família vá passar fome), 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 tenha tido escolha no assunto.

Notas

[1] Em justiça, tenho que dizer que a IBM faz hardware decente. Eu escrevi isso em um laptop IBM.

[2] Eles 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 sente muito como significado. Em um projeto como um compilador, você precisa resolver muitos problemas, mas os problemas se encaixam em um padrão, como em um sinal. Enquanto quando os problemas que você precisa resolver são aleatórios, eles parecem ruído.

[4] Einstein em certo 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 vem acontecendo há muito tempo na indústria da construção. Quando você tinha uma casa construída há alguns séculos, 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 a Netscape foi. Provavelmente mais perigoso do que qualquer outra empresa já foi. Não menos porque eles estão determinados a lutar. Em sua página de listagem de empregos, eles dizem que um de seus "valores fundamentais" é "Não seja mau". De uma empresa vendendo ó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 quem é essa uma declaração de guerra.

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