GRANDES HACKERS

Julio de 2004

(Este ensayo se deriva de una charla en Oscon 2004.)

Hace unos meses terminé un nuevo libro , y en las reseñas sigo notando palabras como "provocador" y "controversial". Por no hablar de "idiota".

No quise que el libro fuera polémico, sino que fuera eficaz. No quería que la gente perdiera el tiempo diciéndoles cosas que ya sabían. Es más eficaz simplemente darles las diferencias, pero supongo que eso tiene que dar como resultado un libro alarmante.

Edison

No hay controversia sobre qué idea es más controvertida: la sugerencia de que la variación en la riqueza podría no ser un problema tan grande como pensamos.

No dije en el libro que la variación en la riqueza fuera en sí algo bueno. Dije que en algunas situaciones podría ser un signo de algo bueno. Un dolor de cabeza punzante no es algo bueno, pero puede ser un signo de algo bueno, por ejemplo, que estás recuperando la conciencia después de recibir un golpe en la cabeza.

La variación en la riqueza puede ser un signo de variación en la productividad (en una sociedad de una sola persona, son idénticas). Y eso es casi seguro algo bueno: si en tu sociedad no hay variación en la productividad, probablemente no se deba a que todos sean Thomas Edison, sino a que no tienes ningún Thomas Edison.

En una sociedad de baja tecnología no se observan grandes variaciones en la productividad. Si una tribu de nómadas recoge leña para hacer fuego, ¿cuánto más productivo será el mejor recolector de leña que el peor? ¿Un factor de dos? En cambio, cuando se le da a la gente una herramienta compleja como un ordenador, la variación en lo que pueden hacer con ella es enorme.

No es una idea nueva. Fred Brooks escribió sobre ella en 1974 y el estudio que citó se publicó en 1968. Pero creo que subestimó la variación entre programadores. Escribió sobre la productividad en líneas de código: los mejores programadores pueden resolver un problema determinado en una décima parte del tiempo. Pero ¿qué pasa si el problema no está dado? En programación, como en muchos campos, lo difícil no es resolver problemas, sino decidir qué problemas resolver. La imaginación es difícil de medir, pero en la práctica domina el tipo de productividad que se mide en líneas de código.

La productividad varía en cualquier campo, pero hay pocos en los que varíe tanto. La variación entre programadores es tan grande que se convierte en una diferencia de tipo. Sin embargo, no creo que esto sea algo intrínseco a la programación. En todos los campos, la tecnología magnifica las diferencias en productividad. Creo que lo que está sucediendo en la programación es simplemente que tenemos mucha influencia tecnológica. Pero en todos los campos la palanca se está haciendo más larga, por lo que la variación que vemos es algo que cada vez más campos verán a medida que pase el tiempo. Y el éxito de las empresas y los países dependerá cada vez más de cómo aborden esa cuestión.

Si la variación de la productividad aumenta con la tecnología, entonces la contribución de los individuos más productivos no sólo será desproporcionadamente grande, sino que en realidad crecerá con el tiempo. Cuando se llega al punto en que el 90% de la producción de un grupo es creada por el 1% de sus miembros, se pierde mucho si algo (ya sean incursiones vikingas o planificación central) reduce su productividad hasta el promedio.

Si queremos sacarles el máximo partido, tenemos que entender a estas personas especialmente productivas. ¿Qué las motiva? ¿Qué necesitan para hacer su trabajo? ¿Cómo reconocerlas? ¿Cómo conseguir que vengan a trabajar para ti? Y luego, por supuesto, está la cuestión de cómo convertirse en uno de ellos.

Más que dinero

Conozco a un puñado de superhackers, así que me senté a pensar en lo que tienen en común. Su cualidad distintiva es probablemente que realmente aman programar. Los programadores comunes escriben código para pagar las cuentas. Los grandes hackers piensan que es algo que hacen por diversión y por lo que están encantados de encontrar gente dispuesta a pagarles.

