Ser Programador Después De Los 40

Esta es la charla que dí en App Builders Switzerland el 25 de abril de 2016.

Los slides están en SpeakerDeck y al final de este artículo. El video de la presentación (en inglés) está en YouTube.

Gracias a una comunidad formidable, este artículo fue traducido a varios otros idiomas:

Original in English. J’ai aussi publié une traduction au français.


Hola, soy un desarrollador autodidacta de cuarenta y dos años, y esta es mi historia.

Hace algunas semanas me crucé con el tweet aquí debajo, y me hizo pensar sobre mi carrera, y estos pensamientos me llevaron al lugar donde todo comenzó para mí:

Original: http://www.smbc-comics.com/index.php?db=comics&id=2436

Comencé mi carrera como desarrollador de software precisamente a las 10 de la mañana, el lunes 6 de octubre de 1997, en algún lugar de la ciudad de Olivos, al norte de Buenos Aires, Argentina. El momento era Unix Epoch 876142800. Había celebrado recientemente mi vigésimo cuarto cumpleaños.

El Mundo En 1997

El mundo era un lugar ligeramente distinto en aquel entonces.

Los websites no tenian warnings para cookies. El futuro de la web eran portales como Excite.com. Mi motor de búsqueda preferido era AltaVista. Mi e-mail era kosmacze@sc2a.unige.ch , lo cual indicaba que mi primer website se encontraba en http://sc2a.unige.ch/~kosmacze. Estábamos aún llorando la muerte de la Princesa Diana. Steve Jobs había aceptado el rol de CEO y había convencido a Microsoft de inyectar 150 millones de dólares en Apple Computer. Digital Equipment le estaba haciendo juicio a Dell. Los restos del Che Guevara acababan de ser inhumados en Cuba. La cuarta temporada de “Friends” había comenzado. Habían matado a Gianni Versace delante de su casa. Habían fallecido recientemente la Madre Teresa de Calcuta, Roy Lichtenstein y Jeanne Calment (la mujer más anciana del mundo). La gente estaba jugando desenfrenadamente a Final Fantasy 7 en su PlayStation. La BBC 2 había empezado a transmitir los Teletubbies. James Cameron estaba a punto de presentar Titanic. The Verve sacó su éxito “Bitter Sweet Symphony” y enseguida tuvo que empezar a pagarle regalías a los Rolling Stones.

Excite en 1997, cortesía del Internet Archive

Los smartphones se parecían al Nokia 9000 Communicator; tenían 8 MB de memoria, un procesador i386 de 24 MHz y funcionaban con el sistema operativo GEOS.

Los smartwatches se parecían al CASIO G-SHOCK DW-9100BJ. No tenían tantas aplicaciones como ahora pero la batería duraba años.

IBM Deep Blue había ganado una partida de ajedrez por primera vez frente a Garry Kasparov.

Un hacker conocido como “_eci” publicó el código en C para un ataque informático llamado “WinNuke”, dirigido a Windows 3.1, 95 y NT. Era un ataque de negación de servicio que apuntaba al puerto 139 (NetBIOS) lo cual causaba una de esas “pantallas azules de la muerte” en el sistema atacado.

Anecdóticamente, en 1997 nacieron Malala Yousafzai, Chloë Grace Moretz y Kylie Jenner.

Varias películas suceden en 1997, por ejemplo: Escape de Nueva York, Predator 2, El Curioso Caso de Benjamin Button, Harry Potter y El Misterio del Príncipe, El Padrino 3, y según Terminator 2: El Juicio Final, Skynet se volvió consciente a las 2:14 de la mañana del 29 de agosto de 1997. Obviamente eso no sucedió, pero extrañamente el dominio google.com fue registrado el 15 de setiembre de ese año.

Estábamos a dos años de Y2K y los medios de comunicación estaban empezando a poner nerviosa a la gente.

Mi Primer Trabajo De Desarrollador

