Michael Kennedy: «Con el pódcast, quiero ofrecer algo de forma gratuita a todo el mundo y conseguir que el mensaje llegue a tantas personas y lugares como sea posible»

Introducción

Michael Kennedy es un empresario de éxito y profesional del desarrollo de software. Es el creador y presentador del pódcast semanal Talk Python To Me, centrado en Python y en temas relacionados del desarrollo de software. También es el fundador y el autor principal de «Talk Python Training», un programa en línea de formación de Python. Tuvimos la oportunidad de entrevistar a Michael sobre sus experiencias de programación, y a continuación incluimos toda la transcripción. ¡Esperamos que la disfrute!

La entrevista

Evrone:En Evrone, llevamos años dedicándonos al desarrollo personalizado e intentamos organizar comunidades profesionales en Rusia, como una comunidad para desarrolladores de Ruby o Python. Tus pódcast son famosos en Rusia. En primer lugar, nos gustaría darte las gracias de parte de la comunidad rusa de Python por tu gran labor.

Nuestra primera pregunta es la siguiente: si Python no existiera, ¿con qué lenguaje trabajarías?

Michael: Buena pregunta. Python lleva mucho tiempo, más de 30 años, lo que creo que ya es bastante sorprendente por sí solo. C++ fue el primer lenguaje de programación que aprendí. Me siguen gustando todos los lenguajes tipo C, y he pensado en qué lenguaje elegiría si no existiera Python. Creo que probablemente sería uno de los lenguajes de C. Probablemente, C#. La verdad es que C# me gusta mucho. Creo que es un lenguaje muy bonito. Me gusta Swift como lenguaje, pero creo que el ecosistema no es tan bueno. Creo que las bibliotecas de clases base no están tan cuidadas ni resultan tan útiles. He trabajado mucho con JavaScript. Pero no es algo con lo que me gustaría seguir trabajando. No es que odie JavaScript, pero no es mi lenguaje favorito. Así que me decido por C#. Sobre todo ahora que es multiplataforma. Aunque seguiré con Python mientras pueda. No creo que vaya a desaparecer.

Evrone:Sí, Python se está comiendo el mundo del software ahora mismo.

Michael: Totalmente. Sobre todo, la parte de ciencia de los datos.

Evrone: En el futuro, ¿crees que habrá métodos de programación que no necesiten que un programador conozca una sintaxis específica del lenguaje y escriba texto en esa sintaxis? ¿Cuál es tu opinión?

Michael: Cada 10 años más o menos, siempre hay alguien que dice «Ya no vamos a tener programadores. Ya no tendremos que trabajar con editores de texto». A veces es por las soluciones de flujo de trabajo sin código del tipo «arrastrar y colocar». Otras veces es por la externalización. En Estados Unidos, existía la preocupación de que muchos trabajos se externalizaran a lugares como India. Pero no creo que eso fuera finalmente ningún problema. Tenemos más trabajos de programación en todo el mundo que nunca. No creo que vaya a producirse una gran revolución de ese tipo. Hay herramientas mucho mejores que permiten crear soluciones sin código o con muy poco. Pero pienso que en realidad es más interesante centrarte estos días en la inteligencia artificial.

Seguro que has visto GitHub Copilot, que te permite escribir un poco de documentación y después decir algo como «crea ese programa», y usar Codex como el motor de aprendizaje automático subyacente. Este motor consulta todo el código fuente de GitHub y escribe ese código. No creo que exista una solución para estos problemas, pero hemos visto que el aprendizaje automático avanza muy rápido. Hace 10 o 20 años, a lo mejor podías pedirle a un editor con inteligencia artificial que escribiera un programa y lo haría. Pero no creo que esto signifique que los programadores vayan a desaparecer. Creo que siempre habrá alguien que vaya a verificar eso. Alguien tiene que mantenerlo y conseguir que evolucione. Y no sé si la inteligencia artificial llegará a ser tan buena que puedas decirle «Ahora quiero añadir esta característica. Reescribe mi programa». A lo mejor sí, pero me parece más bien poco probable. Creo que los proyectos de inteligencia artificial basados en GPT-3 tendrán un impacto mucho más interesante en el futuro que los flujos de trabajo sin código del tipo «arrastrar y colocar».

Evrone:Sí, a los humanos nos gusta comunicarnos entre nosotros, y hemos evolucionado bastante para hacerlo. En tu repositorio, tienes un script que permite a cualquier usuario copiar todas las grabaciones de audio del pódcast de Python. ¿Cómo te sientes por el hecho de que la gente pueda copiar tu trabajo?

