Entrevista con Armin Ronacher, creador de Flask

Introducción

Armin Ronacher se ha convertido en colaborador habitual en el ecosistema de software de Python, ya que ha creado proyectos muy populares como Flask y Jinja2. En los últimos 10 años, ha trabajado en varios proyectos comerciales y de código abierto, y estamos encantados de hablar con él sobre su vida y desarrollo profesional. En esta entrevista con Evrone, Armin habla sobre su trabajo en Sentry, comparte su opinión sobre cómo gestionar errores en el back-end, habla sobre las diferencias entre Rust y Python, el método de «tipado gradual» y, por supuesto, sus secretos para conciliar la vida laboral y personal.

La entrevista

Evrone:  Tu puesto se denomina director de ingeniería. ¿Cómo es un día de trabajo cualquiera en Sentry?

Armin: Desde el punto de vista de la programación, mi día suele dividirse en dos partes. Trabajo desde las 9:00 hasta las 15:00-16:00, cuando recojo a mis hijos de la guardería. Después, tengo un segundo turno por la tarde/noche para reuniones en distintas zonas horarias. Dicha partición funciona bien para mí, ya que de esa forma tengo tiempo para estar con mis hijos cuando aún hay luz fuera. En relación con mis funciones, mi papel en muchos aspectos es asegurarme de que todas las personas que trabajan conmigo estén informadas sobre los aspectos relevantes. Esto es especialmente importante, ya que Sentry es una empresa con varias ubicaciones en distintas zonas horarias. En realidad, es una combinación entre contratar, solucionar los problemas de las personas, asistir en la arquitectura de sistemas, dar forma o comunicar la visión del producto a los proyectos actuales y ayudar en gran medida con problemas de ingeniería de todo tipo.

2. Evrone:  El popular método de «pila completa» anima a los desarrolladores a escribir código de front-end y back-end. Como desarrollador con amplia experiencia en lenguajes de programación y pilas tecnológicas, ¿apruebas dicha práctica?

Armin:  Es una pregunta complicada, ya que… ¿qué es realmente una pila completa en un proyecto complejo? Está claro que, para una aplicación trivial, simplemente consiste en un back-end de CRUD y un front-end de React, y puedes comprenderlo todo. Pero ese proceso no funciona para todos nosotros, ya que Sentry es una iniciativa mucho más compleja. La descripción simplificada de Sentry es un servicio que procesa informes de rendimiento y de bloqueos, y los muestra al usuario. Sin embargo, desde una perspectiva técnica, Sentry es una canalización de procesos muy compleja con varias bases de datos y varios servicios que procesan los informes antes de que persistan. La idea de que una única persona pudiera encargarse de trabajar en todos estos componentes para crear una característica no solo es poco realista, sino también muy ineficiente. Por lo tanto, mi respuesta a la pregunta de si apruebo este tipo de procedimientos dependería mucho del tipo de proyecto.

3. Evrone:  La reciente reestructuración de Mozilla ha afectado a un gran número de desarrolladores del lenguaje Rust. ¿Cómo crees que esto afectará al desarrollo del lenguaje?

Armin:  En mi opinión, me duele bastante ver los cambios producidos en Mozilla. Al igual que Mozilla, somos un proyecto de código abierto que nos hemos convertido en una empresa comercial, y nuestros caminos se han cruzado varias veces. A veces usamos las tecnologías de Mozilla, de la misma forma que Mozilla usa las nuestras. Creo que, para Rust en conjunto, los cambios producidos en Mozilla sin duda afectarán al lenguaje, pero no creo que Rust se vea dañado a causa de esto. Sin embargo, no tener el proyecto Servo sin duda tendrá un impacto en la forma en que evolucione el lenguaje y la comunidad.

4. Evrone:  ¿Cuál crees que es el motivo principal por el que los paquetes de Python aún son tan complicados?

Armin:  Es una historia muy compleja, pero creo que se reduce a las dificultades técnicas y la falta de concentración. Por ejemplo, si se compara con la comunidad de Rust, los paquetes se han reconocido como un aspecto importante y un proyecto de la comunidad (cargo) se convirtió en parte del desarrollo del lenguaje. En el mundo de Python, estos esfuerzos siempre se producen por separado. La infraestructura de creación de paquetes (pip, setuptools, virtualenv) se desarrolla en gran medida de forma independiente al lenguaje. En el aspecto técnico, hay muchas deficiencias en Python que impiden alcanzar una mejor experiencia del usuario. Por ejemplo, solo se puede cargar una única versión de una biblioteca al mismo tiempo, lo que limita la libertad con las dependencias.

5. Evrone:  Al comparar Python, Rust, TypeScript y otros lenguajes con los que trabajas, ¿cuál crees que es la mejor estrategia para que un desarrollador de nivel medio gestione los errores en su código de back-end?