Consistió en escribir páginas ASP en varios editores, como Microsoft FrontPage, HotMeTaL Pro o EditPlus, haciéndome cargo de la compatibilidad entre Netscape Navigator e Internet Explorer 4, y en escribir procedimientos almacenados en SQL Server 6.5 para darle vida a un sitio web comercial publicado en japonés, ruso, inglés y castellano — sin ninguna consistencia en el soporte de UTF-8 de estas herramientas.

El producto de estos esfuerzos funcionaba en un servidor hosteado en algún lugar de los EEUU, con una CPU Pentium II, un extraordinario disco duro de 2 GB y asombrosos 256 MB de RAM. Era un solo servidor, con Windows NT 4, SQL Server 6.5 e IIS 2.0, que soportaba unas diez mil visitas por día.

Mi primer lenguaje de programación profesional fue este engendro mutante llamado VBScript, obviamente adornado con algo de JavaScript del lado del cliente, salpicado con un montón de “si es Netscape haz esto, de otro modo haz aquello” porque en aquella época no tenía mucha idea de cómo usar JavaScript correctamente.

Irónicamente, estamos en 2016 y recién estamos apenas empezando a entender como hacer algo correctamente en JavaScript.

No se conocían los test unitarios. No se había publicado aún el Manifiesto por el Desarrollo Ágil de Software. La integración contínua era un sueño. XML no era ni siquiera un acrónimo de moda. Nuestra estrategia de control de calidad consistía en resetear el servidor una vez por semana, porque de otra manera se caía de manera aleatoria. Desarrollamos nuestro propio componente COM+ en Visual J++ para analizar los archivos JPEG que subían nuestros usuarios al servidor. Apenas aparecieron los primeros archivos en formato JPEG 2000 este componente empezó tristemente a fallar.

No usábamos ningún sistema de control de versiones, ni siquiera CVS, RCS o — Dios nos proteja — SourceSafe. Subversion no existía aún. Nuestra puntuación en el Joel Test era algo así como menos 25.

6776 Días

En estos 6776 días me levanté cada mañana, me serví una taza de café y luego escribí código con cosas llamadas VBScript, JavaScript, Linux, SQL, HTML, Makefiles, Node.js, CSS, XML, .NET, YAML, Podfiles, JSON, Markdown, PHP, Windows, Doxygen, C#, Visual Basic, Visual Basic.NET, Java, Socket.io, Ruby, tests unitarios, Python, shell scripts, C++, Objective-C, archivos batch, y últimamente Swift.

En esos 6776 días pasaron muchísimas cosas; lo más importante fue que conocí a mi mujer y me casé. Dejé seis trabajos y me echaron en dos ocasiones. Arranqué y cerré mi propio negocio. Terminé una maestría. Publiqué algunos proyectos open source, uno de los cuales apareció en un artículo de Ars Technica, escrito por nadie más ni nadie menos que Erica Sadun. Aparecí en la televisión en Suiza y en Bolivia. Presencié en persona presentaciones por Bill Gates y Steve Jobs, en Seattle y San Francisco respectivamente. Hablé y organicé conferencias en cuatro continentes. Escribí y publiqué dos libros. Tuve dos episodios de “burnout” y pasaron muchas, muchas otras cosas, algunas hermosas y otras horribles.

Muchas veces me pregunté a mí mismo si dejaría de ser desarrollador del todo. Pero de alguna manera, el código siempre me vuelve a llamar después de un tiempo. Me gusta escribir aplicaciones, sistemas, software. Para evitar el “burnout” tuve que inventar algunas estrategias.

En esta charla les voy a dar algunos secretos, para que ustedes también puedan alcanzar la edad gloriosa de los cuarenta como un desarrollador experimentado, y con ganas de seguir en esta profesión.

Aviso Para Los Jóvenes De Corazón

He aquí un par de ideas para llegar a los gloriosos cuarenta como un desarrollador feliz.

