Gabriel Ortuño, Principal Software Engineer en Cabify

Hola Gabriel, ¿nos cuentas brevemente quién eres?

Hola! Me llamo Gabriel Ortuño, vivo en Madrid, aunque soy de San Fernando (Cádiz), y estudié en la UCA la carrera de informática.

Actualmente trabajo en Cabify como ingeniero construyendo un nuevo producto para mejorar la gestión de las flotas de conductores.

¿Cómo entraste en contacto con el mundo de la informática y la programación?

La verdad es que desde muy pequeño me llamaron mucho la atención las consolas y los ordenadores. Me compraron mi primer ordenador cuando comencé el instituto y desde entonces tuve muy claro que lo que quería estudiar era informática.

Durante aquella época empecé a hacer páginas webs, sin tener ni idea de programación y usando cualquier software que te permitiera hacer webs de una forma más o menos visual.

Cuando entré en la carrera fue cuando aprendí a programar de verdad usando C. Fue algo que me enganchó de inmediato, y a lo que dedicaba la mayor parte del tiempo que estudiaba en casa. Al acabar el primer año, de las pocas asignaturas que aprobé fue la introducción a la programación. 

Viviendo todavía en San Fernando encontré mis primeros trabajos como programador haciendo software para comercios, primero en una inmobiliaria y luego colaborando con un compañero de carrera en un software para una librería.

Cuando terminé la carrera, tenía claro que quería salir de Cádiz, y trabajar en alguna empresa donde poder aprender de los compañeros. Así que estuve echando currículums como un loco hasta que al final me llamaron desde Madrid.

Entré en una pequeña factoría de software que hacía aplicaciones para bancos. Después de 3 meses, mi compañero de piso me pasó una oferta de una nueva startup que buscaba programadores de front y me lancé. Y así es como entré 11870.com donde conocí a grandes compañeros y aprendí en qué consiste realmente este oficio.

¿A qué te dedicas a día de hoy?

Actualmente trabajo en el equipo de Driver Fleet encargado de desarrollar un nuevo producto para la gestión de flotas que acabamos de lanzar oficialmente a principios de Junio en España.

Ahora mismo estoy centrado en el backend, en donde usamos Elixir como lenguaje principal, aunque también hago cosas en Ruby de vez en cuando porque Cabify fue desarrollado originalmente en este lenguaje y todavía existe un servicio monolítico que tenemos que mantener.

¿Cómo es un día típico en tu trabajo?

Mi rutina suele consistir en, nada más llegar revisar los correos y mensajes en slack para estar al día, revisar pull request de compañeros y revisar issues o comentarios en documentos del día anterior. Finalmente suelo empezar a realizar algunas de las tareas que hemos planificado durante nuestro sprint planning.

Es habitual que durante el día surjan dudas sobre las tareas que estamos haciendo en ese momento, por lo que solemos improvisar algunas reuniones rápidas para resolverlas.

Además, durante la semana hay distintas reuniones planificadas: para discutir algún tema con algún equipo, planificación de tareas, entrevistas, la reunión semanal del equipo de producto, etc...

¿Qué es lo que más te motiva de tu trabajo (en Cabify)?

Cabify es ya una empresa muy grande con una buena base de usuarios, así que cada funcionalidad que saques puedes mejorar la calidad de vida de los conductores o de los pasajeros.

En el caso de mi equipo, la aplicación de gestión de flotas que acabamos de lanzar, pretende mejorar la forma en la que todas las empresas VTC que trabajan con Cabify pueden gestionar a sus conductores, ofreciendo información en tiempo real de su posición, los viajes que han hecho y el dinero que han obtenido. Además, ofrece informes sobre el rendimiento de los conductores que permiten al manager saber exactamente en qué tiene que mejorar cada uno de ellos. Es decir, que es una herramienta que aportará un gran beneficio a las empresas VTC y a Cabify.

En el equipo de producto trabajan unas 250 personas, entre ingenieros, product managers, diseñadores, y el equipo de datos. El nivel técnico en general es muy alto, y las herramientas se van evolucionando o cambiando constantemente, por lo que tienes la suerte de poder aprender constantemente cosas nuevas y los retos que existen son infinitos.

¿Cómo es vuestro departamento de ingeniería y cómo es vuestro proceso de desarrollo de software?

Cabify se organiza en diferentes grupos por verticales de negocio y dentro de cada grupo hay una serie de squads. Cada squad tiene libertad de decidir cómo trabaja, así que es imposible generalizar. 

