Nota: esse artigo é uma tradução de um ensaio escrito por Paul Graham, chamado “Great Hackers“

Há uns meses atrás eu terminei o meu livro, e em resenhas apareciam constantemente palavras como “provocativo” e “controverso”, para não dizer “idiota”.Eu não quis escrever um livro controverso. Eu queria que ele fosse eficiente. Eu não queria que as pessoas perdessem o tempo delas, em que eu dizia coisas que elas já sabiam. É mais eficiente só dizer os diffs. Mas eu imagino que estava destinado a escrever um livro alarmista.

Edisons

Não há controvérsia sobre qual é a idéia mais controversa: a sugestão que variações de riqueza entre as pessoas não é um problema tão grande quanto parece.

Eu não disse em meu livro que variação em riqueza era uma coisa boa em si. Eu disse que em algumas situações pode ser um sinal de coisas boas. Um dor de cabeça latejante não é uma coisa boa, mas pode vir a ser uma coisa boa — por exemplo, você pode estar recuperando a consciência depois de tomar uma pancada na cabeça.

Variação de riqueza pode ser um sinal de variação em produtividade. (Em uma sociedade composta por um único indivíduo, elas são idênticas.) E isso quase sempre é uma coisa boa: se sua sociedade não tem variação em produtividade, provavelmente não é pelo fato de você estar em uma sociedade em que todos são Thomas Edison. É provável que você esteja em uma sociedade sem Thomas Edisons.

Em uma sociedade com pouca tecnologia não se via muita variedade em produtividade. Se você está em uma tribo nômade que precisa buscar madeira para fazer fogo, quão o melhor catador de galhos é mais produtivo que o pior? Duas vezes? Por outro lado, se você dá a uma pessoa uma ferramenta complexa como um computador, a variação em sua produtividade é enorme.

Essa não é uma idéia nova. Fred Brooks escreveu sobre isso em 1974, e ele se baseou em um estudo de 1968. Mas eu creio que ele subestimou a variação entre os próprios 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 fosse dado? Em programação, assim como em muitas áreas, a parte difícil não é resolver o problema, mas saber qual problema resolver. Imaginação é algo difícil de se medir, mas na prática ela domina o tipo de produtividade que se é medida em linhas de código.

Produtividade costuma variar em qualquer área, mas são poucas nas quais ela varia tanto. A variação entre programadores é tanta que se torna até distinta. Não creio que isso seja algo intrinseco ao ato de programar. Em qualquer área, a tecnologia apenas amplia as diferenças em produtividade. Eu acredito que o que está acontecendo em programação é apenas conseqüência do fato de existir muito espaço de alavancagem em programação. Porém, em todas as áreas a alavanca está se tornando cada vez maior, logo a variação que vamos perceber em outras áreas será cada vez maior em outras áreas, a medida que o tempo passa. E o sucesso de empresas, e países, vai depender cada vez mais de como eles lidam com o sucesso.

Se a variação de produtividade cresce com a tecnologia, então a contribuição dos indivíduos mais produtivos não será apenas desproporcionalmente grande, mas irá na verdade crescer com o tempo. Quando se alcança o ponto em que a 90% da produção de um grupo é criada por 1% dos seus membros, há muito a se perder se algo (como um ataque Viking, ou o estabelecimento de economias planificadas) derruba a produtividade deste grupo para a média.

Se você quer que tirar o máximo deles, nós precisamos entender essas pessoas especialmente produtivas. O que os motiva? Do que precisam para fazer seu trabalho? Como você os identifica? Como você os convence a vir trabalhar para você? E a questão óbvia, como você se torna um deles?

Mais que Dinheiro

Eu conheço uma meia dúzia de super-hackers, então eu parei para pensar sobre tudo o que eles têm em comum. A característica marcante deles é provavelmente que eles adoram programar. Programadores comuns programam apenas para pagar as contas. Hackers brilhantes consideram que isso é algo que eles fazem por diversão; uma coisa que os deixa felizes ao descobrir que há pessoas que ainda os pagam para que façam isso.