1. Olvídense De Las Tendencias

El primer consejo que puedo darles es que se olvíden de las tendencias. Cada año hay algo nuevo en nuestra profesión: un lenguaje de programación, un framework, una librería, un patrón de diseño, una arquitectura de componentes o cualquier paradigma que toma por asalto la prensa y los blogs. La gente se vuelve loca. Se organizan conferencias sobre el tema. Se escriben libros. Suben y bajan los ciclos de Gartner. Consultores cobran fortunas para enseñar, poner en producción o arruinar la vida de los trabajadores de nuestra industria. La prensa nos presiona continuamente y nos hace sentir culpables si no les prestamos atención.

En 1997 fue CORBA y RUP.

En 2000 fue SOAP y XML.

En 2003 fue Arquitectura Dirigida Por Modelos y Fábricas de Software.

En 2006 fue Web Semántica y OLPC.

En 2009 fue Realidad Aumentada.

En 2012 fue Big Data.

Y ahora es… Realidad Virtual? Bots?

No se preocupen por las nuevas tendencias. Sigan haciendo lo que hacen, sigan aprendiendo lo que estaban aprendiendo, y dejen que las aguas sigan su rumbo. Préstenle atención a estas nuevas tendencias solamente si tienen un interés genuino, o si sienten que les podrían traer algún beneficio en el medio o largo plazo.

La razón de esto estriba en el hecho que, como decían los romanos en el pasado, nihil sub sole novum. La mayor parte de lo que se ve y se aprende en computación ha existido durante décadas, y este simple hecho se oculta detrás de pilas de marketing, libros, blogs y preguntas en Stack Overflow. Cada “nueva” arquitectura es simplemente una reescritura y una readaptación de ideas que han estado dando vueltas durante décadas.

2. Elijan Sabiamente Su Galaxia

En nuestra industria, cada tecnología genera a su alrededor lo que llamo una “galaxia”. Estas galaxias tienen tanto estrellas como agujeros negros; cambios meteóricos que desaparecen en la negrura, muchos planetas, solamente una ínfima fracción de los cuales tiene algún tipo de vida, y una enorme cantidad de polvo cósmico y materia oscura.

Ejemplos de galaxias son .NET, Cocoa, Node.js, PHP, Emacs, SAP, etc. Cada una de ellas contiene evangelistas, desarrolladores, blogueros, podcasts, conferencias, libros, cursos de entrenamiento, servicios de consultoría y problemas de inclusión social. Las galaxias se construyen alrededor de la idea de que la tecnología en su centro es la solución única de todos los problemas. Cada galaxia, por lo tanto, está basada en falsas premisas.

Los desarrolladores de estas diferentes galaxias representan en cuerpo y alma las actitudes típicas que han dado origen a esa tecnología. Adhieren a las ideas, y visten con entusiasmo las remeras y difunden los méritos de su elección a otros.

En realidad, uso el vocablo “galaxia” para evitar el más apropiado, sino más controvertido término “religión”, que describe este fenómeno mucho más correctamente.

En mi caso personal, pasé los primeros diez años de mi carrera en la galaxia Microsoft, y luego los siguientes nueve en la galaxia Apple.

Me atrevo a decir que la razón principal por la cual cambié de galaxia fue Steve Ballmer. Me cansé de la retórica y la actitud de la gente en la galaxia Microsoft, particularmente en contra del software open source.

Por el otro lado, debo admitir que la galaxia Apple es un lugar fantástico, lleno de artistas y músicos y escritores que, por buena o mala suerte, también escriben código.

Participé en conferencias en la galaxia Microsoft, como el TechEd en Barcelona en 2003, o varios Tech Talks en Buenos Aires, Ginebra y Londres. Incluso hablé en los Microsoft DevDays 2006 en Ginebra. La actitud general de los programadores en la galaxia Microsoft es hostil, “empresarial” y regida por secretos, acuerdos de no divulgación y procesos IT complicadísimos.