Michael: Sí. Cualquiera puede descargarlo. Son como cinco gigabytes. Se tarda un rato, pero no mucho. He pensado bastante en esto. Tienes que pensar en términos del código fuente y el proyecto que publicas en GitHub, y el contenido que creas que podrías publicar en un pódcast o tal vez en YouTube. Esto me hace pensar en cuál es mi trabajo en realidad. ¿Qué quiero lograr? Con el pódcast, lo que intento lograr es que el mensaje llegue a tantas personas como sea posible. Quiero compartir los datos sobre Flask 2.0, o cómo Python se usa en astronomía o cualquier otra área. Quiero que eso llegue a tantas personas y lugares como sea posible. Y, para hacerlo, publico el pódcast de forma gratuita. Tiene algunos anuncios, pero se puede distribuir de forma gratuita a todo el mundo. No hay ningún coste asociado. Y animo a la gente a descargarlo y compartirlo. Me parece bien, porque también tengo cursos de Python. Algunos son gratuitos, pero la mayoría de ellos cuestan dinero. Y creo que eso es justo, ¿no? Quiero crear algo que esté disponible de forma gratuita para el mundo, e intento apoyar a la comunidad y animarla; pero también quiero crear algo que la gente vaya a apoyar más o de lo que quiera aprender más. También pueden hacerlo.

Evrone: Gracias. Está muy bien que intentes ayudar a los desarrolladores. Apple es una de las empresas que intenta ayudar a los desarrolladores, y han revolucionado el mundo con su nuevo chip M1. Han integrado Apple Neural Engine en el chip y permiten usarlo a los desarrolladores. ¿Has podido probarlo? ¿Qué te parece?

Michael: Me encanta Apple Silicon y el chip M1. Y el hecho de que incluya Neural Engine creo que ofrecerá un gran número de interesantes posibilidades. Pensamos en usar las GPU y el aprendizaje automático como algo que necesita hardware muy grande y costoso, estas enormes máquinas que hacen mucho ruido.

Y, si podemos tenerlas en el M1 o en nuestros teléfonos, va a permitir cosas muy interesantes, sobre todo de informática perimetral. La inteligencia artificial y los asistentes de voz permiten combinar funciones localmente. Así que creo que es un avance muy positivo, y es genial que puedas hacer tanto con el aprendizaje automático en Python para aprovechar estas cosas. Dicho esto, solo lo he usado como consumidor, no como desarrollador. Pero tengo una de mis aplicaciones de edición favoritas para todo tipo de ilustraciones, como logotipos y demás. Se llama Pixelmator Pro. Y usa los sistemas de aprendizaje automático para una gran parte de su trabajo. Por ejemplo, si cambias el tamaño de la imagen, en lugar de cambiar el tamaño con una fórmula matemática, puedes usar un motor de aprendizaje automático y el motor neuronal subyacente para conseguirlo. Me encanta.

Evrone: Sí, seguro que veremos aplicaciones como Photoshop o Affinity Designer, donde las imágenes, el audio y todos esos datos se procesarán con este motor.

Podemos afirmar que a los desarrolladores no solo les encanta escuchar casos de éxito, sino también los fracasos. ¿Qué puedes decirnos sobre tu experiencia profesional cuando las cosas salen mal y cómo gestionarlo?

Michael: Estoy pensando varias ideas para ver qué historia puedo compartir aquí. Creo que la que compartiré tiene que ver con una empresa para la que trabajé. Intenté crear una plataforma de educación en línea basada en una plataforma de formación presencial. Teníamos miles de estudiantes que podían asistir a cursos, así que nos propusimos la idea de crear una versión en línea. Y todo pareció muy natural. Teníamos miles de clientes. Íbamos a desarrollar algunos cursos y los pondríamos en línea. Pero aquello no fue muy bien. Trabajamos en el proyecto varias personas durante seis meses, pero la respuesta no fue la esperada.

Y una de las cosas que aprendí de aquella experiencia no tiene que ver con el desarrollo de software. Más bien, aprendí cómo transmitir el mensaje al mundo. Parece fácil soñar con crear el próximo gran avance, ¿verdad? Instagram hace esto, pero nosotros podríamos hacerlo mejor. Airbnb hace eso. ¿Pero sabes qué? Si aplicamos la misma idea a los camiones, sería increíble. ¿Verdad? Casi todos nosotros podríamos desarrollar ese software. Pero, si nadie lo conoce, nadie podrá probarlo. Es muy difícil.
Así que diría que los mayores desafíos a los que me he enfrentado varias veces no eran necesariamente problemas técnicos. Es cuando nuestros sueños técnicos se encuentran con el mundo real. Y tienes que ir desde ahí. También he tenido algunos errores técnicos interesantes que he tenido que solucionar. Pero los desafíos que más me han impactado son aquellos en los que tuve que dedicar mucho tiempo y crear algo atractivo, pero no pude transmitir el mensaje.