Diz-se às vezes que programadores brilhantes são indiferentes ao dinheiro. Isso não é verdade. O que é verdade é que tudo que importa a eles é fazer um trabalho interessante. Mas se você ganha o suficiente, você pode trabalhar no que quiser. Por essa razão os hackers são atraídos pela idéia de conseguir receber vultosas quantias de dinheiro. Porém, enquanto eles têm que ir trabalhar todo dia eles estão mais preocupados com o que fazem do que com o quanto ganham para fazê-lo.

Economicamente, esse é um fato de suma importância, pois indica que você não precisa pagar aos grandes hackers exatamente o quanto eles valem. Um grande programador costuma ser 10 ou 100 vezes mais produtivo que programador ordinário, mas ele estará feliz da vida se receber apenas 3 vezes mais. Pretendo explicar depois, isso se dá pelo fato de não saberem o quão bom eles são. Mas isso também se dá pelo fato que o dinheiro não é a coisa principal que eles querem.

O que os hackers querem? Assim como qualquer artesão, hackers gostam de boas ferramentas. Na verdade, esse é um eufemismo. Bons hackers acham insuportável o uso de ferramentas ruins. Eles irão se recusar a trabalhar em projetos que não possuem a infraestrutura correta.

Em uma startup para a qual já trabalhei, uma das coisas pregadas no nosso mural de avisos era um anúncio da IBM. Lá havia uma foto de um AS400, e a manchete dizia – eu lembro – “Hackers odeiam isso” [1]

Quando você decide qual infraestrutura você vai usar para um projeto, você não está tomando uma decisão técnica. Você está tomando uma decisão social, e essa pode a ser a mais importante das duas. Por exemplo, se sua empresa quer desenvolver software, pode parecer uma escolha prudente que ele seja desenvolvido em Java. Porém, quando você escolhe uma linguagem, você também está escolhendo uma comunidade. Os programadores que você irá conseguir contratar para trabalhar em um projeto em Java não serão tão espertos quanto os que você vai conseguir para trabalhar em um projeto em Python. E a qualidade dos hackers provavelmente importa mais do que a linguagem que você escolhe. Embora, francamente, o fato de bons hackers preferirem Python a Java deveria ser um indicador do mérito relativo dessas linguagens.

Os “engravatados” dão preferência às linguagens mais populares pois eles as tratam como padrões de indústria. Eles não querem apostar o futuro da empresa em algo como o Betamax. O lance das linguagens, entretanto, é que elas não são apenas padrões. Se você quiser transportar bits em uma rede, continue com o TCP/IP, por favor. Mas uma linguagem de programação não é um formato. Uma linguagem de programação é uma forma de expressão.

Eu li recentemente que Java acabou de ultrapassar Cobol como a linguagem mais popular. Como um padrão, não há nada melhor. Mas como meio de expressão, você encontra coisas muito melhores. De todos os grande programadores que eu conheço, eu conheço apenas um que iria programar voluntariamente em Java. De todos os os grandes programadores que eu conheço que não trabalham na Sun, no Java, eu não conheço nenhum.

Grandes hackers geralmente insistem em usar software open source. Não apenas por ser melhor, mas por que lhes dá mais controle. Bons hackers insistem em ter controle. Isso é parte do que os torna bons hackers: quando algo está errado, eles precisam consertar. É bom que eles se sintam desse jeito quando estão desenvolvendo software para você. Não fique surpreso por eles lidarem da mesma forma com o sistema operacional.

Alguns anos atrás um investidor de risco me contou a respeito de uma nova startup com a qual ele estava envolvido. Parecia promissor. Porém, no próximo encontro, ele disse que eles tinham decidido desenvolver o software deles usando Windows NT, e tinham acabado de contratar um desenvolvedor experiente em NT para ser o CTO. Quando eu escutei isso, pensei “Esses caras estão arruinados.” Primeiro, não era possível que o CTO fosse um hacker de primeira linha, já que para ser um desenvolvedor experiente em NT você tem que usar NT voluntariamente, múltiplas vezes, coisa que não consigo imaginar sendo feita por um grande hacker; além disso, mesmo que ele fosse bom, ele teria muita dificuldade para contratar qualquer para trabalhar em um projeto que tivesse que ser desenvolvido em NT. [2]