La galaxia Apple fue para mi, en 2006, como un baldazo de aire fresco; un lugar repleto de músicos, artistas, pintores; escribían código para ayudarse en su pasión, y escribían código con pasión. Eso hacía toda la diferencia, y hasta hoy, aún disfruto muchísimo esta galaxia, ésta en la que nos encontramos hoy, en este momento, y que nos ha juntado.

Y luego salió el iPhone, y el resto es historia.

Entonces mi recomendación es: elijan su galaxia sabiamente, disfrútenla cuanto mucho o poco deseen, pero siempre mantengan el telescopio apuntado hacia otras galaxias, y estén siempre listos para realizar un salto en el hiperespacio hacia otro lado si fuese menester.

3. Aprendan Sobre La Historia Del Software

Esto me lleva al punto siguiente: aprendan bien la historia de su tecnología favorita. ¿Les gusta C#? ¿Saben quien lo ha creado? ¿Como fue que nació el proyecto .NET? ¿Quién fue el arquitecto? ¿Cuáles fueron las limitaciones del proyecto, y por qué el lenguaje resultó ser lo que es ahora?

Apliquen la misma receta a cualquier lenguaje o arquitectura de CPU que les guste: Python, Ruby, Java, cualquier lenguaje de programación. Lo mismo para sistemas operativos, tecnologías de red, hardware, lo que sea. Vayan y aprendan como aparecieron, como se les ocurrió a sus creadores, y cuanto tiempo les tomó crecer y madurar. Porque el buen software requiere diez años, ¿saben?

Las historias alrededor del origen de nuestra industria son fascinantes, y les van a enseñar dos cosas: primero, que todo es un remix. Segundo, que ustedes podrían estar remixeando próximamente. No, perdón, no es así: ustedes van a ser los creadores de la próxima tendencia.

Y para ayudarles en esa tarea, esta es mi lista de libros de historia del software que me gustan y les recomiendo:

De esta manera, ustedes tambien aprenderán a darle valor a aquellas tecnologías que han pasado la prueba del tiempo: Lisp, TeX, Unix, bash, C, Cocoa, Emacs, Vim, Python, ARM, GNU make, man pages. Estos son algunos ejemplos de cosas que han durado durante largo rato y que son algo para celebrar, protejer y aprender.

4. Sigan Aprendiendo

Aprendan. Todo vale. ¿Quieren aprender Fortran? Pues a por él. ¿Les parece que Erlang es interesante? Excelente. ¿Les parece que COBOL va a ser importante en el futuro de sus carreras? Fantástico. ¿Necesitan saber algo más a propósito de Functional Reactive Programming? Adelante. ¿Diseño? Claro que sí. ¿UX? Debes saberlo. ¿Poesía? Deberías.

Muchos conceptos en computación han estado dando vuelta durante décadas, lo cual hace muy importante el aprender viejos lenguajes de programación y frameworks; incluso aquellos que han caído en desuso. Primero, les hará apreciar el estado actual de la industria (u odiarlo, depende), y segundo, aprenderán a usar las herramientas modernas de manera más efectiva, siquiera porque habrán comprendido su herencia y su origen.

Truco 1: aprendan al menos un lenguaje de programación nuevo cada año. Esta idea no es mía; sale del libro The Pragmatic Programmers. Y funciona.

Un lenguaje de programación cada año. ¿Parece simple, no? Vayan más allá del típico “Hello, World” y construyan algo más o menos útil con él. Por ejemplo, usualmente lo que yo hago es simplemente construir una calculadora con cada nueva tecnología que aprendo. Me permite darme cuenta de la sintaxis, me familiariza con las APIs o los editores, etc.

Truco 2: lean al menos seis libros por año. Más arriba les mostré una lista de seis libros; eso los debería mantener ocupados durante un año. Aquí va la lista para el segundo año:

(Si, lo sé, son siete libros).