En el caso particular de mi equipo, hacemos sprints de 3 semanas. Antes de la reunión de planificación, tenemos una reunión donde revisamos todas las features nuevas que tenemos que implementar, las analizamos, discutimos, y sacamos una lista de tareas con estimaciones de lo que tenemos que hacer.

En la reunión de planificación, la product manager elige las features que más le interesa, sin sobrepasar el límite de puntos que hacemos en un sprint y las prioriza.

Cuando acaba el sprint solemos hacer la típica reunión de retrospectiva donde analizamos cómo hemos hecho las cosas durante el sprint.

A parte de eso, tenemos una reunión bisemanal en la que hablamos solamente temas técnicos, cosas que vemos que queremos mejorar o que hay pendientes de hacer.

¿Cuál es el reto más interesante al que te has enfrentado en tu carrera profesional?

Para mi el reto más interesante al que me he enfrentado ha sido cuando Cabify se fusionó con EasyTaxi. Fue un proyecto que llevó más de un año en completar y que estuvo involucrada mucha gente de ambas empresas.

Concretamente yo estuve al cargo de un proyecto en el que hicimos un servicio que recibía solicitudes de viajes desde la app de cabify, y la enviaba al backend de EasyTaxi, luego debía mantener sincronizadas las 2 plataformas para que tanto el pasajero con la app de Cabify, como el conductor con al de Easy viesen la misma información. El objetivo era tener cuanto antes las 2 plataformas en la app de Cabify, para la migración de usuarios que se había planificado más adelante.

El reto inicialmente fue más humano que tecnológico, ya que debíamos coordinarnos con un equipo en Sao Paulo que trabajaba con 5 horas de diferencia con nosotros y cuando surgía algún problema por la tarde debíamos esperar hasta el día siguiente para poder resolverlo.

Por otro lado, las máquinas de estados de Cabify y EasyTaxi eran completamente diferentes y costaba encontrar una fuente fiable de información sobre cómo funcionaba la de Easy, así que muchas cosas que hicimos tuvieron que ser a base de prueba y error.

Mi trabajo ahí era el de coordinarme con el equipo de Brasil y trasladar esta información a mi equipo, convertirla en tarjetas y comprobar que todo funcionaba como se esperaba.

Cuando se empezó a mover todo el tráfico de EasyTaxi sobre esta nueva aplicación, hubo bastantes problemas de escalabilidad, y raro fue lo que no se rompiera en algún momento, tanto por nuestro lado como por el de Easy.

Al final todo salió bastante bien y se consiguió migrar un gran porcentaje de usuarios y conductores de Easy a nuestra plataforma, así que el trabajo duro mereció la pena.

Llevas muchos años trabajando con Ruby on Rails… ¿Sigues trabajando con esta tecnología? ¿En qué parte del stack te encuentras más cómodo?

La verdad es que todavía sigo trabajando con Ruby, aunque no es mi lenguaje principal. En Cabify, se decidió a finales de 2016 que queríamos romper el monolito en el que se había convertido la aplicación principal hecha con Ruby on Rails, y el lenguaje elegido para reemplazarlo fue Elixir, que en aquel momento era un lenguaje muy prometedor y la verdad es que nos ha ido bastante bien. Desde entonces se han hecho montones de servicios con Elixir y con Go, lo que ha permitido que la plataforma escalara mejor.

Yo particularmente me siento más cómodo en el backend, y hace mucho tiempo que no toco nada de front. Elixir es un lenguaje que me gusta bastante y con el que a día de hoy me siento más cómodo que con ruby.

Has trabajado en varias empresas de producto como Cabify, Jobandtalent, 11870, etc, y también en alguna empresa de consultoría... ¿Prefieres las empresas de producto? ¿Por qué?

Sin lugar a dudas, me decanto por las empresas de producto. Creo que el cariño y la dedicación que se le ponen a las cosas cuando es tu propio producto es muy superior a cuando es algo que tienes que hacer para otros. Además, al poder dedicar un periodo largo a un mismo producto te permite evolucionarlo más y llegar a retos de escalabilidad y mantenimiento que sería muy difícil que encuentres en proyectos a más corto plazo.

En cualquier caso, no todas las consultoras son iguales, y cuando decidí entrar en ASPgems lo hice porque me gustaba su cultura de empresa, la gente que tienen y han tenido en su plantilla son miembros destacados de la comunidad Ruby (por lo que pude aprender mucho). También tienen productos propios como NeuroK. Además, el tener varios proyectos al mismo tiempo y que los compañeros compartieran lo que aprendían de cada uno de ellos, hacía que pudieras evolucionar muy rápido.