A Fronteira Final

Depois do software, a ferramenta de trabalho mais importante para um hacker é provavelmente o seu escritório. Grandes empresas acreditam que a função do escritório é para indicar a hierarquia. Porém, hackers usam seus escritórios para mais que isso: eles usam o escritório como um lugar para se pensar. E, se você está em uma empresa de tecnologia, o que sai da cabeça dele é o seu produto. Dessa forma, fazer com que hackers trabalhem um ambiente barulhento, cheio de distrações é o mesmo que montar uma empresa de serviço de pintura num lugar que o ar esteja cheio de pó.

O cartoon do Dilbert lida muito com o assunto dos cubículos, e com razão. Todos os hackers que eu conheço odeiam cubículos. A simples possibilidade de serem interrompidos é suficiente para impedi-los de trabalhar em problemas difíceis. Se você quer fazer qualquer trabalho de verdade em um escritório com cubículos, você tem duas opções: trabalha em casa, ou chega mais cedo ou mais tarde ou em fins de semana, quando não há mais ninguém. Será que as empresas não percebem que isso é um sinal que algo está errado? Um ambiente de trabalho deveria ser algo que ajuda você a trabalhar, não algo que você tem que contornar se quiser trabalhar.

Empresas como a Cisco se orgulham pelo fato de todos lá terem apenas um cubículo, até mesmo o CEO. Entretanto eles não são tão avançados como pensam; obviamente eles ainda encaram o espaço como um sinal de hierarquia. Não se esqueça também que a Cisco é famosa por ter pouquíssimo desenvolvimento de produto in-house. Eles conseguem novas tecnologias através de aquisições de startups que criam tecnologia — presume-se que seja o lugar onde os hackers tinham um lugar calmo para trabalhar.

Uma empresa grande que entende o que os hackers precisam é a Microsoft. Uma vez em um vi um anúncio de recrutamento da Microsoft que tinha uma foto grande de uma porta. Trabalhe para nós, era a premissa, e daremos um lugar para trabalhar onde você realmente possa produzir. E você sabe, a Microsoft é notória entre as grandes empresas por serem capazes de desenvolver software in-house. Não o desenvolvem bem, talvez, mas bem o suficiente.

Se empresas querem que hackers sejam produtivos, eles devem ficar atentos para o que eles fazem em casa. Em casa, hackers podem ajeitar as coisas de jeito que eles sejam mais produtivos. Quando trabalham em casa, hackers não trabalham em lugares abertos e barulhentos; eles trabalham em lugares fechados por portas. Eles trabalham em lugares confortáveis, familiares com pessoas por perto quando precisam andar quando há algo que precisa de reflexão, ao invés de caixas de vidro enfiadas em acres e acres de estacionamentos. Eles têm um sofá onde eles podem tirar uma soneca quando se sentem cansados, ao invés de ficar sentados em frente às suas mesas, num coma, fingindo que trabalham. Não há equipe de limpeza como aspirador de pó que faz barulho nas melhores horas dedicadas para o trabalho de programação. Não há reuniões ou, Deus os livre, retiros corporativos ou execícios de team-building. E quando você presta atenção quanto ao que estão fazendo no computador, você vai que isso reitera o que eu disse anteriormente sobre ferramentas. Eles podem ser obrigados a usar Java e Windows no trabalho, mas em casa – onde podem escolher livremente – é mais provável que você os veja usando Perl e Linux.

Na verdade, essas estatísticas sobre Cobol ou Java serem as linguagens mais populares podem enganar. O que deveríamos olhar, se quisermos saber quais são as melhores ferramentas, são aquelas que os hackers escolhem quando eles podem escolher livremente, em projetos pessoais. Quando você se faz essa pergunta, você vai ver que sistemas operacionais open source já possuem uma fatia dominante do mercado, e que a linguagem número um provavelmente é Perl.