Seis libros al año puede sonar exagerado, pero en realidad es sólo un libro cada dos meses. Y la mayoría de los libros que he mencionado en esta presentación no son muy largos, y mejor aún, están extraordinariamente bien escritos, son divertidos y están llenos de sabiduría.

Mírenlo de esta manera: si ahora tienen 20 años, para cuando tengan 30 habrán leído más de 60 libros, y unos 120 para cuando lleguen a mi edad. Y habrán tenido experiencia directa con al menos 20 lenguajes de programación distintos. Piensen en ello durante un momento.

Algunos de los doce libros que seleccioné fueron escritos en los setenta, otros en los ochenta, algunos en los noventa y finalmente la gran mayoría son de la última década. Representan lo que considero que es lo mejor que se ha escrito a propósito de nuestra industria.

Pero no los lean simplemente; tomen notas. Marquen las páginas. Escriban en los bordes. Y luego reléanlos. Borges alguna vez dijo que un placer mayor que leer un libro es releerlo. Ah, y además, cómprenlos en papel. Créanme. Lo de los libros electrónicos no es para tanto. Nada le gana a un libro de papel.

Pero debo advertirles algo: a medida que envejezcan, la cantidad de cosas que les parecerán nuevas o importantes disminuirá dramáticamente. Prepárense. Pueden llorar un poco cuando se den cuenta de esto.

5. Enseñen

Una vez que han aprendido, enseñen. Esto es muy importante.

Esto no quiere decir que renten un aula y se pongan a dar cursos (¡aunque sería fantástico que así fuese!) Simplemente significa que den buenas respuestas a preguntas en Stack Overflow; que escriban un libro; que publiquen un podcast sobre su tecnología favorita; que mantengan un blog; que escriban en Medium; que vayan a otro continente y funden escuelas de programación usando Raspberry Pis; o que ayuden a un programador más joven siendo su mentor (pero sin embargo no hagan esto antes de los 30).

Enseñar los hará mas humildes, porque les mostrará de manera ruda y dolorosa cuán limitado es vuestro conocimiento. Enseñar es la mejor manera de aprender. Solo podrán ustedes aprender correctamente poniendo su conocimiento a prueba frente a otros. Esto los hará también mas respetuosos con respecto a otros programadores y tecnologías; cada lenguaje, sin importar cuán humilde o misterioso, tiene tu lugar en el Tao de la Programación, y solamente mediante la enseñanza podrán ustedes sentir esto.

Y además, enseñando podrán realmente hacer que las cosas sean diferentes. En 2012 recibí un e-mail de una persona que había participado a uno de mis cursos. Ella había trabajado durante años como programadora Adobe Flash. Se acuerdan de ActionScript? Bueno, de manera no muy sorprendiente, esta persona se encontró completamente desocupada después de 12 años de trabajo como programadora freelance Flash. Sola. Con un bebé en los brazos. Me dijo ella, en su mensaje, que durante mi curso lo había pasado muy bien y que había aprendido algo útil, y que luego de ello encontró trabajo como programadora web móvil. Me escribió para decirme gracias.

No puedo decir que cambié el mundo, pero quizás lo empujé un poquito en otra dirección, que quizás (espero) sea mejor. Este pensamiento ha hecho que cada lección que dí desde ese día tenga un sentido mucho más profundo y duradero.

6. Las Oficinas Apestan

No esperen que las empresas de software les ofrezcan el mas mínimo camino de crecimiento. Quizás lo hagan en los EEUU, pero no he visto nada similar en Europa. Esto significa que ustedes son los únicos responsables por el éxito de vuestras carreras. Nadie les dirá “bueno, este año podrías ser líder del equipo, y luego el gerente, más tarde el CTO…”

Para. Nada. En realidad, más bien lo contrario; ustedes fueron, son y serán desarrolladores, esto es, un obrero de fábrica relativamente caro, de quien sus gerentes estarían más que contentos de tercerizar los servicios, sin importar lo que les digan.