En tu web, tienes varias notas sobre buenas prácticas para escribir código 👌, ¿cuáles son algunos de los principios clave que usas en tu día a día?

En cualquier proyecto de software que trabajes, la capacidad de poder mantener y evolucionar el código es fundamental. Nunca conoces los requisitos 100% antes de hacer algo, siempre va a ser necesario hacer cambios, mejoras, ajustes, etc… Además, no sueles trabajar sólo, por lo que el conocimiento de la base de código se va repartiendo entre cada uno de los miembros del equipo.

Por este motivo, para mi es fundamental que cuando se desarrollen cosas nuevas, se vaya documentando el proceso de decisiones que se van tomando, y en el momento de escribir código que se haga con un poco de cariño, pensando en que alguien después de ti va a necesitar leerlo y entenderlo. Por lo tanto, es muy importante que repasemos lo que hemos escrito, busquemos el mejor nombre posible para las funciones, variables, clases... y que extraigamos cada uno de los conceptos y responsabilidades de forma adecuada, para que sea fácil de entender lo que se pretende con cada línea código. No hace falta hacer que sea 100% genérico, hay que hacer que se adapte a las necesidades que tienes en ese momento y que sea fácil de extender en el futuro si es necesario.

¿Cuales son los recursos que más te han ayudado a convertirte en el (pedazo) profesional que eres hoy?

Para mi ha sido muy importante: por un lado haber caído en empresas con gente con un gran nivel, donde he aprendido un montón; por otro lado, aprender Ruby y conocer a la comunidad Ruby de Madrid, haber ido a conferencias como la Conferencia Rails o meetups como Madrid.rb, y tras las cuales me iba a casa super motivado para seguir aprendiendo.

Por supuesto, luego hay libros que te marcan más que otros como The Pragmatic Programmer de Andrew Hunt y Dave Thomas, The Passionate Programmer de Chad Fowler, el Refactoring de Martin Fowler y recientemente me ha gustado mucho 99 bottles of OOP de Sandi Metz.

¿Qué te gusta hacer para desconectar del trabajo/ pantalla?

Cuando estoy en casa, la mayor afición que tengo es cocinar, y paso bastante tiempo viendo recetas y haciendo experimentos.

Pero como todo no puede ser estar delante del ordenador y comer, hace 5 años me apunté en un gimnasio de artes marciales en Tetúan a practicar Kenpo Kai. Yo había practicado Karate de pequeño y tenía ganas de retomar aquello. Allí conocí a un grupo de gente genial, y me enganché a este deporte, y en Diciembre de 2019 conseguí aprobar mi examen de citurón negro. Esto, como te podrás imaginar, me permite hacer un poco de ejercicio y desestresarme bastante, además de pasármelo muy bien.

¿Cómo te ves dentro de 5 años?

Espero seguir haciendo más o menos lo que estoy haciendo ahora, porque es lo que realmente me gusta. Tampoco descarto dar el paso hacia el management, ya que es algo que he tenido ocasión de hacer en el pasado, y aunque es bastante duro, te aporta mucho a nivel personal.

¿Cómo y dónde podemos contactar contigo?

Podéis contactar conmigo por Twitter o en Linkedin.

Gracias 👏👏👏

Otras entrevistas interesantes

¿Quieres más? ¡Aquí tienes más entrevistas que te podrían interesar!

Vanessa Medina, FrontEnd Software Engineer en eDreams y co-fundadora de FrontFest

Escribió sus primeros GOTOs en un Amstrad CPC464. Comenzó siendo sysadmin, hasta que descubrió el desarrollo frontend. Trabaja en eDreams, organiza FrontFest, da charlas...

Oriol Barcelona, software engineer en Dynatrace

Escribió su primer programa antes de los 15 años y le apasiona su profesión. En Dynatrace, lidera un equipo de 4 personas, encargado de construir una UI para sus sistemas de persistencia.

Manuel Montenegro, software engineer en Personio

Manolo es Malagueño. Descubrió la programación en quinto de primaria. Hoy, su trabajo ayuda a que los empleados de los clientes de Personio cobren las nóminas a final de mes.
Suscribirme

¡Suscríbete!

Más de 900 desarrolladores/as reciben ya nuestras ofertas y contenidos para estar al día de cómo está el mercado y aprender de los mejores profesionales. Y tú, ¿te lo vas a perder?

¿Qué quieres que te enviemos?