Interesse

Além de boas ferramentas, hackers querem projetos interessantes. O que faz que um projeto seja interessante? Bem, certamente aplicações sexy como aviões stealth ou software para efeitos especiais seriam interessantes de se trabalhar. Mas qualquer aplicação pode ser interessante se ela apresenta desafios técnicos novos. Logo, é difícil predizer quais problemas são do agrado de hackers, pois alguns se tornam interessantes apenas quando as pessoas trabalhando neles descobrem uma nova forma de solução. Antes da ITA (que escreveu o software para a Orbitz), as pessoas trabalhando em sistemas de busca de passagens áreas provavelmente acreditaram que era um dos aplicativos mais monótonos já existentes. Mas a ITA tornou-o em um problema interessante ao redefini-lo de forma ambiciosa.

Creio que isso foi o mesmo que aconteceu com o Google. Quando o Google foi fundado, o senso comum entre os então-chamados portais é que buscas eram algo monótono e sem imaginação. Porém o pessoal do Google não achava isso, e por isso eles o fizeram tão bem.

Esse é um aspecto no qual os gerentes podem fazer a diferença. Da mesma forma que um pai diz para um filho “Eu aposto que você não consegue limpar o seu quarto em 10 minutos”, um bom gerente às vezes sabe redefinir um problema em algo mais interessante. Steve Jobs parece ser especialmente bom nisso, em parte por ser uma pessoa de padrões elevados. Eram muitos os computadores pequenos e baratos antes do Mac. Ele redefiniu o problema: faça um que seja bonito. E isso provavelmente incentivou os desenvolvedores muito mais que qualquer outro método.

Eles conseguiram, sem dúvida. Quando o Mac apareceu, você nem precisava ligá-lo para saber que seria algo bom; dava pra saber a partir do gabinete. Há algumas semanas eu estava andando em uma rua de Cambridge, em no lixo eu vi algo que parecia ser o estojo do Mac. Eu olhei dentro, e lá tinha um Mac SE. Eu levei pra casa e liguei, e ele iniciou. A carinha feliz do Mac, logo depois o Finder. Meu Deus, foi tão simples. Foi da mesma forma que… o Google.

Hackers gostam de trabalhar com pessoas de padrões elevados. Mas não é suficiente que seja apenas preciso na descrição de seus padrões. Tem que ser alguém que insista nas coisas certas. Isso significa que você mesmo tem que ser um hacker. Eu vi alguns artigos que tentavam explicar sobre gerência de programadores. Na verdade, deveriam ser dois artigos: um sobre o que deve ser feito no caso de você ser um programador, e outro no caso você não seja. O segundo poderia ser resumido em uma palavra: desista.

O problema não está tanto no gerenciamento diário. Bons hackers praticamente gerenciam a si mesmos. O problema é, se você não for um bom hacker, você não é capaz de dizer quem é um bom hacker. Um problema similar pode ser usado para explicar por que os carros americanos são tão feios. Eu o chamo de paradoxo do design. Você pode acreditar que você fazer produtos que sejam bonitos simplesmente contratando um bom designer. Mas se você mesmo não tem bom gosto, como é que você vai conseguir reconhecer um bom designer? Por definição, você não consegue, baseado no portfolio. E você não se guia pelos prêmios que ele ganhou ou pelos lugares onde ele trabalhou, já que em design – como em muitas outras áreas – os que tem prêmios são escolhidos pela moda ou pela lábia, sendo a habilidade da pessoa apenas um distante terceiro lugar. Não há forma de se escapar: você não é capaz de gerenciar algo que se pretende que seja bonito sem saber o que é belo. Carros americanos são feios porque empresas americanas são dirigidas por pessoas de mau-gosto.

Muitas pessoas nesse país pensam que bom-gosto é algo subjetivo, ou até mesmo frívolo. Não é. Para gerenciar o design, o gerente tem que ser o usuário mais exigente dos produtos da empresa. Se você tem bom gosto, você pode fazer – assim como o Steve Jobs – com que o problema que as pessoas tenham que resolver é satisfazer os seus gostos.