No tomen un trabajo solamente por el dinero que les ofrezcan. Las empresas de software se han vuelto verdaderos talleres de trabajo esclavo, donde se espera de ustedes que justifiquen los salarios absurdamente altos que se les pagan con impensables horas de trabajo y expectativas absolutamente irracionales. Y, al menos en el caso de Suiza, no hay ningún sindicato que les ayude si les va mal. En realidad hay sindicatos en Suiza, pero no les importan situaciones que no les permitan tener algún tipo de impacto mediático.

Aún peor: en la mayoría de los lugares de trabajo serán acosados, particularmente si son mujeres, miembros de la comunidad LGBT o de grupos étnicos que no fuesen el caucásico. He visto programadores amenazados de no tener sus visas renovadas si no hacían sus tareas más deprisa. He presenciado el acoso de mujeres y colegas gay.

Algunos sectores de nuestra industria son estrictamente vomitivos, y no se necesita estar en Silicon Valley para verlo en acción. No se necesita Medium para leerlo. Se puede ver esto directamente en Suiza. Muchos bancos tienen lugares de trabajo asquerosos. Las compañías financieras quieren que vomites código durante 15 horas al día, incluso si las leyes suizas sobre el trabajo lo prohíben explícitamente. Las empresas farmacéuticas quieren que escribas código para falsear los resultados de pruebas de calidad y pasar controles regulatorios de manera ilícita. Las “startups” quieren chupar tu sangre, trabajando 18 horas al día sin compensación, todo “porque te estamos dando stock options” o “porque somos todos parte del mismo equipo”.

No importa que seas Zach Holman y que pongas en tu CV que literalmente escribiste Github de tu puño y teclado: serás despedido por la más estúpida de las razones.

No importa que tu aplicación traiga más de la mitad del tráfico y del ingreso de tu empleador; el equipo de la API tratará tus ideas con desprolijidad y falta de respeto.

Gente muy conocida en esta industria, incluso con páginas en Wikipedia, me ha pedido de trabajar gratis para ellos de manera más que descarada. No daré nombres, pero créanme que impediré que cualquier joven desarrollador se les acerque y trabaje para ellos, porque la gente sin ética no merece el cerebro de nadie.

Cada vez que un gerente de RRHH les diga “deben hacer esto (cualquier cosa que esté mal en su propio marco de referencia) porque le pagamos un salario” recuerden de contestar lo siguiente: “ustedes me pagan un salario, pero yo les doy mi cerebro a cambio, y rehúso cumplir con esta orden”.

Porque además, colmo de los colmos, los colocarán en un open space, y por alguna razón perversa estarán orgullosos de ello. Los open space son un cáncer. Constituyen sin ninguna duda el peor ambiente de trabajo jamás inventado, y el menos apropiado (y de lejos) para el trabajo que consiste en escribir código — o para cualquier otro tipo de trabajo intelectual, en realidad.

Recuerden: el hecho de que ustedes entiendan una situación no implica que tengan que estar de acuerdo con ella.

Desobedezcan la autoridad. Digan “vete al diablo, no haré lo que me pides” y váyanse a otro trabajo. Hay fantásticos lugares para trabajar; no son muchos, pero existen. He tenido la inmensa suerte de poder trabajar en algunos de ellos. No dejen que un mal trabajo les quite el entusiasmo. No lo vale. Desobedezcan y sigan su camino.

O, mejor aún, vuélvanse independientes.

7. Conozcan Su Valor

¿Habrán seguramente escuchado hablar del mito del “Desarrollador de Software 10x”, verdad? Bueno, les voy a develar un secreto: no es un mito, pero no funciona de la manera que ustedes piensan que funciona.