A veces se dice que los grandes programadores son indiferentes al dinero, pero no es del todo cierto. Es cierto que lo único que les importa es hacer un trabajo interesante, pero si ganas suficiente dinero, puedes trabajar en lo que quieras y, por eso, a los hackers les atrae la idea de ganar grandes cantidades de dinero. Pero mientras tengan que ir a trabajar todos los días, les importa más lo que hacen allí que cuánto les pagan por ello.

En términos económicos, este es un hecho de la mayor importancia, porque significa que no hay que pagar a los grandes hackers ni lo que valen. Un gran programador puede ser diez o cien veces más productivo que uno normal, pero se considerará afortunado si le pagan el triple. Como explicaré más adelante, esto se debe en parte a que los grandes hackers no saben lo buenos que son, pero también a que el dinero no es lo principal que quieren.

¿Qué quieren los hackers? Como a todos los artesanos, a los hackers les gustan las buenas herramientas. De hecho, eso es un eufemismo. A los buenos hackers les resulta insoportable utilizar malas herramientas. Simplemente se negarán a trabajar en proyectos con la infraestructura incorrecta.

En una empresa emergente en la que trabajé una vez, una de las cosas que colgaban en nuestro tablón de anuncios era un anuncio de IBM. Era una foto de un AS400 y el titular decía, creo, "los hackers lo desprecian". [1]

Cuando decides qué infraestructura utilizar para un proyecto, no solo estás tomando una decisión técnica, sino también una decisión social, y esta puede ser la más importante de las dos. Por ejemplo, si tu empresa quiere escribir algún software, puede parecer una opción prudente escribirlo en Java. Pero cuando eliges un lenguaje, también estás eligiendo una comunidad. Los programadores que podrás contratar para trabajar en un proyecto Java no serán tan inteligentes como los que podrías contratar para trabajar en un proyecto escrito en Python. Y la calidad de tus hackers probablemente importe más que el lenguaje que elijas. Aunque, francamente, el hecho de que los buenos hackers prefieran Python a Java debería decirte algo sobre los méritos relativos de esos lenguajes.

Los empresarios prefieren los lenguajes más populares porque los consideran estándares. No quieren apostar la empresa por Betamax. Sin embargo, lo que pasa con los lenguajes es que no son solo estándares. Si tiene que mover bits a través de una red, utilice TCP/IP sin dudarlo. Pero un lenguaje de programación no es solo un formato. Un lenguaje de programación es un medio de expresión.

He leído que Java acaba de superar a Cobol como lenguaje más popular. Como estándar, no se puede pedir más, pero como medio de expresión se puede hacer mucho mejor. De todos los grandes programadores que se me ocurren, sólo conozco a uno que programaría voluntariamente en Java. Y de todos los grandes programadores que se me ocurren que no trabajan para Sun, en Java, no conozco a ninguno.

Los grandes hackers también suelen insistir en utilizar software de código abierto. No sólo porque es mejor, sino porque les da más control. Los buenos hackers insisten en tener el control. Esto es parte de lo que los convierte en buenos hackers: cuando algo no funciona, necesitan arreglarlo. Quieres que sientan lo mismo sobre el software que están escribiendo para ti. No deberías sorprenderte si sienten lo mismo sobre el sistema operativo.

Hace un par de años, un amigo capitalista de riesgo me habló de una nueva empresa en la que estaba involucrado. Parecía prometedora. Pero la siguiente vez que hablé con él, me dijo que habían decidido desarrollar su software en Windows NT y que acababan de contratar a un desarrollador de NT con mucha experiencia para que fuera su director técnico. Cuando escuché esto, pensé: estos tipos están condenados. En primer lugar, el director técnico no podía ser un hacker de primera, porque para convertirse en un desarrollador de NT eminente tendría que haber usado NT voluntariamente, varias veces, y no podía imaginarme a un gran hacker haciendo eso; y en segundo lugar, incluso si fuera bueno, tendría dificultades para contratar a alguien bueno para trabajar para él si el proyecto tuviera que desarrollarse en NT. [2]

La última frontera