And so I would say the biggest challenges I have experienced multiple times were not necessarily technical problems. It’s when our technical dreams meet the real world. And then you've got to go from there. So I've also had some interesting technical failures that I've had to deal with. But the big ones that stick out are these challenges of spending a lot of time and building something beautiful but not being able to get the word out about it.

Evrone: Sí, una cosa es escribir software. E informar al mundo sobre eso está relacionado, ya que el software tiene que ayudar al mundo. Necesita usuarios.

Muchos desarrolladores principiantes usan ideas avanzadas, como JetBrains PyCharm o Visual Studio Code con la extensión Microsoft Python. Para los desarrolladores novatos, ¿cómo podemos evitar que la diversión de programar se arruine por las continuas advertencias y grandes cantidades de código resaltado como incorrecto?

Michael: Sí, es un problema, ¿verdad? Los principiantes se enfrentan a muchos desafíos, y creo que algunos tienen que ver con elegir el tamaño adecuado del problema en el que quieren trabajar. Si eliges un problema que es demasiado sencillo, no te servirá de inspiración. Si eliges un problema que es demasiado complicado, aunque se pueda alcanzar, acabarás frustrándote. Así que tienes que encontrar el nivel adecuado, y eso te ayudará, ya que no trabajarás con código demasiado complejo. Pero eso es muy poco preciso. No es muy específico ni útil. Mi consejo es que, cuando veas uno de esos errores, no lo omitas simplemente porque pienses que funcionará de todos modos. En su lugar, dedica un momento a averiguar qué significa el error y lo que intenta enseñarte. Por ejemplo, un error común que suele aparecer en PyCharm es este: «Esta variable local entra en conflicto con la variable global, y puede que tu código funcione, pero verás una advertencia. Puedes pensar que no sabes lo que significa, que te da igual y continuar. Pero también podrías pararte un momento y pensar lo siguiente: «Me he dado cuenta de que solo tengo que elegir otro nombre para no tener esta confusión en mi código».

Necesitas pararte e ir más despacio. Averigua qué significa y no intentes obtener la respuesta y ya está; en su lugar, usa continuamente estos ciclos de aprendizaje. Lo mismo ocurre si aplicas linters en tu programa después de haberlo desarrollado durante seis meses. Verás páginas y páginas de problemas que no sabías que existían. Si aparecen desde el principio y solo tienes que solucionar uno o dos al día, no pasa nada. Pero si se acumulan y llegan a mil problemas en un período de seis meses, no quieres tener que dedicarte una semana entera a arreglarlos. No es algo productivo. Tienes que aprender a programar mejor para evitar las advertencias, y solo tienes que dedicar un momento para averiguar qué intentan decirte. Corrige la advertencia y continúa. La ventaja es que no solo te informará de los problemas, sobre todo con PyCharm, pero también con VS Code. A veces, también te dirá cómo corregirlos.

Evrone:Si hablamos de inspiración, lo que más nos gusta a los desarrolladores es encontrar soluciones interesantes y poco comunes. ¿Cuál sería tu consejo para los desarrolladores? ¿Dónde podemos encontrar la fuerza para sobreponernos a la rutina y encontrar el interés, la inspiración y la felicidad en el desarrollo de software?

Michael: Siempre intentamos conseguir una nueva biblioteca llamativa, una novedad que podemos usar para solucionar un problema. Pero, muchas veces, eso no es lo que necesitamos. Solo tenemos que solucionar un problema. Es parecido, pero lo suficientemente distinto para que tengamos que crear algo nuevo. Creo que una de las cosas que podemos hacer para superar estos desafíos (o estas tareas aburridas y repetitivas) es usar nuestra creatividad y habilidades de programación para averiguar cómo solucionar el problema para siempre.

Por ejemplo, imagina que cada día tuvieras que cargar un archivo CSV por FTP o una tarea igual de aburrida; después, lo descargas y lo ejecutas con el script y se carga en el destino. Entonces, se introduce en la base de datos y otra persona hace un informe sobre eso. Podrías encontrar una forma de escribir un demonio que supervise un directorio y que ejecute esa acción automáticamente cuando se cree un archivo específico. Puedes pensar en este tipo de cosas para «automatizar las tareas aburridas».