Funciona, eso sí, del punto de vista del empleador: un “Desarrollador de Software 10x” genera un valor diez veces mayor de lo que el empleador le paga. Esto significa que si ella o él gana cien mil francos suizos al año, ella o él en realidad están generando anualmente un valor cercano al millón de francos. Y, claro está, ellos (no los programadores) obtienen el bonus a fin de año, porque, ya lo saben, capitalismo. Conozcan su valor. Lean Karl Marx y Thomas Piketty. No creo que haga falta decir más.

Siempre muévanse: sean como el tiburón que se mueve constantemente, porque sus conocimientos tienen un valor magnífico. Digan sus salarios en voz alta, así todos sabremos si nos están pagando bien o no. Las empresas quieren que se callen, que no se diga cuanto gana la gente, de esta manera pueden permitirse pagarle a las mujeres solamente el 70% de lo que se paga a los hombres. ¡Así que hablen! ¡Blogueen! ¡Twiteen! Yo estoy ganando 135 mil francos suizos al año. Este es mi salario actual. ¿Cuál es el tuyo? ¿Y el tuyo? Cuanto más hablemos, menos desigualdad habrá. Cualquier persona haciendo mi trabajo con mi experiencia debería ganar lo mismo, sin importar su origen étnico, su sexo, su edad o su equipo de fútbol preferido. Punto final. Pero no es así. Para nada.

8. Ayuden A Los Demás

Si eres un hombre blanco recuerda todo el privilegio del que has beneficiado desde que naciste, simplemente porque has nacido de esa manera. Es tu responsabilidad cambiar la industria y sus tendencias para generar más inclusión social.

Es tu tarea ayudar a los demás.

Toma decisiones conscientes en tu vida. Sé consciente de tus acciones y de su efecto. No te sonrojes ni te sientas avergonzado de cambiar tu opinión. Di “lo siento” cuando sea necesario. Escucha. No seas un cabrón. Ten integridad y respeto hacia tí mismo.

No critiques o te burles de las elecciones tecnológicas de tus colegas; porque otros tendrán sus razones para elegirlas, y éstas deben ser respetadas. Prepárate a cambiar tu manera de pensar en cualquier momento mediante el aprendizaje. Un día quizás te guste Windows. Un dia quizás te guste Android. Personalmente hay ciertas cosas en Android que me gustan mucho. Y eso está bien.

9. LLVM

Todos están entusiasmadísimos con Swift, pero en realidad a lo que yo le presto más atención estos días es a LLVM.

Creo que LLVM es el proyecto de software más importante actualmente, teniendo en cuenta su impacto en el largo plazo. Objective-C blocks, Rust y Swift (los dos lenguajes de programación compilados de tipo fuerte más “amados” en la encuesta StackOverflow 2016), Dropbox Pyston, el Clang Static Analyser, ARC, Google Souper, Emscripten, LLVMSharp, Microsoft LLILC, Rubymotion, cheerp, watchOS apps, el Android NDK, Metal, todas estas cosas surgieron o fueron potenciadas por LLVM. Hay compiladores que usan LLVM para casi todos los lenguajes de programación más importantes hoy día. El .NET CLR en algún momento va a interoperar con él, y Mono ya lo usa. Facebook intentó integrar LLVM con HHVM, y WebKit recientemente migró su compilador JavaScript de LLVM al nuevo B3 JIT.

LLVM es cross-platform, cross-CPU, cross-lenguaje, cross-compiler, cross-testeado, gratis y libre, como la cerveza y como los pájaros.

Aprendan todo lo que puedan sobre LLVM. Esta es la galaxia donde sucede la verdadera innovación hoy día. Es la fundación para los próximos 20 años.

10. Sigan Su Intuición

Tuve la intuición de que .NET iba a ser algo importante cuando vi su presentación en junio del 2000. Tuve la intuición de que el iPhone iba a ser importante cuando vi su presentación en 2007.

En ambos casos la gente se rió en mi cara, literalmente. En ambos casos seguí mi intuición y creo que no me fue tan mal.

