Coders At Work, escrito por Peter Seibel y publicado el 16 de septiembre de 2009, es una colección de entrevistas con algunos de los programadores más destacados de esta generación. Las conversaciones son largas y profundas en cualquier tema, incluidos la depuración y las pruebas, y todas giran en torno al oficio de programar. El libro sería una buena serie de podcasts o un audiolibro, pero yo prefiero leerlo.
¿CÓMO NOS HA AYUDADO ESTE LIBRO?
Coders at work aumentó nuestros conocimientos tecnológicos. El libro proporciona información que abre nuevas oportunidades en nuestras carreras. Además, el libro nos ayudó a convertirnos en solucionadores de problemas. Codificadores en el trabajo nos proporcionó información que nos ayudó a comprender cómo abordar los problemas y utilizar las herramientas que nos rodean para desarrollar soluciones supremas.
EL LIBRO EXPLICADO EN MENOS DE 60 SEGUNDOS
El libro consta de entrevistas con algunos programadores muy consumados. Las partes principales de estas entrevistas incluyen cómo los entrevistados se iniciaron en la programación, sus lenguajes de programación favoritos y sus primeros programas, opiniones sobre las tendencias actuales en programación e información sobre su carrera profesional.
LAS TRES MEJORES CITAS
- «La legibilidad del código es ahora mi prioridad. Es más importante que ser rápido, casi tan importante como ser correcto. Aun así, ser legible es la forma más probable de que sea correcto».
- «Entró y meó en el baño de mi hotel sin ni siquiera cerrar la puerta, ya que yo estaba allí de pie. Le dije: «Muy bien. Estás cómodo». Nos conocíamos desde hacía cuatro o cinco años, aunque nunca nos habíamos visto».
- «Pero creo que si un programa está bien escrito, habrá algo en su estructura que me guiará a varias partes del mismo en un orden que tendrá algún tipo de sentido».
RESÚMENES Y NOTAS DE LIBROS
Capítulo uno Jamie Zawinski
Jamie Zawinski, propietario de un club nocturno, hacker de Lisp y uno de los primeros desarrolladores de Netscape, forma parte de un grupo de hackers conocidos por sus iniciales de tres letras como nombres completos. En 1998, contribuyó notablemente al desarrollo de mozilla.org y XEmacs. Cuando se le preguntó cómo aprendió a programar, en sus propias palabras, Zawinski respondió que la primera vez que utilizó un ordenador en circunstancias de codificación fue en octavo curso. No había ningún método para guardar los programas, así que los tecleábamos de las revistas. Además, leí muchos libros, supongo, sobre diversos lenguajes hasta el punto de que no tenía forma de escribir programas para lenguajes que sólo había estudiado. Trabajar en Lucid, una empresa que implementa software Lisp y crea un entorno de desarrollo, contribuyó a hacer de Zawinski un mejor programador. Argumenta que los desarrolladores deben ser conscientes del síndrome del segundo sistema. Nunca se le había ocurrido rediseñar un sistema. Zawinski aconseja a los jóvenes programadores que empiecen poco a poco y se centren más en el proceso que en los resultados. Esa fue la misma forma en que Fitzpatrick comenzó LiveJournal.
Cita favorita del capítulo: «A veces. Acabo haciendo toda la mierda de sysadmin, que no soporto; nunca me ha gustado. Disfruté trabajando en XScreenSaver porque, en cierto modo, los salvapantallas -los modos de visualización reales más que el marco de XScreenSaver- son el programa perfecto porque casi siempre empiezan de cero, y hacen algo bonito, y nunca hay una versión 2.0. Es muy raro que haya un fallo en un salvapantallas. Se cuelga-oh, hay una división por cero, y lo arreglas».
Capítulo dos: Brad Fitzpatrick
Brad Fitzpatrick es el más joven de los entrevistados y la única persona. No puede vivir sin Internet ni los ordenadores personales. Tras ver a su padre construir un Apple II desde cero, Brad se aficionó a la programación, jugando con las piezas de hardware y leyendo libros. Al igual que Zawinski, Brad también empezó con BASIC. No podía hacer nada con un ratón ni con modos gráficos y colores superiores. Fue hasta que uno de los amigos de la familia de Brad le presentó C y le regaló Turbo C. Brad también trasteó con la programación en ensamblador en calculadoras como Z80 en la calculadora IT. El interés de Brad por Perl comenzó cuando se dedicó a los CGI e imprimió una o dos líneas en el navegador Netscape Navigator. Brad no asistió a ninguna clase de programación. Se trataba de uno o dos libros de la biblioteca. Su universidad era una combinación de correr y LiveJournal, lo que hacía la escuela soportable.
Cita favorita del capítulo: «Cuando trabajaba con Perl -incluso para personas que conocían Perl realmente bien- recomendaría Higher-Order Per de MJD. El libro es entretenido en el sentido de que empieza de forma algo simple, y te quedas como, sí, sí, sé lo que es un cierre. Y luego sigue jodiéndote la cabeza. Al final del libro, te quedas alucinado».
Capítulo tres: Douglas Crockford
Douglas Crockford fue en su día arquitecto senior de javascript en Yahoo. Anteriormente, trabajó para Lucasfilm, Atari y Electric Communities. Crockford fue a la Universidad de San Francisco y asistió a una clase de Fortran en el departamento de matemáticas, donde aprendió a programar. Crockford sostiene que con las mejoras en la CPU y la memoria o el hardware en general, los desarrolladores ya no se preocupan por la eficiencia como lo hacían en el pasado. Según el entrevistado, parte de lo que hace difícil la programación es que la mayor parte del tiempo los programadores hacen cosas que antes no hacían. Habla de su método favorito para entrevistar a los candidatos a un puesto de trabajo. Cita al candidato para que lleve un trozo de código que haya hecho y nos guíe a través de él. Crockford también piensa que la única forma de mejorar Javascript sería hacerlo más pequeño si pudiéramos eliminar todas las características que no le dan valor y mantener sólo lo que importa. Dice que este enfoque puede aplicarse a HTML, HTTP y CSS. Los desarrolladores deberían averiguar qué es lo que mejor hacen los lenguajes y centrarse en ello en lugar de amontonar nuevas actualizaciones. Cuando se le pidió un consejo para un próximo programador, Crockford respondió que deberían centrarse más en la comunicación. Deberían aprender a leer y escribir.
Cita favorita del capítulo: «En general, nos ha ido bastante bien. Creo que el mundo es un lugar mejor, aunque no siempre avanza. Si nos fijamos en las políticas internacionales de los últimos diez años, la consolidación de los grandes medios de comunicación y la corrupción de efectos que no han sido compensados por la red abierta. Es una gran decepción. Cientos de miles de personas han muerto como consecuencia directa de ello».
Capítulo cuatro: Brendan Eich
Brendan Eich, CTO de la Corporación Mozilla, filial de la Fundación Mozilla, es responsable del desarrollo continuo del navegador Firefox y creador de Javascript, el lenguaje de programación más utilizado en la web. Brendan estudió física en Santa Clara, donde aprendió a programar. Brendan dice que le interesaban Unix y C, pero que sólo estaban empezando con la vieja plancha DEC. Tenía un compilador portátil de C y estaba empezando a crear código y a trastear con la portación de utilidades de Unix. Según la observación de Brendan, cada vez más gente escribía código con más abstracciones de alto nivel que antes. Si se ejecutan aplicaciones repartidas en servidores por todo el mundo, el antiguo enfoque no funcionará. Brendan también habla de cómo trabajó en el código del núcleo y de las redes en SCI. El tamaño del fondo de lenguaje que utilizaba creció con el tiempo porque escribió su capa de gestión de red y de detección de paquetes. Además de leer código, Eich también lee libros sobre programación. Dice que le encantaban los libros de Brian Kernighan y que los consideraba geniales. A Eich también le encantaban los volúmenes 1 a 3 de El arte de la programación informática de Knuth.
Cita favorita del capítulo: «[Assenbly level programming] sigue separando a los programadores de pelo en pecho de los que no lo tienen del todo».
Capítulo cinco: Joshua Bloch
Joshua Bloch es el actual arquitecto jefe de Java en Google y antiguo ingeniero en Sun Microsystems. Fue el precursor del diseño y la implementación del marco de colecciones de Java iniciado en Java 2. Joshua aprendió a programar, especialmente Fortran, de su padre mientras estudiaba un curso de programación hacia 1971. En 1977, Joshua escribió una versión de los juegos de las veinte preguntas conocida como «Animales». Éste fue el primer programa emocionante que escribió. Joshua insiste en que los desarrolladores deben leer libros a menudo, como Design Patterns, con un vocabulario común, buenas ideas y un batiburrillo de estilos y lenguajes. Otro libro es Elements of Style, no es un libro de programación, pero debería leerlo por dos razones. En primer lugar, mejora su estilo de prosa; en segundo lugar, todos los conceptos del libro se aplican a los programas. Joshua sostiene que la necesidad de matemáticas es mucho más considerable en una comunidad que escribe compiladores, bibliotecas y marcos de trabajo. Cuando se escriben aplicaciones web sobre marcos de trabajo, hay que entender la comunicación visual y verbal. En opinión de Joshua, los programadores inteligentes suelen escribir el peor código. A los programadores inteligentes les cabe todo en la cabeza y lo entienden. Y como pueden entenderlo, creen que es adecuado para su utilización.
Cita favorita del capítulo: «Todos somos optimistas en nuestra profesión, o nos veríamos obligados a pegarnos un tiro».
Capítulo seis: Joe Armstrong
Joe es el creador de Erlang y de la Open Telecom Platform, un marco para crear aplicaciones Erlang. Joe estudiaba física, y como estudiante universitario, algunos cursos implicaban crear programas, y le encantaba. Llegó a ser muy bueno depurando, y la paga estándar por depurar era una cerveza en ese momento. Joe suele pasar mucho tiempo pensando antes de ponerse a codificar. Sin embargo, durante este periodo, también toma notas. Según Joe Armstrong, los widgets actuales no le hacen más productivo. Eche un vistazo a los sistemas de archivos jerárquicos. ¿Cómo nivelan su productividad? No lo hacen porque casi todo el desarrollo del software ocurre en su cabeza. Trabajar con un sistema sin esfuerzo impone una cierta forma disciplinada de pensar. Necesitará disciplina si no tiene un sistema de directorios y tiene que colocar todos los archivos en un único directorio. Si puede aplicar el mismo campo a lo que está haciendo, no habrá necesidad de sistemas de archivos jerárquicos. Los sistemas de archivos jerárquicos, diez a uno, facilitan el trabajo conjunto de los grupos. Armstrong cree que lo que hace a un buen programador es su elección de los problemas. ¿Se dejan llevar por las soluciones o por las respuestas? Además, aconseja a los jóvenes programadores que intenten aprender varios lenguajes, ya que mejora sus habilidades, su flexibilidad y sus conocimientos sobre otros lenguajes.
Cita favorita del capítulo: «Creo que la falta de reutilización se da en los lenguajes orientados a objetos, no en los funcionales. Porque el problema con los lenguajes orientados a objetos es que tienen todo este entorno implícito que llevan consigo. Querías un plátano pero tienes un gorila sujetando el plátano y toda la jungla».
Capítulo siete: Simon Peyton Jones
En 1987, fue uno de los artífices de un proyecto que abrió el camino a la resolución del lenguaje de programación Haskell. Simon Peyton es investigador principal en el laboratorio Microsoft Research de Cambridge. Cuando se le pregunta por la correlación entre programación e investigación, Simon responde que esos aspectos interactúan ampliamente. Los lenguajes de programación facilitan la programación. Actúan como la interfaz de usuario de la programación. Por lo tanto, la investigación en lenguajes de programación y la programación están inconmensurablemente relacionadas. Simon habló de las pruebas de las API en Microsoft. Hacen un gran trabajo probando APIs. Ante una nueva API, Steven Clarke y su equipo se esfuerzan por observar a los programadores hablar sobre lo que intentan hacer. Y consiguen que las personas que crearon la API observen desde una pantalla de cristal. Peyton disfruta programando cuando intenta escribir un programa con integridad intelectual. Añade que se puede seguir echando barro a un programa y funcionará durante bastante tiempo, pero no será satisfactorio. Por lo tanto, uno de los buenos atributos de un buen programador es que siempre debe intentar generar soluciones conmovedoras incluso en situaciones técnicas.
Cita favorita del capítulo: «A veces, decir que es obviamente correcto no significa que pueda ver que es correcto sin ningún andamiaje mental. Puede ser que necesite que le digan algo para darse cuenta de por qué es correcto».
Capítulo ocho: Peter Norvig
Peter Norvig es un pensador integrador y hacker de corazón. Una vez diseñó un programa para detectar una serie de tres búsquedas realizadas por el mismo usuario en los registros de búsqueda de Google. Peter aprendió a programar en el instituto, la escuela tenía un doctorado -8-, y tomó una clase que empezaba con programación BASIC. El primer código interesante que escribió Peter fue el Juego de la Vida. Dice que fue un ejercicio de clase que hizo rápidamente. Peter trabajó para una empresa de software en Cambridge. Su producto era un conjunto de herramientas de diseño de software y varios tipos de consultoría de software. Uno de los proyectos de la empresa era crear un dibujante de diagramas de flujo que analizara su programa y generara un diagrama de flujo para él. Peter hizo hincapié en que los desarrolladores deben tener otras habilidades además de escribir código. Habilidades como la comprensión de las necesidades de los clientes, la comunicación y la resolución de problemas. Según Peter, la programación se ha convertido en una actividad más social de lo que solía ser. Los ordenadores de entonces solían estar más segregados y se trataba más de procesamiento por lotes, por lo que la interfaz era un poco más sencilla. Peter Norvig no ve con buenos ojos el planteamiento de Google de hacer preguntas enigmáticas en las entrevistas. Prefiere que se ponga a los entrevistados en una situación técnica a limitarse a charlar para hacerse una idea de que son el tipo adecuado.
Cita favorita del capítulo: «Creo que una de las cosas más importantes es ser capaz de tenerlo todo en la cabeza a la vez. Tiene muchas más posibilidades de éxito si puede hacerlo. Eso facilita un programa pequeño. Para un programa más extenso, necesita herramientas adicionales para poder manejarlo».
Capítulo nueve: Guy Steele
Cuando se le preguntó qué lenguajes había utilizado, Guy Steele, propiamente políglota de la programación. Generó esta lista Fortran, COBOL, IBM, lenguaje de máquina PDP-10, APL, C, C++, BLISS, Haskell, FOCAL, TEGO y TeX. «Ésos son los principales, supongo», añadió. Guy se inició en la programación a través de un amigo del colegio que consiguió fascinar a Guy con unas pocas líneas del programa Fortran. Después de estudiar Fortran, Guy siguió adelante y aprendió el lenguaje ensamblador IBM 1130. Su primer programa emocionante creaba índices de palabras clave en contexto. Además, IBM ofrecía índices rápidos para sus manuales que, cuando te daban un teclado, lo buscabas en los índices. Estaba ordenado alfabéticamente en función del teclado, pero a ambos lados del teclado, verías diferentes palabras del contexto que rodeaba a esa palabra. Steele se ocupaba de varias máquinas del campus, como el DEC PDP-10. En aquella época, Harvard poseía un PDP-10 para los trabajos de posgrado. Los estudiantes universitarios sólo utilizaban los terminales de teletipo de un sistema comercial que la escuela alquilaba. Steele también declaró algunos de los libros esenciales que leyó y que nivelaron sus conocimientos de programación, entre ellos Knuth y The Art of Computer Programming. Además, Guy Steele sostiene que los jóvenes programadores no utilizan sus pulgares cuando intentan contar. Por otro lado, ha habido avances sustanciales desde la lucha con la incompatibilidad de la base-diez con dos potencias.
Cita favorita del capítulo: «Así que supongo que hay lecciones ahí: la lección que debería haber sacado es que puede haber más de un fallo aquí, y que debería haber buscado más la primera vez. Pero otra lección es que si se cree que un fallo es poco frecuente, buscar en las rutas ejecutadas raramente puede ser fructífero. Y la tercera es que tener una buena documentación sobre lo que el algoritmo intenta hacer, es decir, una referencia a Knuth, fue increíble.»
Capítulo diez: Dan Ingalls
Dan Ingalls, uno de los cofundadores de Smalltalk. Inició la primera promulgación de Smalltalk, escrita en BASIC. Participó en la implementación de siete generaciones de Smalltalk, desde el prototipo hasta el actual implemental de código abierto, Squeak. Dan creció como inventor y se especializó en física en la universidad. Hizo un curso de programación en Fortran en Harvard. Ingalls puso en marcha un programa que después hizo un negocio. Su propósito era evaluar programas y observar su comportamiento dinámico, en términos sencillos, la creación de perfiles. Había un programa que perfilaba un programa Fortran y colocaba contadores en cada punto de bifurcación. Dan creó una versión mejor del programa que tenía un proceso de interrupción por temporizador, de modo que rastrearía cuánto tiempo real se gastaba en las distintas partes del programa. Dan sigue disfrutando de la programación como cuando empezaba. Dice que los dos últimos años han sido interesantes desde que pasó de un entorno familiar -Smalltalk- a Squeak, donde las herramientas eran estupendas. Dan aconseja a los desarrolladores noveles que aprendan varios lenguajes con diferentes puntos fuertes. Añade que merece la pena que los desarrolladores tomen varios entornos informáticos diferentes y encuentren un problema que resolver.
Cita favorita del capítulo: «Diferentes personas tienen diferentes niveles a los que necesitan llegar para sentirse bien con lo que están trabajando. Así que creo que alguien puede sentirse totalmente seguro quizá utilizando una biblioteca de colecciones sin haberla programado él mismo.»
CÓMO PUEDE AYUDAR ESTE LIBRO A LOS DESARROLLADORES DE SOFTWARE
«Coders at Work» es una colección de entrevistas realizadas por Peter Seibel a algunos de los programadores con más éxito y experiencia de nuestro tiempo. Estos codificadores comparten en el libro sus ideas, experiencias y sabiduría sobre el desarrollo de software. La lectura de este libro puede ayudar a los desarrolladores de software a comprender mejor el sector, aprender de las experiencias de programadores de éxito y desarrollar sus habilidades y perspectivas. El libro puede inspirar a los desarrolladores a pensar de forma creativa y a retarse a sí mismos para convertirse en mejores codificadores.