Armin:  Como trabajo para una empresa especializada en informes de bloqueos, estoy expuesto a un gran número de errores de back-end :) Lo que he aprendido con esto es que tienes que dedicar la misma cantidad de tiempo a diseñar los tipos de error que a diseñar los valores devueltos. No puedes tener información contextual suficiente sobre los errores. Hay una gran cantidad de código que simplemente escribe mensajes de error en una excepción y da por concluido el trabajo. En algún momento, alguien querrá responder a esos errores y empezará a analizar los mensajes de error. Este tipo de «gestión de errores de tipos de cadenas» causa mucha frustración. Recuerdo un código de gestión de bases de datos que comprobaba un tipo específico de error de conexión al analizar el mensaje de error y gestionar varios idiomas (alemán, francés, etc.), ya que la base de datos al otro lado localizaría los mensajes de error.

6. Evrone:  ¿Hay alguna característica del ecosistema o el lenguaje Python que realmente echas de menos al trabajar con Rust?

Armin:  Por supuesto. Python es un lenguaje muy maduro y consolidado, por lo que cada vez que cambias a algo distinto, hay muchas cosas que echas en falta. Otros ecosistemas tardaron mucho tiempo en ser tan completos como Python. Uno de los primeros aspectos que he observado al escribir más con Rust es que el ecosistema se podía adaptar rápidamente a elementos típicos del año 2020, pero no resultaba tan fácil con tecnologías más antiguas. Por ejemplo, la primera vez que tuve que usar código XML, en lugar de JSON, me di cuenta de lo ineficiente que es la compatibilidad de Rust con XML. Otro aspecto es que Python es un lenguaje bastante «lento», que no te penaliza realmente por añadir más características de depuración en una compilación de producción. En Rust, realmente no puedes hacer eso sin eliminar una de las mejores características (el rendimiento). Esto te obliga a programar de formas muy distintas.

7. Evrone:  ¿Cuál crees que es la mejor forma de evaluar los conocimientos de un desarrollador de software?

Armin:  Es una pregunta que me resulta difícil de contestar. Creo que no existe una forma universal de contratar o evaluar a las personas, ya que en gran parte se basa en tu capacidad para evaluar a la gente en general. Hay toda una comunidad de personas que lo único que hacen es lanzar preguntas de entrevista de empresas de FAANG, y estoy seguro de que eso ha cambiado un poco las cosas. También nos encontramos en la situación en que mis equipos suelen trabajar en problemas que son bastante únicos, por lo que es más importante averiguar si los desarrolladores tienen interés en solucionar problemas únicos (y, a veces, frustrantes) y cómo se desenvuelven trabajando en equipo en aspectos problemáticos.

8. Evrone: ¿Crees que Python es el mejor lenguaje de programación de uso general que deberían aprender primero los nuevos desarrolladores? ¿Hay nuevas alternativas en 2020?

Armin:  No estoy seguro de que Python sea el mejor lenguaje de programación de uso general, pero siempre he pensado que es bastante equilibrado. A pesar de todas sus deficiencias y las frustraciones que causa, permite solucionar problemas con bastante rapidez y, en ese sentido, es tan bueno en 2020 como lo era hace 15 años. Por un momento, pensé que JavaScript lo reemplazaría. Pero, de alguna forma, la comunidad ha adoptado dicha complejidad, que hasta incluso las cosas más sencillas se hacen complejas. Aún puedo programar con mayor rapidez un proyecto sencillo en Python que en JavaScript, simplemente por el hecho de que solo necesito un puñado de bibliotecas. Si tuviera que enseñar a alguien a programar en 2020, probablemente elegiría C, Rust y Python como los lenguajes, y Python en gran medida porque también puedes mostrarles el código fuente del intérprete y podrán comprender cómo funciona en segundo plano. Esto no ocurre con otros lenguajes populares.

9. Evrone:  Con tantos lenguajes de programación disponibles, ¿qué sistema operativo e IDE prefieres?

Armin:  Los ordenadores son horribles. Tengo una relación de amor odio con macOS. Aún lo uso y, cada vez que intento usar algo distinto, vuelvo en solo unas semanas. Aunque implemento equipos con Linux y también uso bastante Windows en mi vida. En relación con el IDE, uso Visual Studio Code con enlaces de Vim, y aún uso bastante Vim de forma independiente.

10. Evrone:  Recientemente, se introdujeron los nuevos conceptos y sintaxis de «async/await» en Python, Rust y TypeScript: todos los lenguajes con los que trabajas. ¿Cuál es tu opinión sobre este método para gestionar la simultaneidad en nuestro código?