Después del software, la herramienta más importante para un hacker es probablemente su oficina. Las grandes empresas creen que la función de un espacio de oficina es expresar el rango. Pero los hackers usan sus oficinas para algo más que eso: las usan como un lugar para pensar. Y si eres una empresa de tecnología, sus pensamientos son tu producto. Por lo tanto, hacer que los hackers trabajen en un entorno ruidoso y que distraiga es como tener una fábrica de pinturas donde el aire está lleno de hollín.

La tira cómica Dilbert tiene mucho que decir sobre los cubículos, y con razón. Todos los hackers que conozco los desprecian. La mera perspectiva de ser interrumpido es suficiente para evitar que los hackers trabajen en problemas difíciles. Si quieres hacer un trabajo real en una oficina con cubículos, tienes dos opciones: trabajar en casa o llegar temprano o tarde o un fin de semana, cuando no hay nadie más. ¿No se dan cuenta las empresas de que esto es una señal de que algo no va bien? Se supone que un entorno de oficina debe ser algo que te ayude a trabajar, no algo a pesar de lo cual trabajes.

Las empresas como Cisco están orgullosas de que todos allí tengan un cubículo, incluso el director ejecutivo. Pero no son tan avanzados como creen; obviamente, todavía consideran el espacio de oficina como una insignia de rango. Cabe señalar también que Cisco es famoso por realizar muy poco desarrollo de productos internamente. Obtienen nueva tecnología comprando las empresas emergentes que la crearon, donde presumiblemente los piratas informáticos tenían un lugar tranquilo para trabajar.

Una gran empresa que entiende lo que necesitan los hackers es Microsoft. Una vez vi un anuncio de contratación de Microsoft con una gran imagen de una puerta. Trabaja con nosotros, la premisa era, y te daremos un lugar para trabajar donde realmente puedas hacer tu trabajo. Y, como sabes, Microsoft se destaca entre las grandes empresas por ser capaz de desarrollar software internamente. No muy bien, tal vez, pero lo suficientemente bien.

Si las empresas quieren que los hackers sean productivos, deberían fijarse en lo que hacen en casa. En casa, los hackers pueden organizar las cosas por sí mismos para poder hacer lo máximo posible. Y cuando trabajan en casa, los hackers no trabajan en espacios abiertos y ruidosos, sino en habitaciones con puertas. Trabajan en lugares acogedores y de barrio con gente alrededor y algún lugar por donde caminar cuando necesitan reflexionar sobre algo, en lugar de hacerlo en cajas de cristal en acres de aparcamientos. Tienen un sofá en el que pueden echarse una siesta cuando se sienten cansados, en lugar de sentarse en coma en su escritorio, fingiendo que trabajan. No hay un equipo de personas con aspiradoras que rugen todas las noches durante las horas pico de hackeo. No hay reuniones o, Dios no lo quiera, retiros corporativos o ejercicios de formación de equipos. Y cuando miras lo que están haciendo en ese ordenador, verás que refuerza lo que dije antes sobre las herramientas. Puede que tengan que usar Java y Windows en el trabajo, pero en casa, donde pueden elegir por sí mismos, es más probable que los encuentres usando Perl y Linux.

De hecho, estas estadísticas sobre Cobol o Java como los lenguajes más populares pueden ser engañosas. Lo que deberíamos analizar, si queremos saber qué herramientas son las mejores, es lo que los hackers eligen cuando pueden hacerlo libremente, es decir, en sus propios proyectos. Cuando uno se hace esa pregunta, descubre que los sistemas operativos de código abierto ya tienen una cuota de mercado dominante, y el lenguaje número uno es probablemente Perl.

Interesante