Pequenos, Chatos Problemas

É bem fácil dizer quais são os problemas que não são interessantes: aqueles que, ao invés de resolver um problema complexo e bem definifido, você tem que resolver várias coisinhas chatas. Um dos piores tipos de projetos é o qual se deve desenvolver uma interface para um software que está cheio de bugs. Outro é quando você tem que personalizar algo para um cliente que não sabe o que quer. Para hackers, esses projetos é uma tortura.

A característica marcante desses pequenos problemas chatos é que não se aprende nada com ele. Escrever um compilador é interessante pois te ensina como um compilador funciona. Porém, escrever uma interface para um software cheio de bugs não te ensina nada, já que os bugs são aleatórios. [3] Hackers evitam esses probleminhas pentelhos não apenas por ser pessoas difíceis ou excessivamente críticas. É uma questão de auto-preservação. Trabalhar em problemas pentelhos te deixa estúpido. Bons hackers evitam esses problemas pela mesma razão que modelos evitam cheeseburgers.

É claro que alguns problemas possuem intrinsicamente essa característica. Devido a oferta e demanda, até pagam especialmente bem. Dessa forma, uma empresa que encontrar uma forma de fazer com que os bons hackers trabalhem em problemas tediosos seria muito bem sucedida. Como é que você o faria?

Um lugar onde isso acontece é em startups. Em nossa startup nós tínhamos o Robert Morris como administrador de sistemas. Isso é o mesmo que ter os Rolling Stones tocando em um bar mitzvah. Não é possível que um talento desse quilate seja contratado. Mas as pessoas são capazes de fazer qualquer coisa pelas empresas das quais eles são os fundadores. [4]

As grandes empresas resolvem esse problema particionando a empresa. Eles fazem com que as pessoas realmente espertas trabalhem em um departamento de P&D, onde os empregados não precisam trabalhar diretamente com os problemas pentelhos dos clientes. [5] Nesse modelo, o departamento de pesquisa funciona como uma mina. Lá surgem novas idéias; quem sabe o resto da empresa consiga usá-las.

Você não precisa chegar a esse extremo. A programação bottom-up dá uma outra forma de fazer a divisão da empresa: faça com as pessoas espertas trabalhem como produtores das ferramentas. Se sua empresa desenvolve software que faz x, deixe um grupo para construir as ferramentas para o desenvolvimento de software desse tipo, e o outro grupo usa essas ferramentas para escrever os aplicativos. Dessa forma você pode ser capaz de fazer com as pessoas espertas escrevam 99% do seu código, mas mesmo assim os mantém isolados de usuários – assim como eles estariam em um departamento de pesquisa tradicional. Os que desenvolvem as ferramentas teriam usuários, mas esses seriam apenas os desenvolvedores da própria empresa. [6]

Se a Microsoft usasse essa estratégia, o software deles não estaria cheio de falhas de segurança, já que os menos espertos, que estariam desenvolvendo os aplicativos em si, não estariam fazendo coisas em baixo-nível, como fazendo alocação de memória. Ao invés de desenvolver o Word diretamente em C, eles estariam apenas mexendo com grandes blocos de linguagem-Word. (Duplo, creio eu, é o termo técnico)

Grupos

Além de problemas interessantes, bons hackers gostam de outros bons hackers. Bons hackers costumam se agrupar — as vezes até de forma extraordinária, como aconteceu com a Xerox Parc. Logo, você pode ter certeza que não vai atrair bons hackers numa proporção direta com a qualidade do ambiente que é oferecida. A tendência de aglutinação se traduz em um proporção quadrática em relação ao ambiente. Assim, é um sistema em que o vencedor leva tudo. Em qualquer instante de tempo, há apenas uns 10 ou 20 lugares onde os hackers mais gostariam de trabalhar e, se você não está em um desses lugares não quer dizer que você vai apenas ter menos hackers. Você vai ficar com nenhum.