Lo que en un principio podría haber sido aburrido, si encuentras una forma de hacerlo automáticamente (o en gran parte), cada vez que se ejecute, seguro que sonríes y piensas «Sí. Eso no era divertido, pero mira ahora». Y esos problemas también te ayudarán a crecer como desarrollador de software. Puede que sepas cómo cargar un archivo CSV y guardarlo en Postgres o algo similar. Pero no sabes cómo crear un demonio del sistema en Linux que se ejecute continuamente con Python. Bueno, sería genial aprender eso. Esta es la novedad con la que puedes jugar. Y ya nunca tendrás que repetir esa tarea.

Evrone: Sí. Como desarrollador, ¿con qué frecuencia tienes que pensar sobre el servicio o plataforma sin servidor específico donde se ejecutará tu aplicación? ¿Se refleja de algún modo en tu código?

Michael: En realidad, no suelo pensar mucho en eso. En cierto sentido, sí que se refleja en el código. Esta es mi filosofía sobre las plataformas en la nube. Tienes que hacer un sacrificio bastante interesante. Si lo apuestas todo en la tecnología nativa de la nube y desarrollas aplicaciones que usan todos los servicios, puedes crear cosas realmente increíbles. Por ejemplo, si usas esa base de datos alojada y ese servicio de administración de colas alojado, y también ese servicio de correo electrónico alojado, y solo tienes que seguir los pasos de estos servicios, puedes crear aplicaciones muy interesantes, con dos restricciones.

Por una parte, estarás para siempre atrapado en esa nube específica. Y, si creas algo que use todas las API y servicios de Amazon, tendrás que reescribirlo todo si luego quieres migrar a Azure, Linode o algo parecido. Y no quieres tener que hacer eso si piensas que en algún momento podrías cambiar de tecnología. El otro inconveniente es que no podrás trabajar si no puedes conectarte a Internet o tu conexión es inestable. Si estás en un avión, o a lo mejor tienes que quedarte en casa a causa de la COVID y quieres ir a un parque y trabajar en un banco, porque ya no aguantas quedarte en casa, no podrás trabajar en tu aplicación. Lo que hago es ejecutar nuestros servicios en un conjunto de máquinas virtuales con Linux.

Y esas máquinas se ejecutan en DigitalOcean, Linode o AWS. Aparte de esas máquinas, uso un par de servicios que son únicos. Por ejemplo, tengo un servicio en la nube para crear transcripciones de audio. Y se integra por completo con esas API. Pero eso no afecta a dónde se ejecutan el resto de mis aplicaciones. Y tengo una para la distribución de vídeo en todo el mundo que la integro también con ese servicio. Pero esa no es toda la historia de mis aplicaciones e infraestructura.

Ese es mi punto de vista. Suelo usar cosas más sencillas que se pueden migrar a otras ubicaciones. Esto ha funcionado muy bien conmigo. Por ejemplo, a lo mejor puedo hacer algo en AWS Lambda o Azure Functions y mi vida sería más sencilla, pero no lo creo. Muchos pensamos en lo que hacen las grandes empresas, la escala increíble que están consiguiendo, y creemos que esos consejos serían válidos en nuestro caso. Hay un artículo muy bueno llamado «No eres Google». No eres Facebook, ni tampoco eres LinkedIn. Dice que lo que hacen esas empresas en la informática en la nube y otras cosas increíbles es porque tienen cientos de millones de usuarios y necesitan reducir a cero el tiempo de inactividad. Si tienes dos mil usuarios, puedes permitirte cinco segundos de inactividad una vez al mes. No parece una gran diferencia, pero es una diferencia enorme para la complejidad de lo que tienes que desarrollar.

Evrone: Suele decirse que Python es lento. ¿Te parece que el rendimiento sea insuficiente? ¿Usas optimizaciones para agilizarlo?

Michael: A veces me ha ocurrido, pero no llega a ser un problema para mí. No me dedico a la ciencia de los datos ni ejecuto cálculos matemáticos a gran escala. Creo API. Creo aplicaciones web o pequeñas automatizaciones, cosas así. Y Python ha sido muy útil en esas situaciones. Interactúa bien con estos otros sistemas. Estos otros sistemas son las redes, las bases de datos y las API de terceros, como Stripe, servicios de correo electrónico, etc. En ese mundo, funciona bastante rápido. Diría que el tiempo medio de respuesta de la red interna a la externa es de unos 30 milisegundos. Nadie va a notar una diferencia de 30 a 20 milisegundos. A lo mejor puedes decir que podrías tener menos servidores si asignas una menor carga de computación. Pero, la mayoría del tiempo, se espera en realidad a bases de datos y otro tipo de cosas, así que no puedes hacer que funcione mucho más rápido. En el lado científico, se pone bastante interesante. Si lo haces todo solo con Python, estoy de acuerdo contigo en que probablemente sea bastante lento. Pero la mayoría de lo que ocurre en el lado de la ciencia de los datos es así: «Voy a obtener esa biblioteca. Voy a obtener TensorFlow o algo así». Y esos son solo niveles muy finos alrededor del código de C, y el código de C es muy rápido, por lo que podrías obtener los datos en C y, después, consultarlos desde Python. En ese caso, también es rápido.