Además de buenas herramientas, los hackers quieren proyectos interesantes. ¿Qué hace que un proyecto sea interesante? Bueno, obviamente sería interesante trabajar en aplicaciones abiertamente atractivas como aviones furtivos o software de efectos especiales. Pero cualquier aplicación puede ser interesante si plantea desafíos técnicos novedosos. Por eso es difícil predecir qué problemas les gustarán a los hackers, porque algunos se vuelven interesantes solo cuando las personas que trabajan en ellos descubren un nuevo tipo de solución. Antes de ITA (que escribió el software dentro de Orbitz), las personas que trabajaban en búsquedas de tarifas aéreas probablemente pensaban que era una de las aplicaciones más aburridas imaginables. Pero ITA lo hizo interesante al redefinir el problema de una manera más ambiciosa.

Creo que en Google ocurrió lo mismo. Cuando se fundó Google, la opinión generalizada entre los llamados portales era que las búsquedas eran aburridas y carecían de importancia. Pero los chicos de Google no pensaban que las búsquedas fueran aburridas, y por eso lo hacen tan bien.

Este es un ámbito en el que los directivos pueden marcar la diferencia. Como un padre que le dice a su hijo: "Apuesto a que no puedes limpiar toda tu habitación en diez minutos", un buen directivo a veces puede redefinir un problema como algo más interesante. Steve Jobs parece ser especialmente bueno en esto, en parte simplemente por tener estándares elevados. Había muchos ordenadores pequeños y económicos antes del Mac. Jobs redefinió el problema como: haz uno que sea bonito. Y eso probablemente presionó a los desarrolladores más que cualquier incentivo o castigo.

Sin duda, cumplieron con su promesa. Cuando apareció el Mac por primera vez, ni siquiera hacía falta encenderlo para saber que funcionaba bien; se notaba en la carcasa. Hace unas semanas, estaba caminando por la calle en Cambridge y, en la basura de alguien, vi lo que parecía ser una funda de transporte para Mac. Miré dentro y había un Mac SE. Lo llevé a casa, lo enchufé y se encendió. La cara feliz de Macintosh y, a continuación, el Finder. Dios mío, era tan sencillo. Era como... Google.

A los hackers les gusta trabajar para gente con estándares altos, pero no basta con ser exigentes. Hay que insistir en las cosas correctas, lo que normalmente significa que uno mismo tiene que ser un hacker. He visto artículos ocasionales sobre cómo gestionar a los programadores. En realidad, debería haber dos artículos: uno sobre qué hacer si uno mismo es programador y otro sobre qué hacer si no lo es. Y el segundo probablemente se podría resumir en dos palabras: darse por vencido.

El problema no es tanto la gestión del día a día. Los hackers realmente buenos prácticamente se autogestionan. El problema es que, si no eres un hacker, no puedes saber quiénes son los buenos hackers. Un problema similar explica por qué los coches americanos son tan feos. Lo llamo la paradoja del diseño. Uno podría pensar que puede hacer que sus productos sean hermosos simplemente contratando a un gran diseñador para que los diseñe. Pero si uno mismo no tiene buen gusto , ¿cómo va a reconocer a un buen diseñador? Por definición, no se puede saber por su cartera de trabajos. Y no se puede guiar por los premios que ha ganado o los trabajos que ha tenido, porque en el diseño, como en la mayoría de los campos, estos tienden a estar impulsados por la moda y las relaciones sociales, y la capacidad real ocupa un distante tercer lugar. No hay forma de evitarlo: no se puede gestionar un proceso destinado a producir cosas hermosas sin saber qué es la belleza. Los coches americanos son feos porque las empresas automovilísticas americanas están dirigidas por gente con mal gusto.

En este país, mucha gente piensa que el gusto es algo elusivo o incluso frívolo. No es ninguna de las dos cosas. Para impulsar el diseño, un directivo debe ser el usuario más exigente de los productos de una empresa. Y si tiene un gusto realmente bueno, puede, como hace Steve Jobs, hacer que la satisfacción personal sea el tipo de problema en el que a la gente buena le gusta trabajar.

Pequeños y desagradables problemas

Es bastante fácil decir qué tipo de problemas no son interesantes: aquellos en los que, en lugar de resolver unos pocos problemas grandes y claros, hay que resolver muchos problemas pequeños y desagradables. Uno de los peores tipos de proyectos es escribir una interfaz para un software que está lleno de errores. Otro es cuando hay que personalizar algo para las necesidades complejas y poco definidas de un cliente individual. Para los hackers, este tipo de proyectos son la muerte de mil cortes.