Ter grandes hackers, por si, não é suficiente para ter uma empresa de sucesso. Isso deu certo para o Google e ITA, dois dos lugares em voga hoje, mas não ajudou a Thinking Machines ou Xerox. A Sun teve um bom período, mas seu modelo de negócios está em crise. Nessa situação, nem mesmo os melhores hackers podem te salvar.

Eu creio que, mesmo assim, se tudo for igual uma empresa que consegue atrair os melhores hackers vai ter uma vantagem enorme. Há pessoas que vão discordar disso. Quando estávamos levantando capital de investimento nos anos 90, muitos nos disseram que as empresas de software não vencem pela qualidade do software, mas por valor de marca, dominação de canais de distribuição e por fechar os negócios certos.

Eles realmente acreditavam nisso, e acho que sei o porquê. Eu acho que muitos dos investidores de risco estão procurando pela próxima Microsoft, ainda que inconscientemente. Mas quando a Microsoft é o seu modelo, você não está procurando por empresas que esperam ganhar por escreverem software de qualidade. Mas os investidores de risco erram ao procurar pela próxima Microsoft, já que nenhuma startup pode ser a próxima Microsoft a não ser que exista outra empresa que esteja disposta a fraquejar no momento certo e se torne a próxima IBM.

É um erro usar a Microsoft como modelo, já que toda a sua cultura deriva daquele golpe de sorte. A Microsoft é um ponto fora da curva. Se você descartar esse ponto, você vai encontrar bons produtos sendo os vencedores do mercado. Os investidores devem procurar é a próxima Apple ou a próxima Google.

Eu acredito que Bill Gates sabe disso. O que o preocupa em relação ao Google não é o poder de sua marca, mas o fato deles possuírem os melhores hackers [7]

Reconhecimento

Quem são os grandes hackers? Como você reconhece quando você se depara com um? Isso é muito difícil, na verdade. Até mesmo os hackers não sabem dizer. Eu tenho certeza que meu amigo Trevor Blackwell é um grande hacker. Talvez você tenha lido no Slashdot como ele construiu o seu próprio Segway. O mais marcante em seu projeto é que desenvolveu todo o software em um único dia (em Python, por acaso)

Para Trevor, isso é comum. Porém, quando eu o conheci, eu pensei que fosse um idiota total. Ele estava no escritório do Robert Morris falando sobre alguma coisa, e lembro de ter ficado atrás dele fazendo sinais para o Robert que ele espantasse o maluco para que pudéssemos sair para o almoço. Robert disse que também fez mal-julgamento do Trevor, no início. Pelo que conta, quando Robert o conheceu, Trevor tinha acabado de começar uma nova rotina que envolvia escrever tudo sobre qualquer aspecto de sua vida em uma pilha de papel, a qual era carregada para todos os cantos. Ele também tinha acabado de chegar do Canadá e tinha um sotaque muito estranho, além de ter mullets.

O problema aumenta devido ao fato de hackers, apesar de ter a reputação de desprezo por relações sociais, costumam se esforçar muito para que pareçam espertos. Quando estava na pós-graduação eu costumava passar algum tempo no laboratório de IA do MIT. Assustava, no começo. Todos lá falavam muito rápido. Mas depois de um tempo eu aprendi o truque de falar rápido. Você não tem que pensar mais rápido; apenas use o dobro de palavras para falar qualquer coisa.

Com essa quantidade de ruído no sinal, é difícil conhecer um bom hacker quando se conhece. Eu não sei dizer, até hoje. Você também não os consegue diferenciar pelos seus currículos. A única maneira de se reconhecer um bom hacker é trabalhando com eles em algum projeto.

Essa é a razão pela qual áreas com empresas high-tech giram em torno de universidades. O princípio ativo não é nem tanto os professores, mas os alunos. Startups surgem ao redor de universidades pois elas juntam pessoas de potencial e faz com que elas trabalhem nos mesmos projetos. Os mais espertos até aprendem quem são os outros espertos, e em conjunto eles bolam projetos próprios.