Sigan su intuición. Quizás tengan suerte, también.

11. Las APIs Son Rey

Las mejores APIs dan pie a las mejores aplicaciones. Si la API es un desastre, la aplicación será un desastre, y poco importará la belleza de la interfaz gráfica.

Recuerden que ”chunky” es mejor que “chatty” (es decir, es mejor enviar mucha información con poca frecuencia que poca información con mucha frecuencia) y que los clientes deben ser tontos; empujen la mayor cantidad de lógica al fondo de la arquitectura, en la API.

No inventen sus propios protocolos de seguridad.

Aprendan un par de tecnologías servidor, y asegúrense que Node sea una de ellas.

Dejen REST de lado y usen Socket.io, ZeroMQ, RabbitMQ, Erlang, XMPP; exploren APIs en tiempo real como el próximo paso para el desarrollo de aplicaciones. El tiempo real no es solamente para chat. Saquen el “polling” de la ecuación, para siempre.

Ah, y no se olviden de empezar a agregar bots en esas APIs. Consejo de amigo.

12. Combatan La Complejidad

Simple es mejor. Siempre. Recuerden el principio “KISS” (Keep It Simple, Stupid). Y no digo esto solamente para la interfaz de usuario, sino en cada capa, hasta el código más profundo de su arquitectura.

Refactoring, tests unitarios, revisión de código, pull requests, todas estas herramientas están a disposicion para asegurarse de que el código que ponen en producción sea la arquitectura que funciona más simple posible. Es de ésta manera que se construyen sistemas que funcionan de manera fiable en el largo plazo.

Conclusión

Lo más importante es recordar que la edad no importa.

Uno de mis hijos me dijo, “Imposible, papá. Los matemáticos hacen su mejor trabajo hacia los cuarenta. Y tienes más de ochenta. Es imposible que tengas una idea buena ahora”.
Si todavía estás despierto y alerta mentalmente cuando tengas más de ochenta, tienes la ventaja de que has vivido un tiempo largo y que has visto muchas cosas distintas, y tienes perspectiva. Tengo 86 ahora, y es en los últimos años que he tenido estas ideas. Nuevas ideas vienen y uno toma partes aquí y allá, y el tiempo es bueno para cosechar ahora, mientras que quizás no lo era hace cinco o diez años.
Michael Atiyah, matemático ganador de la Medalla Fields y del Premio Abel, citado en un artículo de la revista Wired.

Mientras que tu corazón te diga de seguir escribiendo código y de crear cosas nuevas, serás joven para siempre.

En 2035, exactamente dentro de 19 años, alguien dará una charla en una conferencia sobre software similar a ésta, empezando de esta manera:

“Hola, tengo 42 años, y esta es mi historia”.

Con suerte será uno de ustedes quién dará esa presentación; de otra manera, será un bot de inteligencia artificial. Darán algunas referencias anecdóticas sobre 2016, como por ejemplo que fue el año en que fallecieron David Bowie, Umberto Eco, Gato Barbieri y Johan Cruyff, o cuando apareció SQL Server para Linux, o cuando Google AlphaGo le ganó a un campeón de Go, o cuando los Panama Papers y la base de datos de ciudadanos turcos fueron jaqueadas el mismo dia, o cuando Google consideró usar Swift en Android por primera vez, o como el último año en que la gente pudo disfrutar de eso inútil llamado privacidad.

Estaremos a tres años del problema del año 2038 y la gente estará muy nerviosa a causa de ello.

Obviamente no puedo saber que sucederá dentro de 19 años, pero les puedo decir que seguramente pasarán tres cosas:

  1. Alguien preguntará en Stack Overflow como filtrar direcciones de email usando expresiones regulares.
  2. Alguien publicará un nuevo framework en JavaScript.
  3. Alguien creará algo muy interesante usando LLVM.

Y quizás ustedes recordarán esta charla con una sonrisa.

Muchas gracias por su atención.