La característica distintiva de los problemitas desagradables es que no se aprende nada de ellos. Escribir un compilador es interesante porque te enseña qué es un compilador. Pero escribir una interfaz para un programa lleno de errores no te enseña nada, porque los errores son aleatorios. [3] Así que no es sólo el fastidio lo que hace que los buenos hackers eviten los problemitas desagradables. Es más bien una cuestión de autoconservación. Trabajar en problemitas desagradables te vuelve estúpido. Los buenos hackers los evitan por la misma razón que los modelos evitan las hamburguesas con queso.

Por supuesto, algunos problemas tienen ese carácter intrínseco y, debido a la oferta y la demanda, pagan especialmente bien. Por lo tanto, una empresa que encontrara una manera de conseguir que grandes hackers trabajaran en problemas tediosos tendría mucho éxito. ¿Cómo lo haría usted?

Un ejemplo de ello es el de las empresas emergentes. En nuestra empresa, Robert Morris trabajaba como administrador de sistemas. Es como si los Rolling Stones tocaran en un bar mitzvah. No se puede contratar a ese tipo de talento, pero la gente hace cualquier tipo de trabajo pesado para las empresas de las que son fundadores. [4]

Las empresas más grandes resuelven el problema dividiendo la empresa. Contratan a gente inteligente para que trabaje en ellas estableciendo un departamento de I+D independiente en el que los empleados no tienen que trabajar directamente en los problemitas desagradables de los clientes. [5] En este modelo, el departamento de investigación funciona como una mina: produce nuevas ideas; tal vez el resto de la empresa pueda utilizarlas.

Tal vez no sea necesario llegar a ese extremo. La programación ascendente sugiere otra forma de dividir la empresa: hacer que la gente inteligente trabaje como fabricantes de herramientas. Si su empresa fabrica software para hacer x, tenga un grupo que construya herramientas para escribir software de ese tipo y otro que use esas herramientas para escribir las aplicaciones. De esta manera, podría lograr que gente inteligente escriba el 99% de su código, pero aún así mantenerlos casi tan aislados de los usuarios como lo estarían en un departamento de investigación tradicional. Los fabricantes de herramientas tendrían usuarios, pero solo serían los propios desarrolladores de la empresa. [6]

Si Microsoft utilizara este enfoque, su software no estaría tan lleno de agujeros de seguridad, porque las personas menos inteligentes que escriben las aplicaciones reales no estarían haciendo cosas de bajo nivel como asignar memoria. En lugar de escribir Word directamente en C, estarían conectando grandes bloques Lego del lenguaje Word. (Duplo, creo, es el término técnico).

Aglutinación

Además de los problemas interesantes, a los buenos hackers les gusta que haya otros buenos hackers. Los grandes hackers tienden a agruparse, a veces de forma espectacular, como en Xerox Parc. Por lo tanto, no atraerás a buenos hackers en proporción lineal a lo bueno que sea el entorno que crees para ellos. La tendencia a agruparse significa que es más como el cuadrado del entorno. Así que es el ganador se lo lleva todo. En un momento dado, sólo hay unos diez o veinte lugares donde los hackers más quieren trabajar, y si no eres uno de ellos, no sólo tendrás menos hackers buenos, sino que no tendrás ninguno.

Tener buenos hackers no es, por sí solo, suficiente para que una empresa tenga éxito. Funciona bien para Google e ITA, que son dos de los puntos calientes en este momento, pero no ayudó a Thinking Machines o Xerox. Sun tuvo una buena racha durante un tiempo, pero su modelo de negocio es un ascensor que va hacia abajo. En esa situación, ni siquiera los mejores hackers pueden salvarte.