Armin:  Tengo mis dudas. Creo que tiene muchas ventajas cuando se usa correctamente, pero oculta las complicaciones de la simultaneidad en gran medida. También hace que sea más aparente la falta de gestión de contrapresión, y creo que la mayor parte del código de «async/await» produciría errores si intentara llevarlo al punto de inflexión. Esto es algo que el código de multiprocesamiento tradicional (que usa un grupo en su mayoría) no sufre de forma predefinida. También es importante comprender que, aunque varios lenguajes usen «async/await», la forma en que se aplica en cada uno es muy distinta. Los diseños de «async/await» de Rust y JavaScript no pueden ser más distintos.

11. Evrone:  Parece que Python se está comiendo el mundo. ¿Podrías mencionar algunos competidores reales como lenguaje de programación de uso general?

Armin:  Parece que Python se come el mundo mayormente debido a la ciencia de los datos. Creo que, aunque está perdiendo popularidad en el mundo de la web, está compensando rápidamente esas pérdidas en el mundo de los datos. Como JavaScript no tiene un buen rendimiento con los números (simple y llanamente), tiene menos oportunidades ahí. Dicho esto, creo que JavaScript es cada vez más popular por pura necesidad.

12. Evrone:  Con toda tu experiencia en el desarrollo de código abierto y Flask, reforzada con tu trabajo en Sentry, te has convertido en un experto en lenguajes de programación. ¿Qué piensas sobre el futuro de Python?

Armin:  Creo que cada vez será más especializado en algunos ecosistemas y que desaparecerá por completo en otros. Esto es algo que ya ha ocurrido en el pasado. Por ejemplo, Python dejó de intentar convertirse en un lenguaje para incrustación (scripting de aplicaciones o juegos, etc.) o desarrollo móvil. Tampoco es algo que usaría como lenguaje preferido para aplicaciones de escritorio, especialmente si quieres incluirlas en tiendas de aplicaciones. Sin embargo, es probable que cada vez sea más popular para infraestructuras de scripting, ciencia de los datos y aplicaciones sin servidor. He podido apreciar un cambio en los usuarios de mi motor de plantillas, desde aplicaciones web clásicas hasta scripting de infraestructura (Ansible, salt), por ejemplo.

13. Evrone:  ¿Qué piensas del nuevo método de «tipado gradual» introducido en Python, JavaScript (a través de TypeScript), Ruby, PHP y otros lenguajes dinámicos?

Armin:  Creo que es genial. Me encanta TypeScript y creo que, si otros lenguajes quieren aprender de otro sitio, tendrían que copiar de ese proyecto.

14.  Evrone:  Como padre de tres hijos y responsable de desarrollo de software, ¿cómo concilias tu vida laboral y personal y evitas quemarte?

Armin:  En el momento de escribir este documento, aún tengo dos hijos, aunque solo quedan días para que llegue el tercero (crucemos los dedos). Lo más importante es que no soy padre soltero. Mi mujer es una pareja maravillosa y cuidamos a nuestros hijos juntos. Para ayudarnos, el siguiente punto más importante es encontrar una buena guardería. No puedes ser buen padre las 24 horas, pero puedes asegurarte de que el tiempo que pases con ellos les dediques toda tu atención. Especialmente durante los primeros días de la pandemia, cuando nuestros hijos estaban todo el tiempo en casa y me di cuenta de que eso no era algo bueno para ellos. Pasaban más tiempo con la tele y el iPad, ya que teníamos que hacer malabares con las reuniones de trabajo a la vez que los cuidábamos.

En mi caso, como vivimos en Viena y la oficina central se encuentra en San Francisco, tuve que adoptar un modelo bicameral en el que trabajaba en dos turnos, con un descanso entre medias. Para mí es ideal, pero no creo que este método funcione para todo el mundo. Empecé a crear una lista donde anotaba cuándo y por qué algo me estresada o molestaba emocionalmente durante una semana para intentar optimizarlo y evitarlo. Con el tiempo, llegas a comprenderte un poco mejor. Aprendes a identificar ciertos patrones.

Una vez identifico una situación que puede molestarme, intento prevenirla o evitarla. En su lugar, intento reconocer con antelación lo que va a causar una respuesta emocional en mí. No siempre funciona, pero en general me ha ayudado bastante. Por ejemplo, las notificaciones de Slack ya no me interrumpen como antes, incluso sin activar la función de no molestar.

Conclusión

Hemos disfrutado hablando con Armin y aprendiendo un poco más sobre su actitud ante la vida y cómo escribir código. En Evrone, usamos con frecuencia el marco Flask para desarrollar soluciones personalizadas para nuestros clientes. Si tiene buenas ideas y le gusta Python tanto como a nosotros… ¡póngase en contacto con nosotros para crear un nuevo producto juntos!