Fernando Cejas trabaja como desarrollador en IBM. Comenzó en el mundo de la programación cuando era adolescente, por curiosidad, porque siempre le ha gustado saber cómo funcionan las cosas. Cuando consiguió entender cuál era la magia que movía un ordenador quiso saber darle órdenes y, por ende, programar pequeñas aplicaciones.
En la actualidad trabaja en IBM donde, dice, le toca “hacer un poco de todo”. No se focaliza de manera estricta en un enfoque concreto, y siempre intenta utilizar la mejor herramienta para resolver el problema al que tenga que enfrentarse. Respecto al mundo del desarrollo, se atreve tanto con programación orientada a objetos (donde tiene más experiencia) como con programación funcional. “Incluso creo que no tengo que ser de uno u otro lado, sino intentar coger lo mejor de ambos mundos”.
Has pasado por empresas como Tuenti o SoundCloud y ahora estás en IBM, ¿cómo ha sido tu avance a nivel profesional?
La verdad es que siempre saco conclusiones positivas. Todo son experiencias constructivas. Estoy muy contento y realmente disfruto lo que hago, es más una pasión que un trabajo y agradezco que pueda ser así. Cada una de las empresas que mencionas fueron muy distintas primero en cuanto a cultura y segundo en cuanto a tipo de trabajo.
Tuenti y SoundCloud tenían más espíritu startup: buena comunicación, gente muy inteligente y desafíos técnicos muy complicados y a la vez divertidos. IBM es más una corporación grande, y mi decisión de moverme vino para adquirir experiencia en empresas de este tamaño, puesto que yo venía del mundo startup, que es lo que siempre me ha apasionado. Además, mi actual trabajo implica distintas áreas, como investigación y comunicación con otros desarrolladores (lo que se llama Developer Relations).
¿Qué haces en IBM? ¿Has estado implicado en el desarrollo de su ordenador cuántico comercial?
Como te comentaba, hago open source e investigación, y comparto el conocimiento publicando artículos y hablando en conferencias. No aporto código a ningún producto en particular, tengo bastante libertad.
En lo que respecta a computación cuántica, no estuve envuelto en su desarrollo pero he investigado su funcionamiento ya que, valga la redundancia, me encanta la ciencia en general y en los últimos años he indagado más en física cuántica y en los principios que gobiernan el funcionamiento de dichos ordenadores. No soy un experto en la materia, pero si un nerdy interesado.
¿En qué momento te encuentras en el mundo de la programación?
Después de muchos años programando, estoy en un momento donde no me dedico 100% a escribir código. La experiencia te da eso: «más experiencia tienes, menos código escribes, pero tienes más iniciativas y muchos más recursos en cuanto a la resolución de problemas». Dicho esto, me gusta pensar los problemas y cómo resolverlos, organizar, hacer mentoring, ayudar… Creo que eso es la evolución natural en esta carrera.
¿Animarías a quienes están indecisos a aprender código? ¿Por qué?
¡Claro que sí! Al día de hoy vivimos rodeados de tecnología que avanza muy rápidamente. Ya vemos desde hace años que es el futuro y cada día con más áreas desarrollándose (inteligencia artificial o computación cuántica, entre otras). Las oportunidades en este ámbito son casi infinitas.
¿Qué lenguajes crees que tienen un gran futuro por delante?
Hay muchos lenguajes de programación emergentes en expansión que han aprendido de los errores que se han cometido en el pasado, y que te brindan la facilidad de aprendizaje y resolución de problemas.
Lenguajes como Kotlin, Rust, Go, Crystal o R son muy populares al día de hoy. Con esto no quiero decir que lenguajes de la vieja escuela como Java o Python no hayan evolucionado, siempre están en mejora continua y tienen un extenso mercado, documentación y experiencia.
¿Quiénes son tus referentes en el mundo de la programación?
Sigo muchas referencias del mundo de la programación como Martin Fowler o Robert C. Martin. También, con todo el contenido que se genera diariamente, me gusta mucho seguir blogs técnicos de empresas o entidades que comparten su día a día en cuanto a temas como escalabilidad, resolución de problemas, estructura de equipos, organización de código, patrones, etc. Por nombrar algunos: SoundCloud, Spotify, Twitter o Netflix.
Hace poco diste una charla sobre ‘The art of coding, disasters and failures’, ¿qué contabas?
Es una charla un poco particular la verdad, ya que en ella intenté agrupar todos los errores que he cometido en mi vida profesional, justamente para compartirlos y ayudar a otros y evitar que se den contra una pared, como lo he hecho muchas veces. La moraleja de la historia es que no estamos solos, todos cometemos errores, somos seres humanos, pero lo importante es compartir dichas experiencias, no estresarse y ser capaces de afrontar estas situaciones de la mejor manera posible y con una sonrisa en la cara.
¿Eres más de lenguajes nativos o de no nativos? ¿Por qué?
Voy con no nativos, pero si me tocara nativos ahí estaría intentándolo, al final todos tenemos la capacidad humana de aprender. La razón es que los no nativos me cuestan menos, son capaces de una abstracción que gente muy inteligente ha creado para intentar hacernos la vida más fácil. Incluso actualmente diría que no hay tanta necesidad en general de programar en 0 y 1.
¿Puedes hablarnos sobre sistemas de bases de datos (SQL y NoSQL) y del enfoque de servidores que usas (clásico, serverless)?
Con respecto a SQL y NoSQL, al final es cuestión de elegir la mejor herramienta para el trabajo correcto como comentaba anteriormente. Bases de datos relacionales (SQL) es lo que se enseñaba en mis tiempos y es lo más natural para mí, porque son simples de entender, los datos se almacenan en tablas y se pueden usar transacciones cuando se manipulan esos datos. Las NoSQL son basadas en documentos (muchas veces sin ninguna estructura fija) y se accede mediante Clave/Valor.
Una gran diferencia viene en cuanto a la escalabilidad, ya que las SQL escalan fácilmente verticalmente, o sea agregando más potencia a los servidores que los alojan. Se puede escalar horizontalmente también, pero se requiere de más lógica y complejidad.
Las NoSQL escalan fácilmente horizontalmente, lo que implica agregar más computadores. Esto es una ventaja ya que no estamos limitado como en la escalabilidad vertical. Hay casos de uso para cada uno, incluso combinaciones, pero eso será cuestión de plantear el problema y elegir el modelo correcto.
Tengo que decir también que lo mismo pasa por distintos enfoques en cuanto a servidores, no hay una bala de plata que resuelva todos los problemas. Eso sí, mi consejo es siempre dividir el problema grande en pedacitos más pequeños, empezar simple y moverse poco a poco hacia el lado de la complejidad.
Por ejemplo, no iría con microservicios de entrada al empezar un proyecto nuevo, sino que empezaría usando un framework monolítico y haciendo refactor poco a poco. Digamos que hay que iterar y mejorar continuamente.
¿Qué opinas de lenguajes como Kotlin y en qué lugar crees que quedará Java?
Personalmente me gusta mucho Kotlin, es un lenguaje que ofrece tanto programación orientada a objetos como funcional. Es nuevo, hay mucha comunidad y está creciendo muchísimo.
Agregar también que es fácil de entender y aprender y uno enseguida se siento proactivo con él. Java sigue estando y estará ahí por mucho tiempo. Tiene un gran mercado y también ha ido evolucionando. Es verdad que muchos otros lenguajes le han comido territorio, pero no veo cerca su fin. Está para quedarse por mucho tiempo en mi opinión.
¿Por qué te has centrado en Android y no en otro sistema operativo?
Hay algunas cosas que en su momento me llamaron la atención, como por ejemplo que estaba basado en Linux y open source. Fue sobre todo una apuesta, más allá de que me gustara el mundo mobile, decidí ir principalmente por Android y no por iOS. En los últimos años sí que he hecho algo de iOS también y como siempre digo, no hay que cerrarse ni casarse con ninguna tecnología.
¿Usas fragments o activities? ¿Por qué?
Uso fragments embebidos en activities porque conozco el approach. En los últimos años se han intentado otras maneras sin demasiado éxito. El hecho de que oficialmente Google lo soporte también me da más tranquilidad al elegir los componentes que uso a nivel framework.
También pienso que usar activities solamente no está mal, para nada… Es una cuestión de gustos. En su día era complicado por los ciclos de vida que eran difíciles de manipular, especialmente al cambiar el dispositivo de orientación. Actualmente gran parte de este tipo de problemas está solucionado con Android Architect Components.
¿Prefieres Java o Kotlin?
Como te comentaba en la pregunta anterior, si tengo que elegir voy por Kotlin porque es conciso, no verboso y fácil de usar. Pero si me toca hacer Java, ningún problema, he crecido con él, aparte que hay que agregar que la interoperabilidad entre ambos lenguajes es casi perfecta. Ambos funcionan juntos sin ningún problema. Desde Kotlin podemos llamar o usar clases y métodos en Java y viceversa.
¿Puedes hablarnos de Kotlin como un híbrido compilado para iOS y Android?
No tengo mucho conocimiento en este ámbito, pero hay tantas soluciones «cross-platform» que intentan cubrir ambas plataformas escribiendo código una sola vez, como Flutter, React Native, Xamarin o web frameworks usando el concepto de Web Progressive Apps. Que en un momento se pueda hacer algo así con Kotlin creo que siempre es un punto a favor del lenguaje y su comunidad.
¿Con qué IDE programas en Android? ¿Por qué?
Con Android Studio. Es el oficial y como está basado en Intellij, el cual vengo usando años, me siento muy familiarizado con su entorno.
En caso de Android Studio, ¿cómo te afectan ciertas ralentizaciones que tiene el IDE?
No creo que sea tan así. No hay IDE perfecto por supuesto. Hay muchos factores que influyen en que un proyecto no compile rápido, por ejemplo, y muchísimas veces nosotros somos los culpables de ello, porque agregamos dependencias innecesarias o nuestro código no está bien del todo organizado, etc.