Sin embargo, creo que, en igualdad de condiciones, una empresa que pueda atraer a grandes hackers tendrá una enorme ventaja. Hay gente que no estaría de acuerdo con esto. Cuando estábamos haciendo rondas de empresas de capital de riesgo en los años 90, varias nos dijeron que las empresas de software no ganaban escribiendo un gran software, sino a través de la marca, dominando los canales y haciendo los acuerdos adecuados.

Realmente parecían creerlo, y creo que sé por qué. Creo que lo que muchos inversores de capital riesgo buscan, al menos inconscientemente, es el próximo Microsoft. Y, por supuesto, si Microsoft es su modelo, no debería buscar empresas que esperan ganar escribiendo un gran software. Pero los inversores de capital riesgo se equivocan al buscar al próximo Microsoft, porque ninguna startup puede ser el próximo Microsoft a menos que otra empresa esté dispuesta a ceder en el momento justo y ser el próximo IBM.

Es un error utilizar a Microsoft como modelo, porque toda su cultura deriva de ese golpe de suerte. Microsoft es un mal punto de referencia. Si lo descartamos, nos daremos cuenta de que los buenos productos tienden a triunfar en el mercado. Lo que los inversores de capital riesgo deberían buscar es el próximo Apple o el próximo Google.

Creo que Bill Gates lo sabe. Lo que le preocupa de Google no es el poder de su marca, sino el hecho de que tienen mejores hackers. [7]

Reconocimiento

¿Quiénes son los grandes hackers? ¿Cómo saber cuándo te encuentras con uno? Resulta muy difícil. Ni siquiera los hackers pueden saberlo. Ahora estoy bastante seguro de que mi amigo Trevor Blackwell es un gran hacker. Es posible que hayas leído en Slashdot cómo hizo su propio Segway . Lo sorprendente de este proyecto fue que escribió todo el software en un día (en Python, por cierto).

Para Trevor, eso es normal. Pero cuando lo conocí, pensé que era un completo idiota. Estaba de pie en la oficina de Robert Morris parloteando sobre una cosa u otra, y recuerdo estar de pie detrás de él haciéndole gestos frenéticos a Robert para que echara a ese loco de su oficina para que pudiéramos ir a almorzar. Robert dice que al principio también juzgó mal a Trevor. Al parecer, cuando Robert lo conoció, Trevor acababa de empezar un nuevo plan que implicaba escribir todo sobre cada aspecto de su vida en una pila de fichas, que llevaba consigo a todas partes. También acababa de llegar de Canadá y tenía un fuerte acento canadiense y un corte de pelo estilo mullet.

El problema se agrava por el hecho de que los hackers, a pesar de su reputación de ignorantes en lo social, a veces se esfuerzan mucho en parecer inteligentes. Cuando estaba en la escuela de posgrado, solía pasar el rato en el laboratorio de inteligencia artificial del MIT de vez en cuando. Al principio, me intimidaba un poco. Todos allí hablaban muy rápido. Pero después de un tiempo aprendí el truco de hablar rápido. No tienes que pensar más rápido; solo usa el doble de palabras para decir todo.

Con esta cantidad de ruido en la señal, es difícil identificar a un buen hacker cuando uno se encuentra con él. Yo no puedo identificarlo, ni siquiera ahora. Tampoco se puede identificar por sus currículums. Parece que la única forma de juzgar a un hacker es trabajar con él en algo.

Y esa es la razón por la que los sectores de alta tecnología sólo surgen en torno a las universidades. El ingrediente activo aquí no son tanto los profesores como los estudiantes. Las empresas emergentes surgen en torno a las universidades porque las universidades reúnen a jóvenes prometedores y les hacen trabajar en los mismos proyectos. Los más inteligentes aprenden quiénes son los otros inteligentes y juntos idean nuevos proyectos propios.

Como no se puede reconocer a un gran hacker si no se trabaja con él, los propios hackers no pueden saber lo buenos que son. Esto es así hasta cierto punto en la mayoría de los campos. He descubierto que las personas que son excelentes en algo no están tan convencidas de su propia grandeza como desconcertadas por el hecho de que todos los demás parezcan tan incompetentes.