Já que você não consegue dizer quem é um grande hacker a não ser que trabalhe com ele, os próprios hackers não sabem dizer o quão bom eles são. Isso é verdade na maior parte dos hackers. Eu já encontrei pessoas que são excelentes em algo, mas não se convencem de sua própria capacidade mesmo com todos os outros ao seu redor parecendo tão incompetentes.

Mas é particularmente difícil para que hackers saibam o quão bons eles são, já que é difícil que eles comparem o trabalho deles. Isso é mais fácil em outras áreas. Nos 100 metros rasos, você descobre o mais rápido em 10 segundos. Até mesmo na Matemática há um certo consenso sobre quais problemas são difíceis de solucionar, e o que é tido como uma boa solução. Programar, entretanto, é como escrever. Quem é capaz de dizer qual de dois romances é melhor? Certamente não são os autores.

Com hackers, pelo menos, outros hackers podem dizer. Isso acontece pois – diferentemente de escritores – hackers trabalham em projetos conjuntamente. Quando você despeja algum pergunta difícil para alguém pela internet, é fácil ver o quanto eles podem te ajudar. Mas hackers não costumam ficar observando um ao outro durante o trabalho. Se você perguntar a um bom hacker o quão bom ele é, ele provavelmente irá responder que não sabe. Ele não está sendo modesto. Ele realmente não sabe.

E nenhum de nós sabe, exceto as pessoas com quem realmente trabalhamos. Isso nos deixa em uma situação estranha: nós não sabemos quem deveriam ser nossos heróis. Os hackers que ficaram famosos costumam ficar famosos por acidentes de Relações Públicas. De vez em quando, eu preciso dar um exemplo de um grande hacker, e nunca sei qual usar. Os primeiros nomes que me vêm à cabeça sempre são as pessoas que conheço pessoalmente, mas parece que é meio brega. Então, talvez usasse o nome de Richard Stallman, ou Linus Torvalds, ou Alan Kay, ou alguém famoso como eles. Mas eu não tenho idéia se eles realmente são bons hackers. Eu nunca trabalhei com eles.

Se existir um Michael Jordan de programação, ninguém sabe. Nem mesmo ele.

Cultivo

Para encerrar, a pergunta que todos os hackers devem estar se perguntando: como se tornar um grande hacker? Eu não sei se é possível que você se modele até se transformar em um. Mas é certamente possível fazer coisas que possam te deixar estúpido, e se você se deixar estúpido, provavelmente você pode se deixar esperto também.

O segredo para se tornar um hacker é trabalhar naquilo que você gosta. Quando eu penso nos grandes hackers que eu conheço, uma coisa que eles tem em comum é a extrema dificuldade em trabalhar com algo que eles não querem. Eu não sei se isso é causa ou efeito; pode ser ambos.

Para fazer algo bem você tem que adorar o que faz. Então, enquanto você acreditar que programar é algo que você adora, é provável que você o faça direito. Tente manter o espírito que você tinha quando programava com 14 anos de idade. Se você está achando que seu emprego atual está estragando seu cérebro, provavelmente está.

Os melhores hackers costumam ser espertos, claro, mas isso é verdade em muitas áreas. Se há alguma qualidade que seja única dos hackers? Eu perguntei a alguns amigos, e a coisa que mais me disseram foi a curiosidade. Eu sempre imaginei que as pessoas espertas fossem curiosas – que a curiosidade fosse o primeiro produto do Conhecimento. Mas, aparentemente, os hackers são especialmente curiosos, sobretudo sobre como as coisas funcionam. Isso faz sentido, já que programas são, na prática, uma grande descrição de como as coisas funcionam.

