Control de versiones para Data Engineers
Cloud Practitioner vs Solutions Architect | El rey que amó mas el viaje que el destino
Lo que vas a ver en esta edición:
Herramienta casi obligatoria para todo Data Engineer
Cuál certificación de AWS elegir
Una lección sobre amar el proceso
Y la importancia del mensaje al hacer commits
🧠 El Núcleo
Control de versiones para Data Engineers
En más de una oportunidad y en distintos espacios (X, LinkedIn, mi blog, esta newsletter) he mencionado que una de las habilidades más importantes para un/a Data Engineer es su capacidad de escribir código de calidad listo para producción.
Esto implica muchas cosas, como la legibilidad, manteniblidad, escalabilidad, pero también algo que suele pasarse por alto: saber versionarlo.
Escribir código es importante
Pero igual de importante es llevar un rastro de los cambios en dicho código
Imagina esto:
Agregás algo nuevo y sin darte cuenta rompés otra parte del proyecto. Querés volver todo atrás.
Querés probar un cambio sin arruinar lo que ya funciona.
Tu computadora se rompe y necesitás retomar tu trabajo en otra máquina.
Tenés que colaborar con alguien más y ambos trabajan sobre diferentes partes del mismo proyecto.
He aquí la herramienta para solucionar estas situaciones y muchas otras: el controlador de versiones.
La herramienta clave
Existen varios controladores de versiones, pero el estándar de facto es Git. No sé si puedo llegar a transmitir la suficiente importancia que tiene Git en el desarrollo de software.
Insisto, por más que tu tarea como Data Engineer a lo mejor no involucre demasiado código, ese código tiene que (idealmente) estar versionado.
En la práctica, con Git podés:
Guardar “fotografías” de tu proyecto (commits) en diferentes momentos de tiempo.
Probar cosas nuevas sin miedo creando ramas (branches).
Colaborar fácilmente con otros ingenieros/as sin pisarse el trabajo.
Volver atrás en el tiempo cuando algo se rompe (acá es donde Volver al Futuro te puede servir (?.
Automatizar despliegues (CI/CD) y buenas prácticas de integración.
Ahora, a lo mejor pienses: “pero yo no soy developer, trabajo con datos”.
Está perfecto, pero justamente por eso tu trabajo también requiere orden:
Pipelines de ETL, scripts de Python, queries de SQL complejas → todo debería estar en Git.
Tu equipo necesita saber qué cambió, cuándo y por qué.
Si trabajás en un entorno corporativo, es muy probable que tu código se despliegue en producción. Y en producción no hay lugar para improvisación.
Además versionar todo el código que escribas no solo es una medida de protección (para vos, tus compañeros, el negocio), sino que te da profesionalismo: demuestra que tratás tus proyectos con la seriedad que merecen.
¿Por dónde empezar?
Si nunca usaste Git, arrancá con estos básicos:
git init→ crear un repositoriogit add→ preparar archivos para guardargit commit -m "mensaje"→ guardar un cambio (tomar la “foto”)git status→ ver qué cambiógit log→ revisar el historial
Después avanzá a conceptos como branches, merge y pull requests, que son el corazón del trabajo colaborativo.
Como todo esto puede quedar muy pero muy abstracto, te voy a pasar el curso donde yo aprendí Git y GitHub (que no son lo mismo, ojo con eso en las entrevistas) unos años atrás.
Ni siquiera voy a molestarme en presentar a su instructor. Es el Mesías del aprendizaje online y deberías conocerlo a esta altura (?
GIT+GitHub: Todo un sistema de control de versiones de cero
¿Porqué lo recomiendo?
Como dije, muy buen instructor
Ejemplos muy didácticos sin vueltas ni explicaciones complejas
Muchos ejemplos y tareas (a versionar se aprende versionando)
Lo que quiero que te lleves
Nuestro trabajo como Data Engineers consiste en construir sistemas robustos, eficientes, escalables y, de ser posible, versionados.
Todo el código que produzcas, ya sean pipelines, scripts, queries, es igual de importante y valioso que cualquier otra app.
Cuidalos.
☁️ La Senda del Nubearquitecto
¿Cloud Practitioner o Solutions Architect?
En anteriores ediciones de esta newsletter vimos:
Razones para arrancar tu camino en la nube mediante AWS
Primeros pasos para introducirte en este proveedor de la nube pública
Ahora querés ir un paso más allá: querés certificarte.
Querés demostrar que tenés las habilidades que se requieren para moverte con profesionalismo y excelencia en AWS. Bueno, bienvenido/a al mundo de las certificaciones.
AWS tiene varias, orientadas a distintos públicos, niveles de habilidad y roles dentro de IT. En la edición de hoy nos vamos a concentrar en dos en particular: Cloud Practitioner y Solutions Architect Associate.
La pregunta del millón es: ¿cuál te conviene?
¿Qué piden en cada una?
¿Hay alguna que tenga más peso? ¿O son más o menos lo mismo?
¿Hay que aprobar una para recién poder ir por la otra?
Todas preguntas que son realmente válidas. A fin de cuentas, uno quiere aprovechar sus recursos (como tiempo y dinero) al máximo. Vamos a resolver estas cuestiones.
Cloud Practitioner o CLF-C02
Perfecta para personas nuevas en AWS y Cloud Computing en general
Conceptos fundamentales de AWS y su estructura de precios
Orientada a profesionales administrativos o roles no técnicos
Sirve de base para certificaciones más avanzadas
No requiere conocimientos previos de AWS o la nube en general
Solutions Architect Associate o SAA-C03
Abarca conocimientos bastante más avanzados de AWS
Tal como su nombre lo indica, se empiezan a ver conceptos de arquitectura en la nube
patrones de diseño
conceptos avanzados de seguridad
escalabilidad y alta disponibilidad
optimización de costos
Enfocada hacia un rol mucho más sofisticado y técnico
Necesaria para certificaciones de especialización
Se requieren habilidades técnicas previas, cierta experiencia práctica con los servicios de AWS y una base mínima de principios de diseño en la nube
¿Y la Data Engineer Associate (DEA-C01)?
Si estás en esta newsletter, es porque sos Data Engineer o estás pensando en transicionar a este rol (o a lo mejor viniste para robarme ideas). En cualquier caso, probablemente te estés preguntando por la Data Engineer Associate.
Esta certificación apareció en 2024 y vino a llenar un hueco muy importante: hasta ahora no había una credencial oficial de AWS que reconociera de forma directa las habilidades necesarias para desempeñar el rol de Data Engineer en la nube.
¿Qué incluye?
Fundamentos de arquitectura en AWS aplicados al ciclo de vida de los datos
Modelado, ingestión y transformación de datos en servicios como S3, Glue, EMR, Redshift y Kinesis
Diseño de pipelines eficientes y seguros
Gobernanza y buenas prácticas en el manejo de datos
Principios de seguridad y optimización de costos enfocados en el trabajo con datos
En otras palabras: mientras que la SAA valida que entendés cómo armar soluciones completas en AWS, la DEA valida que sabés cómo mover, transformar y gobernar datos en esa infraestructura.
Entonces, ¿por cuál voy?
Está claro que elegir una de estas certificaciones depende muchos de tus objetivos profesionales y tus habilidades técnicas actuales.
¿Qué fue lo que hice yo? Bueno, mi caso es algo particular.
Como comenté en una edición anterior, a mí me toco familiarizarme con AWS un poco a las trompadas. Me “tiraron a la cancha” y si bien al principio me guiaron y supervisaron, varias cosas tuve que hacerlas guiándome de la documentación y con algo de miedo jeje.
Pero todo eso me enseñó muchísimo y si bien me interioricé con los conceptos de la Cloud Pracitioner mediante varios cursos de Datacamp, decidí irme de lleno por la SAA.
Mi recomendación para vos es:
si sos completamente nuevo en AWS → arrancá por Cloud Practitioner. Te da una base sólida sin abrumarte
si ya tenés base técnica (ej: desarrollador backend, data analyst, sysadmin) → saltá directamente a Solutions Architect Associate (SAA)
Si ya trabajás con datos y querés enfocar tu perfil en Ingeniería de Datos → la Data Engineer Associate (DEA) puede ser tu mejor jugada, incluso como primera certificación, siempre que tengas algo de práctica previa en AWS
Una cosa es clara: sea cual sea la certificación que elijas, hay muchas horas de estudio, práctica y error por delante.
Que eso no te frene. Certificarte en una nube como la de AWS puede abrirte muchas puertas y realmente te convierte en un perfil muy interesante para el mercado IT.
Espero que este apartado haya arrojado algo de luz para que puedas tomar una buena decisión.
💭 Debug Mental
El futuro rey que amó más el viaje que el destino
Te voy a contar algo de mi que no creo que te sorprenda: me gusta el animé.
No me considero un super fan igual eh. No he visto demasiados, pero los que vi me han impactado en más de un sentido, de alguna u otra forma, siendo One Piece el que más me ha afectado.
Quizá lo viste, quizá lo estás viendo (asi que, intentaré transmitir una moraleja sin spoilers) o quizá escuchaste de este anime. En cualquiera de estos casos, seguro conoces al querido Luffy.
De entrada este loco plantea su objetivo primordial en la vida: ser el rey de los piratas, y para ello debe encontrar el One Piece.
Bueno, no era el único con esa meta. Muchos otros piratas querían lograrlo por la fama, la riqueza, el prestigio. Luffy solamente quería serlo por una razón: la aventura.
En varias parte del animé esto queda en evidencia. No le importan los lujos, la riqueza (aunque sabe que si quiere comida o un barco en condiciones necesita dinero), ni siquiera las mujeres.
Él quiere la aventura, la carne, los compañeros, recorrer el mar, la carne, desentrañar el misterio del One Piece, superarse a sí mismo y ah sí, la carne.
Ahora bien, en un punto de todo este viaje, tanto Luffy como su querida tripulación se encuentran con un personaje importantísimo que clama saber la ubicación del One Piece. Y no, este personaje no está mintiendo. Realmente lo sabe. El animé se encarga de hacerte saber que lo sabe.
Frente a semejante afirmación, Usopp (compañero de tripulación de Luffy) decide preguntar dónde está el objeto que ha provocado que una incontable cantidad de piratas hayan decidido surcar los mares a costa de sus propias vidas, víctimas de una fiebre que no tiene precedente.
Apenas formulada la pregunta, y sin que el personaje que sabe su ubicación pudiera siquiera mover los labios para pronunciar respuesta, Luffy decide gritarle a Usopp con una furia incomensurable.
Uno pudiera pensar: “Amigo, te están por revelar algo que es clave, algo que podría darte la verdadera ventaja por sobre los demás piratas que están en la búsqueda del mismo objetivo”.
Pero no. Citando al propio Luffy:
He aquí una de las escenas que más me han impactado del animé (y son varias eh).
Algo que me marcó y me hizo ver que un flaquito que se estira como la goma tiene algo más poderoso que una fruta del diablo en su interior: su capacidad insuperable de amar el esfuerzo, el proceso y el viaje, más que el premio, la recompensa y el destino.
¿Podemos ser como Luffy? ¿Puedo ser yo como Luffy?
¿Puedo concentrarme más en lo que tengo entre manos, en mi propia transición, en los pasos que doy cada día hacia lo que considero mi “One Piece”?
¿Puedo enamorarme de los desafíos que voy encontrando y del progreso que evidencia mi capacidad de superarlos a todos y cada uno?
¿Puedo darme el permiso que se requiere para lamentar las derrotas sin que eso me hunda y me impida volver a darle brillo a mis ojos, pensando en lo que tengo por delante?
¿Puedo ser capaz de ver lo que tengo por delante, sin que me abrume ni me frene?
¿Puedo hallar plenitud y paz en mi propio viaje, sin que me preocupe demasiado si otros llegan antes que yo?
¿Quiero acaso tener una aventura tan aburrida?
Es un animé. Es ficción. Es tan solo un personaje.
Y he ahí una lección que nosotros, humanos de carne y hueso que habitamos el mundo físico, parece que aún no podemos aprender ni dominar.
Pero hemos de intentar. Yo sé que voy a intentarlo.
Aprendamos del futuro rey (y digo futuro porqué incluso despues de más de 30 años, Luffy aun no logra su ansiado objetivo) que amó más el viaje que el destino.
📚 Datazo
Que tu commit de Git hable por vos + Bonus
Si antes vimos la importancia de usar Git, ahora nos queda charlar brevemente sobre un componente vital del mismo: los commits, o más bien, los mensajes que acompañan a dichos commits.
Imaginate que tu proyecto crece. ¿Te gustaría navegar por cientos o miles de commits con nombres poco o nada descriptivos?
Querés “viajar en el tiempo” e ir a un commit en especifico, pero no tenés mucha idea de qué pasó en ese cambio. Solo ves ‘bug arreglado’ o ‘fix login’.
O estás trabajando en equipo, y tus compañeros tienen que leer sí o sí todos los cambios en tu commit porque sino no tienen ni idea de qué va el cambio ya que el mensaje que dejaste no describe nada.
Por fa, no seas así.
Que tu commit de Git hable por vos. ¿Cómo lograrlo?
Hace un tiempo atrás escribí sobre esto en mi blog con la esperanza de contribuir, no solo a tu viaje como profesional IT, sino también a un mundo tech donde todos los que trabajamos con código y control de versiones seamos descriptivos con nuestros commits.
Todo buen programador es también un buen colaborador.
Tus compañeros, e incluso tu versión del futuro, te lo van a agradecer.
Bonus
Y de yapa (una palabrita que usamos en Argentina para referirnos a “extra”, “bonus”, etc.), te comparto una cheatsheet oficial con comandos en Git, como para darle un cierre ideal a todo lo que hablamos hoy del tema. ¡Espero te sea de utilidad!