Pero para los hackers es especialmente difícil saber lo buenos que son, porque es difícil comparar su trabajo. Esto es más fácil en la mayoría de los demás campos. En los cien metros, sabes en 10 segundos quién es el más rápido. Incluso en matemáticas parece haber un consenso general sobre qué problemas son difíciles de resolver y qué constituye una buena solución. Pero hackear es como escribir. ¿Quién puede decir cuál de dos novelas es mejor? Sin duda, no los autores.

En el caso de los hackers, al menos, los demás hackers pueden darse cuenta. Esto se debe a que, a diferencia de los novelistas, los hackers colaboran en proyectos. Cuando logras resolver algunos problemas difíciles a través de la red, aprendes bastante rápido con qué fuerza responden. Pero los hackers no pueden observarse a sí mismos mientras trabajan. Por eso, si le preguntas a un gran hacker qué tan bueno es, es casi seguro que responderá: "No lo sé". No es solo modesto. En realidad, no lo sabe.

Y ninguno de nosotros lo sabe, excepto las personas con las que hemos trabajado. Lo que nos pone en una situación extraña: no sabemos quiénes deberían ser nuestros héroes. Los hackers que se hacen famosos tienden a hacerse famosos por accidentes aleatorios de relaciones públicas. De vez en cuando necesito dar un ejemplo de un gran hacker, y nunca sé a quién usar. Los primeros nombres que me vienen a la mente siempre tienden a ser personas que conozco personalmente, pero parece poco convincente usarlos. Así que creo que tal vez debería decir Richard Stallman, o Linus Torvalds, o Alan Kay, o alguien famoso por el estilo. Pero no tengo idea de si estos tipos son grandes hackers. Nunca he trabajado con ellos en nada.

Si existe un Michael Jordan del hacking, nadie lo sabe, incluido él.

Cultivo

Por último, la pregunta que todos los hackers se han estado haciendo: ¿cómo se llega a ser un gran hacker? No sé si es posible convertirse en uno, pero sí es posible hacer cosas que te hagan estúpido, y si puedes volverte estúpido, probablemente también puedas volverte inteligente.

La clave para ser un buen hacker puede ser trabajar en lo que te gusta. Cuando pienso en los grandes hackers que conozco, una cosa que tienen en común es la extrema dificultad de hacerlos trabajar en algo que no quieren. No sé si esto es causa o efecto; puede que sean ambas cosas.

Para hacer algo bien, hay que amarlo . Por lo tanto, en la medida en que puedas mantener la piratería como algo que amas, es probable que lo hagas bien. Intenta mantener la capacidad de asombro que tenías sobre la programación a los 14 años. Si te preocupa que tu trabajo actual esté pudriendo tu cerebro, probablemente así sea.

Los mejores hackers tienden a ser inteligentes, por supuesto, pero eso es cierto en muchos campos. ¿Existe alguna cualidad que sea exclusiva de los hackers? Pregunté a algunos amigos y la primera cosa que mencionaron fue la curiosidad. Siempre supuse que todas las personas inteligentes eran curiosas, que la curiosidad era simplemente la primera derivada del conocimiento. Pero aparentemente los hackers son particularmente curiosos, especialmente sobre cómo funcionan las cosas. Eso tiene sentido, porque los programas son, en efecto, descripciones gigantes de cómo funcionan las cosas.

Varios amigos mencionaron la capacidad de concentración de los hackers, su capacidad, como dijo uno de ellos, de "desconectarse de todo lo que ocurre fuera de sus propias cabezas". Yo ciertamente lo he notado. Y he oído a varios hackers decir que después de beber incluso media cerveza no pueden programar en absoluto. Así que tal vez hackear sí requiere una capacidad especial para concentrarse. Tal vez los grandes hackers puedan cargar una gran cantidad de contexto en su cabeza, de modo que cuando miran una línea de código, no ven sólo esa línea sino todo el programa que la rodea. John McPhee escribió que el éxito de Bill Bradley como jugador de baloncesto se debió en parte a su extraordinaria visión periférica. Una vista "perfecta" significa unos 47 grados de visión periférica vertical. Bill Bradley tenía 70; podía ver la canasta cuando miraba al suelo. Tal vez los grandes hackers tengan una capacidad innata similar. (Yo hago trampas utilizando un lenguaje muy denso , que encoge la cancha).