Muitos amigos mencionaram a capacidade que os hackers têm para se concentrar – a habilidade, como disse um, para “desligar qualquer coisa que esteja fora de suas cabeças”. Eu já notei isso. E eu já ouvi de hackers que dizem que depois de meia cerveja não conseguem programar nada. Talvez programar realmente necessite de uma capacidade especial de concentração. Talvez os grandes hackers consigam colocar uma grande quantidade de contexto na cabeça, de forma que, quando olham para uma linha de código, não estão vendo apenas uma única linha de código mas todo o programa ao redor. John McPhee escreveu que o sucesso de Bill Bradley como jogador de basquete era em parte devido a sua visão periférica extraordinária. Uma visão perfeita é de 47 graus de visão periférica vertical. Bill Bradley tinha 70; ele era capaz de ver a cesta até quando estava olhando para o chão. Talvez os grandes hackers tenham alguma habilidade nata similar. (Eu trapaceio usando uma linguagem muito densa, que diminui o tamanho da quadra.)

Isso poderia explicar a desconexão em relação aos cubículos. Talvez as pessoas encarregadas das instalações não precisam tanto de concentração, não tendo idéia que trabalhar em um cubículo é para um hacker o mesmo que colocar seu cérebro em um liquidificador. (Ao passo que Bill – sendo verdadeiros os boatos de autismo – sabe muito bem.)

Uma diferençc que percebi entre os grandes hackers e as pessoas espertas em geral é que os hackers são mais politicamente incorretos. Se existir um aperto de mão secreto entre os bons hackers, é o fato de conhecer um ao outro bem o suficiente para expressarem suas opiniões sem medo de ser apedrejados pelo público em geral. Até entendo porque ser politicamente incorreto pode ser algo útil para um programador. Programas são complexos e, nas mãos de um bom programador, muito fluidos. Nessas situações ajuda ter um hábito de questionar sempre o senso comum.

Será possível cultivar essas características? Não sei. Mas ao menos você pode deixar de reprimi-las. Aqui vai minha melhor tentativa para uma receita. Se for possível se tornar um grande hacker, a maneira de fazer isso seria fazendo um pacto com si mesmo: nunca trabalhe em projetos maçantes (a não ser que sua família vá morrer de fome em caso contrário), em troca você promete que nunca vai fazer um trabalho mal-feito. Todos os grandes hackers que eu conheço parecem ter feito esse pacto, embora nenhum deles tenham feito alguma escolha para isso.

Notas

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

[2] Eles realmente estavam rumo à desgraça. Fecharam alguns meses depois.

[3] Eu acho que é isso que as pessoas querem dizer quando falam sobre o “significado da vida”. Nesse aspecto, parece uma idéia estranha. A vida não é uma expressão; como é que pode ter significado? Mas ela pode ter uma característica que é muito parecida com significado. Em um projeto como um compilador, você tem que resolver uma série de problemas, mas todos os problemas pertencem a um padrão, como um sinal forte. Quando os problemas que você tem que resolver são aleatórios, eles parecem ruído.

[4] Einstein trabalhou por um momento projetando geladeiras. (Ele era dono de parte da empresa.)

[5] É difícil precisar o que é pesquisa no mundo de computação, mas como primeira aproximação: é software que não possui usuários.

Não creio que é a publicação que faz com que os grandes hackers trabalhem em departamentos de pesquisa. Eu acredito que é principalmente o fato de não ter uma reunião de horas com o gerente de produtos sobre os problemas para integrar a versão coreana do Word 13.27 com o clipe de papel falante.

[6] Algo parecido tem acontecido por um longo tempo na industria civil. Quando se construia uma coisa centenas de anos atrás, o empreiteiro construia tudo. Porém, mais e mais os empreiteiros têm montado componentes projetados e fabricados por outra pessoa. Isso tem, do mesmo jeito que publicação eletrônica em desktop, dado às pessoas liberdade para experimentar com idéias desastrosas, mas é certamente algo mais eficiente.

[7] Google é muito mais perigoso para a Microsoft que a Netscape foi. Provavelmente mais perigosa que qualquer outra empresa jamais foi. Ao menos por estarem dispostos para a briga. Na página de empregos, eles dizem que seu princípio fundamental é “Não seja maligno”. Para uma empresa que estivesse vendendo óleo de soja ou equipamento para mineração, tal afirmação seria apenas excêntrica. Mas eu acho que todos nós que estamos no meio de computação sabe reconhecer que essa é uma declaração de guerra a alguém.