Mis primeros meses en D!
El comienzo
Entré a trabajar a Despegar como Software Developer III en noviembre de 2021. Al momento de hacer el proceso, contaba con un año de experiencia como desarrollador MERN Ssr (MongoDB, React JS, Express JS y Node JS) en una empresa de producto SaaS.
Este es un resumen de mi experiencia, tanto laboral como personal desde que ingresé.
Las Entrevistas
El proceso de entrevistas, desde el primer contacto hasta la oferta formal, duró aproximadamente tres semanas. En todo momento RRHH fue proactivo en pedirme franjas de disponibilidad horaria, sugerir fechas para la próxima entrevista y pedirme feedback luego de las mismas.
Hubo dos entrevistas técnicas: la primera con entrevistadores desarrolladores, la segunda con mánagers técnicos de la gerencia donde entraría a trabajar.
En ambas me hicieron preguntas técnicas, tanto conceptuales como sobre herramientas que concretamente usa Despegar (Java, Scala), y challengearon mi experiencia previa.
En la primera entrevista conversamos bastante sobre mi forma de trabajo y cómo encaré situaciones complejas que se dan en el día a día como desarrollador. Las preguntas apuntaban a evaluar si mi forma de trabajar era compatible con lo que hacen en Despegar.
Luego resolvimos un ejercicio de diseño OOP. Digo “resolvimos” porque, si bien era claro que me estaban evaluando, el approach de los entrevistadores fue muy colaborativo. Llegamos a una solución parcial pero bastante charlada, incluso hablando de tradeoffs y alguna que otra buena práctica.
Destaco dos cuestiones: 1) pude conocer acerca de la gerencia, tanto del lado técnico como de negocio, y 2) los mánagers son además referentes técnicos y no se limitan a gestionar.
Asimismo, tuve la oportunidad de preguntar y conocer lo básico acerca de los desafíos técnicos y de negocio que afronta Despegar: volumen de ventas, alto tráfico de red/requests, competencia en un rubro muy afectado por la pandemia de COVID, etc.
El Equipo
El onboarding fue muy grato; el equipo se ocupó con anticipación de todo de forma que desde el primer día mi ocupación fue -casi totalmente- técnica y abocada a mi rol de desarrollador.
El equipo está formado por profesionales de amplia experiencia laboral, y en general de larga trayectoria en Despegar (5–8+ años). Esto es una gran oportunidad personal, porque significa aprender constantemente y adoptar sus formas de trabajar.
Técnicamente, algunos integrantes están especializados en backend, y otros en frontend. Si bien cualquiera puede tomar una tarea a lo largo del stack, tener compañeros especialistas eleva la calidad del código y las code reviews.
El equipo en general es muy responsable y casi siempre está presente para actuar ante alertas o cambios en la calidad del servicio; esto es clave dado que no hay guardias, pero se espera que respondamos con rapidez.
En mi opinión la directiva y gerencia de Despegar está a favor de la cultura de oficina, y si bien como equipo estamos haciendo trabajo 100% remoto (80% en mi caso por decisión propia), la oficina siempre está disponible y se fomenta ir. La oficina de Puerto Madero tiene un ambiente excelente y unas instalaciones muy lindas.
Líderes
Tanto el manager de equipo como el senior manager son profesionales técnicos. El manager de equipo no solo gestiona, sino que codea y además lo hace eficientemente. El senior manager toma parte en decisiones de arquitectura que después bajan al equipo y terminamos consensuando.
Siento que me dieron un lugar en el equipo y stories que son de importancia en producción aunque tenga menos experiencia que el resto, lo cual es muy valorable.
Todos los gerentes que conocí en Despegar tienen background técnico y se podrían sentar a codear una story conmigo. Además “suben la vara” a los equipos, sugiriendo y participando cada tanto.
Negocio
Producto
A nuestro lado está el equipo de Producto, el cual vela por los servicios que brindamos. Además de hacer lo que todo equipo de Producto, colaboran muchísimo a la hora de responder dudas o problemas que nos llegan de terceros, ya que a veces conocen mejor que nosotros las reglas de negocio y la letra chica de cada caso de uso.
Tener un equipo de Producto experimentado es clave para preservar el conocimiento que se tiene acerca del funcionamiento de los servicios. Como oportunidad de mejora, me gustaría encontrar la forma de hacer esto mismo en sistemas. Si bien existe documentación y wikis, con la rotación de líderes o traspaso de equipo se suele perder algo de conocimiento.
Métricas
En Despegar se fomenta hablar en términos de tradeoffs antes de preferencias o gusto personal; pero sobre todo, se busca medir impacto y generar evidencias a través de métricas.
Una nueva feature resulta mucho más atractiva para todos los involucrados si se estima su impacto económico o en tiempos; también, una historia técnica que acorta los tiempos de respuesta aporta valor porque termina impactando en las compras del cliente final. A su vez, si hubo un error (tanto técnico como de negocio) se busca lo ya afectado para estimar pérdidas, y el universo posible del error para darle prioridad y dimensionarlo.
SLA
La gerencia en la cual entré es muy “de producto”. Dentro de los equipos priorizamos la robustez, la tolerancia a fallas y el throughput ante todo, porque una caída o degradación de los servicios implica afectar negativamente métricas de nuestros usuarios y de la empresa.
Ownership
Los puntos anteriores me llevan a decir que generamos software del cual tenemos ownership, sobre el cual tomamos nuestras propias decisiones. Somos dueños del roadmap de lo que hacemos, y podemos sugerir mejoras técnicas con el fin de optimizar servicios.
Vale aclarar que, si bien IT es un sponsor más dentro de la empresa, existen sponsors con drivers mas comerciales que nosotros (por ejemplo, otro sector sugiriendo una feature nueva que aumenta el revenue o una integración con un tercero que amplía la oferta de productos en Despegar).
Cuestiones técnicas
Elección de tecnologías
En el backend, Despegar apuesta por lenguajes de JVM (Java, Scala, Kotlin) o TypeScript, e innova con Rust y Scala puramente funcional. También hay equipos de Machine Learning que usan otros lenguajes como Python. En el frontend, se usa tanto Angular como React. En el stack hay infinitas tecnologías (MariaDB, Cassandra, Redis, Hazelcast, etc) que se eligen dependiendo el caso de uso a resolver.
Más allá de las tecnologías mencionadas, el propósito al elegirlas es correr el negocio sobre plataformas battle-tested y no reinventar la rueda, siendo robustos y modernos a la vez. Considero que no se puede hacer software en escala si se eligen tecnologías que se rompen en producción, tipadas dinámicamente; y que dormir bien sabiendo que no va a volar todo por los aires es parte del criterio.
Ambientes
Contamos con tres ambientes: beta, producción y sandbox. Todos los ambientes cuentan con persistencia, logging, datos, clusters y DBs propias en la gran mayoría de los casos.
Tener un ambiente beta nos resulta muy conveniente, porque nos permite subir una versión de uno o más servicios y probarlo contra todo el stack cross-equipos de beta con mucha tranquilidad antes de subir a producción.
Tener un ambiente sandbox permite que otros equipos hagan pruebas y nos permite reproducir errores de forma casi idéntica a producción sin tener efecto en los datos reales. Es un ambiente muy oportuno para cuando llega cualquier bug al equipo.
Mantener estos ambientes también tiene un costo, pero considero que las ventajas superan la carga de mantenerlos.
Metodología de desarrollo
Usamos Jira con un board Kanban para crear y seguir el estado de las tareas. Seguimos un proceso en el que debemos contar con una aprobación de nuestro código por code review en Github. Luego se procede a deployar en los ambientes y entregar la story.
Tenemos desacoplado el pusheo a Github de la generación de binarios o deploy a cualquier ambiente. Esto trae como ventaja un proceso de deploy más flexible (podemos volver a versiones viejas usando los binarios anteriores y master siempre está limpio), pero tenemos que coordinar la salida de versiones cuando tenemos más de un PR pendiente.
Documentación y testing
Si bien no existe mucha documentación individual sobre los servicios que tenemos, hay documentación sobre el stack en general y la interacción entre las distintas partes. A veces las wikis quedan un poco deprecadas, sobre todo la parte de setup.
Nos debemos como equipo mantener las wikis, porque si bien “sabemos” cómo funcionan algunas cosas, el onboarding podría ser más eficiente y ameno si estuvieran al día.
Algunos servicios generan manuales de Swagger, es algo que me parece muy potente y acelera mucho programar contra otros servicios.
Solemos hacer bastantes tests unitarios, con algunos casos contados donde no se hacen o se dejan de lado. Hubo ocasiones en las que elegí arreglar los tests de un servicio para tenerlos en verde y que tengan sentido, porque no siempre corremos los tests antes de sacar una versión nueva.
Estamos trabajando en mejorar los tests de integración; tenemos algunos que son imposibles de correr o no son determinísticos.
No pedimos cobertura mínima y aceptamos romper reglas de SonarQube.
Monitoreo
Considero que estamos muy sólidos en este apartado: contamos con algunas herramientas clave para ser eficientes y que todo se mantenga feliz.
La enorme mayoría de los servicios tienen integrado New Relic. Me parece fantástico porque le damos mucha importancia e intentamos tener una tasa de error de 0%, para que cuando se alerte un servicio realmente esté pasando algo crítico. Usamos parámetros personalizados y distintos tableros para darnos idea de la situación pudiendo filtrar por instancia, ruta, request, agente, etc.
Tenemos alertas de Nagios que complementan muy bien a NR, ya que nos dan información de más bajo nivel, por ejemplo CPU, memoria, disco, network, percentiles de tiempos de respuesta por ruta y además monitorear estas métricas en tiempo real para cada instancia, lo que ayuda a diagnosticar algunos problemas más específicos.
Logging
Usamos frameworks de logging como logback o log4j, que son maduros y bastante performantes. Tenemos configurados en cada request unos IDs para poder trazar lo que fue loggeando a través de todos los servicios que intervengan.
Además, por servicio por ambiente, se loguea a un servicio de logs cloud que guarda el histórico de logs por algunas semanas, pudiendo grepear en vivo o en logs anteriores lo que sea necesario.
Estas cuestiones hacen que nuestro trabajo debuggeando sea mucho más ameno y productivo, en contraposición a loggear a stdout sin trazabilidad ni historia.
Estándar de código
Considero que el nivel de código es muy bueno. Cada tanto aparecen casos en los que alguien llevó al extremo el uso de Scala con case classes y terminó con un dominio anémico, o quien sobrediseñó en Java con boilerplate cuando con un estilo funcional podría haberse resuelto en menos líneas; pero esto es fácil de decir con el diario del lunes.
No vi ningún servicio que baje de Java 8 y se fomenta el uso de Java 17 para servicios nuevos, lo cual me parece bastante sano.
Se usan APIs “modernas” como Time, Stream, CompletableFuture en contraposición a Joda, loops y Future. Cuando Java queda corto, se recurren a bibliotecas battle-tested como Guava o partes de Spring que están más que probadas y documentadas.
En Scala tenemos cosas con Play Framework, el cual estamos deprecando y refactorizando a cosas con otros framework de Scala o Java.
Tenemos una app frontend nueva en Angular, lo que implica un front bastante maduro con responsabilidades bien diferenciadas.
Extras y buenas prácticas
Algunas costumbres o prácticas que me encontré en la empresa que me parecen para destacar:
- Discord: tenemos un servidor donde solo hablamos de tecnología. Se comparten noticias y artículos de tecnología interesantes. Además, si alguien tiene alguna duda o problema se puede consultar y encontrar ayuda sobre un tema puntual sin importar en qué equipo se esté.
- Postmortems: inevitablemente algo se va a romper, alguien va a equivocarse. Lo importante no es nunca cometer errores, sino aprender para evitarlos en el futuro. Por eso siempre se arman y comparten post mortems, que son documentos donde se detalla causa, efecto y solución ante problemas reales en los equipos que suelen implicar downtime o errores fuertes. Esto es una fuente de aprendizaje de las más cercanas a la realidad.
- Comité Técnico: existe un comité técnico que se dedica a estandarizar, sugerir buenas prácticas y conducir la adopción de tecnologías. Recientemente lanzaron un template de Java 17 muy interesante con muchas decisiones tomadas y partes tediosas ya hechas (logging, NR, packages, bibliotecas, módulos), pero sin sacarle flexibilidad al equipo que lo consume.
- Charlas técnicas: en la gerencia se apunta a que haya una charla técnica por semana. Se tratan tanto temas internos como externos de tecnología, y no solo es un espacio técnico sino que conocemos al resto de la gerencia y la idea es hacer debate, comentar dudas, etc.
5 meses después
Despegar tiene las siguientes “máximas de excelencia”:
1. Proactividad
2. Accountability y ownership
3. Confiabilidad
4. Disciplina de ejecución
5. Priorización continua y explícita
Y la realidad es que no las tuve en cuenta mientras escribía todo esto, pero parece que incidentalmente pasé por todas. Considero que estas 5 son muy buenos ejemplos de mi experiencia en la empresa, porque lejos de ser un slogan, son parte de la cultura que he podido ver en el día a día, son lo que me transmiten mis compañeros y aprendo con cada interacción con ellos.