Esto podría explicar la desconexión en torno a los cubículos. Tal vez las personas a cargo de las instalaciones, al no tener ninguna capacidad de concentración que pueda afectar a su capacidad, no tienen idea de que para un hacker trabajar en un cubículo es como tener el cerebro en una licuadora (mientras que Bill, si los rumores sobre el autismo son ciertos, lo sabe muy bien).

Una diferencia que he notado entre los grandes hackers y la gente inteligente en general es que los hackers son más políticamente incorrectos . En la medida en que existe un apretón de manos secreto entre los buenos hackers, es cuando se conocen lo suficientemente bien como para expresar opiniones que harían que el público en general los apedreara hasta la muerte. Y puedo entender por qué la incorrección política sería una cualidad útil en la programación. Los programas son muy complejos y, al menos en manos de buenos programadores, muy fluidos. En tales situaciones es útil tener el hábito de cuestionar las suposiciones.

¿Se pueden cultivar estas cualidades? No lo sé, pero al menos no se pueden reprimir. Así que aquí va mi mejor intento de encontrar una receta. Si es posible convertirse en un gran hacker, la forma de hacerlo puede ser hacer el siguiente trato consigo mismo: nunca tendrá que trabajar en proyectos aburridos (a menos que su familia se muera de hambre de lo contrario) y, a cambio, nunca se permitirá hacer un trabajo a medias. Todos los grandes hackers que conozco parecen haber hecho ese trato, aunque tal vez ninguno de ellos haya tenido elección al respecto.

Notas

[1] Para ser justos, debo decir que IBM fabrica hardware decente. Escribí esto en una computadora portátil IBM.

[2] Resultó que estaban condenados al fracaso. Cerraron sus puertas unos meses después.

[3] Creo que esto es lo que la gente quiere decir cuando habla del "sentido de la vida". A primera vista, parece una idea extraña. La vida no es una expresión; ¿cómo podría tener sentido? Pero puede tener una cualidad que se parece mucho al sentido. En un proyecto como un compilador, hay que resolver muchos problemas, pero todos ellos siguen un patrón, como una señal. Mientras que cuando los problemas que hay que resolver son aleatorios, parecen ruido.

[4] Einstein trabajó en un momento diseñando refrigeradores (tenía acciones).

[5] Es difícil decir exactamente qué constituye una investigación en el mundo informático, pero como primera aproximación, es un software que no tiene usuarios.

No creo que sea la publicación lo que hace que los mejores hackers quieran trabajar en departamentos de investigación. Creo que es principalmente el hecho de no tener que reunirse durante tres horas con un gerente de producto sobre los problemas que presenta la integración de la versión coreana de Word 13.27 con el clip parlante.

[6] Algo similar viene sucediendo desde hace mucho tiempo en el sector de la construcción. Cuando se construía una casa hace un par de cientos de años, los constructores locales construían todo lo que había en ella. Pero cada vez más, lo que hacen los constructores es ensamblar componentes diseñados y fabricados por otra persona. Esto, al igual que la llegada de la autoedición, ha dado a la gente la libertad de experimentar de maneras desastrosas, pero sin duda es más eficiente.

[7] Google es mucho más peligroso para Microsoft que Netscape. Probablemente más peligroso que cualquier otra empresa. Y no sólo porque están decididos a luchar. En su página de ofertas de empleo, dicen que uno de sus "valores fundamentales" es "No seas malvado". Tratándose de una empresa que vende aceite de soja o equipos de minería, una declaración así sería simplemente excéntrica. Pero creo que todos los que estamos en el mundo de la informática reconocemos a quién se le está declarando la guerra.

Gracias a Jessica Livingston, Robert Morris y Sarah Harlin por leer versiones anteriores de esta charla.