Así que la historia de la velocidad de Python es muy interesante. Estoy de acuerdo con eso en algo como Numba o Cython. He usado Cython para un par de cosas. He oído hablar de las vistas de Django en Cython, lo que me parecía una idea un poco alocada. Pero hacían muchos cálculos en sus visualizaciones, y con Cython era mucho más rápido. Ese es el aspecto técnico. Hay otra cosa que debes tener en cuenta cuando la gente habla de lento o rápido: «¿Qué quieres que funcione más rápido?». Si pudiera escribir un programa en C++ que se ejecutara y me diera la respuesta a un problema en 10 segundos, y pudiera escribir un programa en Python que me diera una respuesta en 5 minutos, está claro que C++ es más rápido. Pero si tardo una semana en escribir ese código de C++, y solo tardo medio día en escribir el código de Python, quiere decir que me he ahorrado mucho tiempo. Así que creo que se trata de saber qué quieres optimizar. ¿Quieres optimizar la velocidad del desarrollador, del producto o del cálculo? A veces, tiene sentido usar C++ o algo parecido (como Go), pero no es algo tan común como podría imaginarse.

Evrone:¿Hay alguna peculiaridad de Python que te parezca extraña o muy mala? ¿Qué te gustaría mejorar en Python?

Michael: Me gusta bastante cómo funciona Python. No haría grandes cambios. Te daré un par de ejemplos que creo que son muy importantes, y después uno o dos que son cosas extrañas del lenguaje.

La instrucción «else» no tiene ningún sentido para mí. El resto de los lenguajes pueden ejecutar perfectamente un bucle sin la instrucción «else» y gestionar las excepciones sin «else». No suele usarse.

Creo que hay cosas interesantes relacionadas con las anotaciones de tipos con las que podíamos trabajar más. Sobre todo, si hay anotaciones de tipos, podríamos ejecutar cálculos matemáticos más rápido. Por ejemplo, el intérprete podía analizar el hecho de que haya una anotación de tipo para un grupo de números, y usaremos números de nivel de C, en lugar de los números de nivel infinito, que son más lentos. Cosas así serían muy útiles. Pero no me resulta un gran problema.

Además, me gustaría pulsar un botón en PyCharm o VS Code, o ejecutar algo de la línea de comandos, y obtener fácilmente un archivo ejecutable que pueda enviar. Sin tener que instalar bibliotecas, para que puedas ejecutarlo directamente. Sé que están PyInstaller y py2exe, pero son bastante inestables y complicados de usar. Al igual que puedes pulsar «Ejecutar» en PyCharm o VS Code, sería genial si pudieras pulsar «Compilar» y obtener un ejecutable. Además, me encantaría que fuera compatible con interfaces de usuario de aplicaciones móviles y de escritorio. Creo que Python sería mucho más popular si las funciones para distribuir ejecutables y crear interfaces de usuario fueran muy buenas. Ya es bastante popular sin esas dos cosas, pero no puedes crear aplicaciones móviles. Si pudieras, sería una locura. Y me encantaría que eso ocurriera.

Evrone: ¡Muchas gracias, Michael! Ha sido un placer hablar contigo. Espero que nos volvamos a ver en alguna conferencia presencial. ¡Gracias y que tengas un buen día!

Conclusión

Tuvimos la oportunidad de charlar con Michael y aprender de sus conocimientos y experiencia de Python. Obtener conclusiones útiles de profesionales del sector sobre los lenguajes de programación, las herramientas y las soluciones que usamos cada día nos ayuda a prestar un mejor servicio a nuestros clientes y alcanzar sus necesidades de software.

También queremos dar las gracias a nuestro compañero Nikolai Rubanov de Selectel por ayudarnos con las preguntas para esta entrevista.

En Evrone, solemos usar Python para desarrollar soluciones personalizadas de software para nuestros clientes. Si quiere obtener información sobre los servicios que ofrecemos o necesita ayuda con su último proyecto, envíenos un mensaje y le responderemos lo antes posible.