¡Bienvenido/a a Debug Mental!

Reflexiones sobre mentalidad, hábitos y el costado humano de trabajar en tecnología. Para crecer profesionalmente sin perderte a vos mismo/a en el proceso.

La cualidad para lograr grandes cosas

Algo que con los años he aprendido, y quizás coincidas conmigo, es que para lograr cosas grandes en la vida hace falta constancia y disciplina.

La disciplina es una cualidad importantísima para todo eso que requiere esfuerzo sostenido a lo largo del tiempo. A fin de cuentas, no podemos solamente depender de la motivación.

Habrá veces donde tengas ganas de hacer eso que sabés que te beneficia, como por ejemplo:

• Sentarte a estudiar

• Hacer ejercicio

• Comer saludablemente

• Acostarte a horario

• etc.

Pero, ¿qué pasa con esas veces donde las ganas no acompañan? Ahí entra la disciplina al rescate. Si tuviera que definir esta cualidad con mis propias palabras, diría que…

“La disciplina es lo que te lleva a hacer lo que sabés que tenés que hacer en el momento que fijaste para ello, incluso cuando las ganas no están ahí para acompañarte”.

La disciplina aporta algo importante para los objetivos que nos fijemos en la vida: estructura. Cuando ya tenemos sistemas y rutinas para ejecutar los pasos que nos llevan al objetivo deseado, es más sencillo ponerse a trabajar en ello.

De hecho, esto que estás leyendo ahora mismo lo escribí el domingo pasado por la mañana, que es el momento de la semana que he elegido para preparar contenido, tanto para la newsletter como mi blog y redes.

Ahora bien, más allá de todo lo que se puede lograr con la disciplina, esta cualidad también tiene un lado negativo. Me pasó a mí (y cada tanto me sigue pasando). Y, quizás, puede que te pase a vos también.

En resumidas cuentas, esa estructura también puede ser una trampa.

La trampa de la disciplina

¿Qué pasa cuando la vida no coopera con nuestros planes? Eso es algo que lamentablemente ocurre tarde o temprano.

Te querés sentar a estudiar, y de repente se va el internet.

Por fin te propusiste salir a hacer ejercicio, pero te piden desde el trabajo que te quedes un rato más.

Y así mil escenarios más.

Pero he aquí la trampa de la disciplina: nos puede hacer creer que si no respetamos la estructura que hemos definido, entonces hemos fallado. Que si no seguimos la estructura definida contra viento y marea, entonces es mejor abandonar.

Esto me pasó muchas veces, y en esos momentos me asaltaron pensamientos como:

• “No fui lo suficientemente disciplinado”

• “No tuve la fuerza de voluntad necesaria”

• “Si tuviera disciplina de verdad, lo habría hecho igual”

• “A lo mejor esto es algo que quizás no pueda lograr”

Sí, pensamientos muy negativos. Por mucho tiempo pensé que la disciplina requiere que seamos una clase de persona que lo tiene que lograr siempre, ante cualquier circunstancia.

Claramente esto no es cierto. Llevada a un extremo, la disciplina nos puede volver rígidos e incapaces de ajustarnos según las circunstancias.

Hace hace relativamente poco, cambié esa forma de pensar y descubrí que la disciplina es importante, pero existe otra cualidad igual de importante (o puede que más).

La mentalidad flexible

Un término con el que me encontré hace poco leyendo cosas por ahí (leo demasiados cosas a veces xD) es el de “flexibilidad psicológica”.

Una investigación científica que podés chequear acá, acuña este término que me parece brillante. Básicamente este estudio nos dice que la salud psicológica no depende solo de estabilidad, control o consistencia (lo que solemos asociar con disciplina), sino de la capacidad de adaptarse dinámicamente al contexto.

La psicología flexible, según el estudio, se define como la capacidad de:

• Reconocer demandas situacionales cambiantes

• Ajustar comportamientos cuando dejan de funcionar

• Cambiar mentalidades (no solo acciones)

• Mantener balance entre distintas áreas de la vida

• Actuar alineado con valores, no solo con reglas

Dicho de otro modo:

• La disciplina sin flexibilidad asume un mundo estable.

• La realidad es dinámica. Por lo tanto, la rigidez es desadaptativa.

¿Significa esto entonces que hay que abandonar la estructura? No, para nada. Lo que este estudio nos intenta decir es ser inflexibles puede traer consecuencias negativas para nuestro bienestar y salud psicológicos, y nuestra relación con el trabajo y las actividades diarias.

Jon Goodman, autor del libro Unhinged Habits, lo dice de una manera genial:

“Hay momentos en los que la estructura está al servicio del comportamiento, y otros en los que la espontaneidad es mejor opción. La clave no está en elegir una por sobre la otra, sino en entender cuándo cambiar de marcha. La estructura crea el marco que hace posible una espontaneidad significativa. La espontaneidad aporta la materia prima que vuelve productivos los períodos de estructura.”

Disciplinados pero adaptativos

Sin la disciplina difícilmente logremos eso que de verdad queremos en la vida. Pero si abusamos de esta cualidad, deja de ser una herramienta y se convierte en una regla que no se puede cuestionar.

Por eso, en vez de volvernos rígidos, apostemos por ser más flexibles.

En esos momentos donde a lo mejor no pudimos seguir nuestra estructura y nuestros hábitos, en vez de pensar cosas como:

• “Mejor vuelvo a intentar la semana que viene”

Vayamos por esto:

• “¿Qué puedo hacer ahora mismo? ¿Qué puedo hacer hoy?”

Aunque suene cliché decirlo, el progreso no requiere perfección.

Requiere constancia y disciplina, sistemas y hábitos.

Pero también requiere adaptación y flexibilidad.

No hace falta abandonar la estructura por completo. La clave está en entender cuándo nos sirve, y cuándo es mejor soltarla.

Tal como lo dice Ryan Holiday en su libro La disciplina es el destino:

”Debemos cultivar la capacidad para el cambio, para la flexibilidad y la adaptabilidad. Continuamente, constantemente. Cambiar las pequeñas cosas del día a día para preservar y proteger las grandes cosas. La rigidez es fragilidad. La falta de forma (formlessness) nos vuelve irrompibles.”

¡Bienvenido/a a La Senda del Nubearquitecto!

Cloud Computing y AWS desde el camino real: conceptos de arquitectura, servicios clave, aprendizajes y herramientas para diseñar soluciones sólidas.

No son lo mismo

Cuando empecé a meterme en cloud, tenía una idea bastante simplificada:

“Nube = AWS”.

Y listo.

Pero esa asociación, aunque común, es incompleta. Porque AWS no es la nube, es un proveedor de nube pública.

Y ahí aparecen preguntas mucho más interesantes:

• ¿Por qué “pública”?

• ¿Existen otros tipos de nube?

En un nuevo post de la serie Cloud Computing Fundamentals, exploro justamente eso y de manera breve: los modelos de despliegue en la nube.

• Qué significa realmente una nube privada (y por qué implica más control… pero también más responsabilidad)

• Por qué la nube pública es tan accesible y escalable

• Y cómo funciona el modelo híbrido, que en la práctica es donde muchas organizaciones terminan operando

¡Gracias por leer El Ingeniero Consciente! Si te reenviaron este correo o estás leyendo desde la web, te invito a suscribirte para recibir más ediciones y potenciar tu camino IT con una pizca de consciencia y atención plena

Además, cierro con algo que considero clave: cómo todo esto impacta en los roles dentro de IT y qué oportunidades abre si estás construyendo tu camino en tecnología.

Si estás empezando en cloud (o querés ordenar conceptos que parecen obvios pero no lo son tanto), este post te va a dar claridad.

👉 El post completo acá

Y atento/a, que en el próximo y último post de esta serie, ya vamos a hablar de los pesos pesados: AWS, GCP y Azure, con foco en:

• ¿Qué ofrecen?

• ¿Cuáles son sus servicios más importantes?

• ¿Qué empresas importantes hacen uso de sus servicios?

¡Bienvenido/a a Debug Mental!

Reflexiones sobre mentalidad, hábitos y el costado humano de trabajar en tecnología. Para crecer profesionalmente sin perderte a vos mismo/a en el proceso.

Yendo al grano

Generalmente intento que mis publicaciones de la newsletter transmitan todo el profesionalismo posible.

Que se note que hubo un esfuerzo cognitivo real detrás.

Y obviamente que se note que esto no lo escribió ChatGPT o Gemini.

Pero hoy decido escribir a medida que las palabras surgen en mi mente.

Me han criticado más de una vez diciendo que mi poder de redacción no es bueno, que se nota cuando la IA no está detrás de lo que escribo.

Es probable. Uno de mis objetivos este año es mejorar como escritor.

Pero esa crítica (que recibí por Twitter de hecho) me dejó reflexionando en algo que hoy decido compartirte rapidito.

Nada es personal

A veces otras personas pueden herirnos con palabras, acciones o indiferencia.

A todos nos pasó. En momentos así, intento recordar estas palabras de Marco Aurelio:

“Cuando alguien te ofenda, recuerda que no es eso lo que te hiere, sino tu juicio sobre ello”.

Esto no significa que no duela.

Si alguien que queremos o respetamos nos trata mal, es natural que aparezcan emociones. Las emociones no se niegan: se reconocen y se transitan.

Comunicarse con los demás para tratar estas situaciones es importantísimo.

Pero he aquí lo que considero una clave para la buena vida:

No podemos controlar lo que otros piensan, dicen o hacen.

Sí podemos trabajar nuestro discurso interno y la interpretación que hacemos de lo que ocurre.

La mayoría de las opiniones ajenas no hablan de nosotros, sino del mundo interno de quien las emite:

• su historia,

• su herida,

• su ego,

• su confusión

Las personas no te ven como sos, sino como ellas son.

No viniste a esta vida a corregir proyecciones ajenas.

Ni a cargar con conflictos que no te pertenecen.

La próxima vez que te ignoren, te juzguen o digan algo en tu contra, recordalo: nada es personal.

Espero que esta reflexión te acompañe en esta semana que comienza :)

PD: ¿Te gustó esta reflexión breve? Estoy intentando darle una pequeña vuelta de tuerca a Debug Mental.

Esto no quiere decir que no habrá más posts extensos y más profundos, pero pienso que reflexiones rápidas como la de hoy también deberían tener su espacio.

Si te gustó esta publicación, dejame en comentarios tu opinión. ¡Me encantará leerte!

Y si te reenviaron este correo o estás leyendo desde la web, te invito a suscribirte para recibir más ediciones y potenciar tu camino IT con una pizca de consciencia y atención plena

¡Bienvenido/a a La Senda del Nubearquitecto!

Cloud Computing y AWS desde el camino real: conceptos de arquitectura, servicios clave, aprendizajes y herramientas para diseñar soluciones sólidas.

Elige tu transporte

La nube ya no nos resulta un misterio. Tal como vimos anteriormente, sabemos que la nube es, en esencia, la computadora de alguien más.

Ese “alguien más” es una forma simple de referirnos a las empresas que construyen y operan enormes data centers, y que nos permiten acceder a sus recursos para cubrir una amplia variedad de necesidades digitales.

Lo que vamos a explorar ahora es cómo los usuarios acceden a esos recursos.

A lo que hacemos referencia es a los modelos de servicio, que es muy comparable a algunos medios de transporte que tenemos a disposición:

• Infrastructure as a Service (IaaS), que es como alquilar un coche. Nos proveen del mismo, pero tenemos que encargarnos de cosas como la conducción o el combustible.

• Platform as a Service (PaaS), que es como pedir un Uber. Podemos elegir el destino y el camino general pero no controlamos el vehículo ni cómo está construido el motor.

• Software as a Service (SaaS), comparable a tomar un autobús o colectivo, como le decimos en Argentina. No decidimos ni el vehículo, ni el motor, ni la ruta, solo elegimos si subirnos o no.

¡Gracias por leer El Ingeniero Consciente! Si te reenviaron este correo o estás leyendo desde la web, te invito a suscribirte para recibir más ediciones y potenciar tu camino IT con una pizca de consciencia y atención plena

Estos no son los únicos eh. Hay más. Y los factores que nos pueden ayudar a evaluar cuál modelo se ajusta a nuestras necesidades son:

• el nivel de control deseado - ¿querés manejar vos o preferís que alguien más lo haga?

• el nivel de responsabilidad que estás dispuesto a asumir - ¿te encargás del mantenimiento y el combustible, o no querés ocuparte de nada?

Exploramos todo esto en detalle, incluyendo características básicas de cada modelo, comparación con un on-premise clásico, ejemplos de servicios de proveedores conocidos, y más, en una nueva entrada de la serie Cloud Computing Fundamentals: Los modelos de servicio.

👉🏻 Post disponible acá 👈🏻

La próxima vez que pidas un Uber, o te subas a un colectivo, ojalá te acuerdes de lo visto hoy 😉

En el próximo post de esta serie vamos a hablar de despliegue (privado vs. público vs. híbrido) y cómo algunos roles clásicos (DevOps, Data Engineer, etc.) se adaptaron para incorporar la nube a su caja de herramientas.

Ahora te tengo que dejar que me pedí un PaaS y el chofer me cobra la espera 🚗.

¡Bienvenido/a a Debug Mental!

Reflexiones sobre mentalidad, hábitos y el costado humano de trabajar en tecnología. Para crecer profesionalmente sin perderte a vos mismo/a en el proceso.

Un nuevo objetivo

El 2026 está en pañales. Probablemente ya tengas tus objetivos para este año y estés ilusionado/a con alcanzarlos.

Hoy quiero proponerte un objetivo adicional e invitarte a la reflexión:

¿Y si nos aburrimos un poco más en 2026?

Charlemos de algo que hoy por hoy es muy difícil de hacer: dejar el teléfono.

Difícil, lo tenemos practicamente “pegado” a la mano.

Y hablo en plural porque yo también tengo un camino que recorrer al respecto.

Ahora, ¿por qué estamos tan enganchados? Muy seguramente porque intentamos evitar el aburrimiento.

A ver, usar el celu no es algo malo per se, obvio que no.

Es una herramienta necesaria después de todo.

Pero he aquí la pregunta incómoda:

¿Lo usamos con consciencia, o estamos huyendo de nosotros mismos y el mundo que nos rodea?

Como dije más arriba, la idea es reflexionar.

Por eso te traigo los puntos clave de un video titulado “Necesitas aburrirte”.

Haré mi mejor esfuerzo en transmitirte su mensaje, y ver cómo aburrirnos puede ser una de las mejores cosas que tanto vos como yo hagamos este año.

¿Qué pasa cuando nos aburrimos?

¿Te pasó alguna vez? Nada que hacer o con lo que distraerte, y a lo mejor empezaste a pensar en tu presente, tu futuro, a reflexionar en la vida misma.

Primero: tranqui que es super normal que te pase eso.

Segundo: eso que aparece en tu mente cuando no hay distracciones no es casualidad.

Se llama modo de red por defecto.

“¿Eh? ¿De qué me hablás?”

De un conjunto de regiones cerebrales que se activan cuando nos aburrimos, cuando el cerebro no está ocupado o distraído.

Según Arthur C. Brooks, catedrático de Harvard y experto en felicidad y bienestar, todas estas regiones están relacionadas con:

• La autoreflexión

• El soñar despiertos

• La memoria

• Imaginar el futuro

¿Te da esto una pequeña idea de porqué no nos gusta tanto cuando la red por defecto se activa, es decir, cuando estamos aburridos?

Es que todas estas actividades, como imaginar el futuro, pueden llegar a ser algo incómodas.

Y ahí es cuando también se vienen las preguntas existenciales, algo que según Brooks, es “increíblemente importante e increíblemente bueno”.

La crisis de ansiedad y depresión

Es triste hablar de un tema así, pero no es ningún secreto que en la era más conectada de la humanidad, existen muchos casos de ansiedad y depresión.

Brooks afirma que una de las causas de esto es el hecho de que “hemos encontrado una forma de eliminar el aburrimiento”.

En otras palabras, encontramos la forma de apagar casi que por completo el modo de red por defecto.

¿Cómo? Con una cantidad enorme de distracciones.

Brooks lo expresa así:

“Estás intentando no estar aburrido/a porque el modo de red por defecto es levemente incómodo y te lleva a esa clase de preguntas y cuestiones que no son fáciles de responder ni resolver.”

Ahí es donde sentí un “ouch”. Sentí que Brooks me hablaba a mí.

Porque sí, porque aún no estoy 100% curado de la adicción al teléfono, como mencioné antes.

Porque de algo estoy seguro: no creo que pasarme horas scrolleando una pantalla me cumpla todos mis sueños.

Pero hay muy buenas noticias. No tengo porqué vivir así.

Y si crees que esto que me pasa te pasa a vos también, entonces hay luz al final del túnel 😃

Aburrite más y cambiá tu vida

Por ahora parecen ser todas pálidas, pero, como dije, hay esperanza.

Eso sí, esa esperanza requiere esfuerzo.

Yo estoy intentando afrontarlo.

Y si todo esto te resuena, quizá también puedas intentarlo.

“Aburrite más”, nos dice Brooks, a la vez que nos asegura: “Tendrás las ideas más interesantes cuando hagas cosas sin dispositivos”.

Y he aquí lo que me pareció vital:

“Apunta a pasar períodos de al menos 15 minutos estando aburrido/a, y observa cómo tu vida cambia”.

Admito que ese “observa cómo tu vida cambia” me dejó super intrigado.

Y también pensé: “¿En qué me cambiaría aburrirme más?”

Sabiendo muy bien que los seres humanos trabajamos mejor cuando podemos divisar recompensas en el horizonte, Brooks nos menciona algunas de ellas si decidimos estar más aburridos:

• Vamos a estar menos aburrido/a con cosas ordinarias, como por ejemplo, el trabajo

• Menos aburrido/a con nuestras relaciones y las personas que nos rodean

• Vamos a empezar a explorar esas cuestiones importantes de la vida, como el propósito, el significado o la coherencia

• Y quién sabe…hasta terminemos siendo más felices

En el papel todo suena muy bonito.

El punto es: ¿cómo lograrlo?

¡Gracias por leer El Ingeniero Consciente! Si te reenviaron este correo o estás leyendo desde la web, te invito a suscribirte para recibir más ediciones y potenciar tu camino IT con una pizca de consciencia y atención plena

Mi propio ejercicio

Primero, la honestidad brutal: me costó horrores usar menos el teléfono al principio. Y obvio que sigue costando lo suyo.

En otras palabras:

Yo tambíen a veces me encuentro intentando escapar del aburrimiento.

Sin embargo, he hecho progresos:

• Cosas como estudiar ya no me parecen tan pesadas o aburridas

• Estar con mis pensamientos me asusta (un poco) menos

• Tengo más espacio para la autoreflexión, lo que me da una sensación de bienestar general mayor

• Me concentro más cuando charlo con personas cara a cara, sobre todo con familiares y amigos

• Dispongo de más tiempo para dedicar a cosas que me nutren más, como tocar mis teclados, leer libros o escribir

Pero no creas que todo fue un paseo por el parque.

Como dije antes, este bienestar vino con un precio.

Al estar menos distraído en general, también vinieron esos pensamientos incómodos de los que hablamos.

Me costó mucho al principio quedarme con pensamientos como “¿Qué pasa si un día me quedo sin trabajo?” o “¿Qué estoy haciendo con mi vida? ¿Hacia dónde voy?”

Claramente esto que te digo es lo menos marketinero del mundo: “Flaco, me estás diciendo que use menos el teléfono para empezar a deprimirme pensando en todo esto”.

Puede que tengas razón, pero creo que la alternativa es peor: huir de todas esas cuestiones todo el tiempo puede que haga que te sientas peor.

O quizá no, no puedo hablar por vos. Pero eso es lo que me estaba pasando a mí.

Poner en práctica todo esto me llevó a una conclusión:

Si vos también querés probar esto de aburrirte más, entonces pasemos a una parte más practica.

Charlemos un ratito de las herramientas que me ayudaron a que mi teléfono no me distraiga tanto como antes.

📚 Datazo

Hablamos de romper con la adicción, de usar el celular menos. Acá te van dos herramientas que muy probablemente te ayuden con este objetivo.

La configuración ganadora

Ya sea que tengas iPhone o Android, existe una configuración que puede llegar a hacerte pasar 1 hora menos en el teléfono cada día: la escala de grises.

Esta investigación afirma que eliminar el color de tu smartphone y reorganizar las aplicaciones puede ayudarte con la adicción al teléfono, y además, reducir el uso hasta 50 minutos por día, reducir la ansiedad e incrementar tu bienestar.

¿Cómo se puede lograr eso? Fácil:

• Para dispositivos Apple:

  • Abrí la app Ajustes.

  • Tocá Accesibilidad.

  • Seleccioná Pantalla y tamaño del texto.

  • Tocá Filtros de color y activalos.

  • Eligí el filtro Escala de grises

• Para dispositivos Android

  • Andá a Ajustes.

  • Buscá y seleccioná Accesibilidad.

  • Luego a Mejoras de la visibilidad o Color y movimiento.

  • Buscá y activá Escala de grises o Corrección de color y luego seleccioná Escala de grises.

Aunque esto reduce la cantidad de tiempo que pasás en el teléfono, la investigación citada anteriormente comenta que no reduce la cantidad de veces que lo vas a revisar.

Por eso te traigo algo más.

minimal phone

Aplicación de pago, aunque muy barata (9USD por año), que literalmente convierte a tu teléfono en una de las cajas más aburridas que existen, sin sacrificar las funcionalidades que esperamos del mismo.

Algunas cositas interesantes de esta app:

• Reemplazo total del menú de aplicaciones: nada de íconos ni colores llamativos, solo nombres

• Podés elegir qué notificaciones filtrar, de modo que tu celular no esté sonando o vibrando seguido

• Podés configurar cuáles aplicaciones deben estar controladas al momento de usarlas. Esto significa:

  • Abrir la app en cuestión y elegir de antemano cuánto tiempo vas a pasar en ella (5 mins, 10mins o 15mins.)

  • Pasado ese lapso, la aplicación se bloquea y sí o sí vas a tener que esperar un tiempito para volver a seleccionar de nuevo cuánto tiempo vas a pasar en la app otra vez

  • Esto agrega fricción, ideal cuando querés romper un hábito que no te conviene, ya que tu cerebro va a empezar a asociar el hábito con dificultad (que es justamente lo que hace que abandonemos esos hábitos que sí nos convienen, je).

Algunas capturas propias para que veas cómo es.

Seguramente esté olvidando cosas, pero creo esto te da un pantallazo (pun intended) de lo que podés hacer y cómo esta app puede contribuir a que tu teléfono, de repente, ya no resulte tan interesante.

Conclusión

Con todo esto en mente, me pregunto: “¿podré asumir el desafío de aburrirme solo un poco más este 2026?”

Algo tengo claro: quiero que tanto mi vida como mi preciada atención estén en mis propias manos, y no controladas por alguien más.

Y ese mismo deseo guardo para vos, en caso de que te sientas identificado/a con lo que digo.

Porque una vez que se enfrenta esa incomodidad de la que hablamos, una vez que recuperamos nuestra atención, una vez que empezamos a estar ligeramente más aburridos/as que antes…ese día otra vida comienza.

Al menos eso empiezo a pensar.

¿Será este el año para iniciar esa vida?

¡Bienvenido/a a La Senda del Nubearquitecto!

Cloud Computing y AWS desde el camino real: conceptos de arquitectura, servicios clave, aprendizajes y herramientas para diseñar soluciones sólidas.

Arranquemos por el principio

Si ya llevas tiempo suscrito a esta newsletter, seguramente sabrás que soy un “entusiasta” de AWS.

Si sos nuevo/a, y esta es tu primera edición, entonces llegaste en el momento justo.

En cualquier caso, la idea de la edición de hoy es introducirte a lo que es Cloud Computing.

Saber de AWS, GCP o Azure está muy bien, pero como muchos campos en informática, lo ideal es comenzar por los fundamentos.

Estos gigantes de la nube que te menciono son tan solo nombres dentro de un ecosistema más grande que ellos: el Cloud Computing. La realidad es que estos pesos pesados no inventaron la pólvora, sino que supieron basarse en estos fundamentos y construir soluciones desde esa base:

• EC2 (AWS) y Azure Virtual Machine parten del concepto de máquina virtual

• S3 (AWS) y Blob Storage (Azure) parten del concepto de almacenamiento de objetos

• y así con varios servicios más

En esto vamos a profundizar hoy:

• ¿Qué es el Cloud Computing?

• ¿Cuáles son sus fundamentos?

• ¿Qué características comparten todos los proveedores de nube?

• ¿Qué se puede hacer con la nube?

Bienvenido/a a Cloud Computing Fundamentals, una serie de posts de mi blog que serán anunciados a través de esta sección de la newsletter.

Ya tenés el primer post disponible acá

¡Gracias por leer El Ingeniero Consciente! Si te reenviaron este correo o estás leyendo desde la web, te invito a suscribirte para recibir más ediciones y potenciar tu camino IT con una pizca de consciencia y atención plena.

Y para alimentar tu curiosidad, un paneo general de lo que vamos a ver en esta serie a medida que salgan más publicaciones:

• Los modelos de servicio en la nube (sale el mes que viene)

• Modelos de despliegue, regulaciones y roles

• Los principales actores de la nube pública

• Conceptos de Networking fundamentales para moverse con soltura en la nube

Que este año 2026 sea el comienzo de tu viaje en la nube, o que sea el año donde profundices y te vuelvas un/a profesional competente en uno de los conceptos más demandados en IT.

Será todo un placer y un orgullo ser tu compañero de ruta 🚀

¡Bienvenido/a a Taller de Datos!

Conceptos de Data Engineering, Python, SQL, Git y herramientas que forman parte de uno de los roles más demandados en el ecosistema de datos.

Introducción

Python es el lenguaje de facto en data, y obvio que Data Engineering no escapa a esto.

Antes de pasar a hablar de librerías sobre extracción y carga, hagamos un inventario de conocimientos (si sos nuevo/a en la newsletter, esto te va a servir):

• Vimos qué se espera del Ingeniero/a de Datos

• Conocimientos básicos de Python para ser competente

• Lo que es una pipeline y la diferencia entre los patrones ETL y ELT

• Y la importancia de utilizar entornos virtuales en nuestros proyectos con Python

Ahora se viene lo bueno: ¿qué librerías tenemos disponibles para extraer datos de una fuente y luego cargarlos en el destino elegido?

Hoy te traigo un compendio de las librerías mas populares y una breve descripción de cada una. Ideal si te estás familiarizando con el rol, venís de otro rol como backend y estás buscando transicionar a Data Engineering o tan solo querés profundizar en el ecosistema de Python. Vamos al grano.

Drivers de bases de datos

Esta categoría involucra a todas aquellas librerías que nos permiten comunicarnos con bases de datos desde Python.

Podemos entender a un driver como un “traductor” que se encarga de facilitarnos la conexión con una base de datos, encapsulando y abstrayendo múltiples operaciones intermedias para que nosotros podamos concentrarnos únicamente en qué queremos decirle a la base de datos objetivo, y no en cómo hacerlo a bajo nivel.

Un driver requiere el uso de credenciales de autenticación (por ejemplo, usuario y contraseña, certificados, llaves privadas para conexiones vía SSH, entre otros) para crear una conexión. Una vez establecida dicha conexión —que en términos prácticos suele ser un objeto, es decir, una instancia de una clase provista por la librería— podemos:

• ejecutar consultas en SQL puro (CREATE TABLE, DELETE FROM, SELECT, etc.)

• o interactuar con la base de datos sin escribir SQL directamente, a través de lo que se conoce como un ORM (Object-Relational Mapper)

Independientemente del enfoque que elijamos (SQL directo u ORM), en líneas generales podremos:

• leer datos desde la base de datos (SELECT ...)

• cargar o modificar datos en la misma (INSERT, UPDATE, DELETE, etc.)

Te comparto 4 librerías que muy probablemente necesites utilizar en algún punto de tu carrera:

• psycopg2: si necesitás comunicarte con una base de datos PostgreSQL, este ha sido históricamente uno de los conectores más utilizados en el ecosistema Python.

  • Pip: https://pypi.org/project/psycopg2/#description

  • Docs: https://www.psycopg.org/docs/

  • Nota: investigando esta librería al momento de escribir este artículo, aparece su versión más moderna bajo el nombre de psycopg (versión 3). Según sus creadores, psycopg2 queda principalmente para mantenimiento de aplicaciones existentes, mientras que para nuevos proyectos se recomienda comenzar directamente con psycopg. Más info acá.

• sqlite3: integrada nativamente en Python (import sqlite3), por lo que no requiere instalación adicional. Esta librería, escrita en C, provee acceso a una base de datos ligera basada en disco (se almacena como un archivo más en tu sistema) y que no requiere un servidor dedicado. Es especialmente útil para prototipar aplicaciones o desarrollar soluciones simples que luego pueden migrarse a motores más robustos como PostgreSQL, MySQL u Oracle.

  • Docs: https://www.sqlite.org/

• pandas: un verdadero caballito de batalla en el mundo de los datos, y no solo para Ingenieros de Datos. Si bien su foco principal no está en la extracción y carga de datos sino en su manipulación eficiente, ofrece múltiples funcionalidades para leer información desde distintos formatos (CSV, TXT, XLSX, FWF, entre otros), cargarla en memoria mediante estructuras llamadas DataFrames, y luego exportarla nuevamente a archivos o incluso a bases de datos. Internamente, para estas operaciones, pandas se apoya en otros drivers o conectores (por ejemplo, psycopg para PostgreSQL). Como alternativa moderna existe polars, con un propósito y una sintaxis muy similares, pero implementado en Rust, lo que le permite destacar en rendimiento y uso de memoria en ciertos escenarios.

  • Pip: https://pypi.org/project/pandas/

  • Docs: https://pandas.pydata.org/pandas-docs/stable/

• duckdb: una base de datos analítica embebida que puede utilizarse directamente desde Python. Permite ejecutar consultas SQL de forma muy rápida y eficiente sobre datasets grandes, incluyendo DataFrames de pandas, archivos CSV o formatos columnar como Parquet. No requiere un servidor independiente, lo que la vuelve comparable a sqlite3 en cuanto a simplicidad de uso, pero orientada a workloads analíticos en lugar de transaccionales.

  • Pip: https://pypi.org/project/duckdb/

  • Docs: https://duckdb.org/docs/stable/clients/python/overview

SDKs para proveedores Cloud

Muchos proveedores de nube pública, como AWS, GCP y Azure, cuentan con su propio SDK (Software Development Kit) que nos permite interactuar de forma programática con los servicios que ofrecen. En otras palabras, podemos crear, modificar y eliminar recursos desde nuestro lenguaje de programación favorito, en lugar de hacerlo exclusivamente a través de la interfaz web.

En el contexto de pipelines de datos, estos SDK suelen utilizarse para extraer datos desde servicios de almacenamiento de objetos como S3 (AWS) o Cloud Storage (GCP) y, luego del procesamiento o transformación correspondiente, cargarlos nuevamente en el mismo servicio o en otro distinto. Un patrón común es almacenar los datos crudos y los datos procesados en rutas diferentes dentro del mismo bucket (por ejemplo, distintos prefijos en S3), aunque también es habitual cargar los resultados finales en servicios como RDS (bases de datos gestionadas en AWS) o Azure SQL Database.

A continuación, un breve repaso de cómo se organiza el acceso a estos servicios en cada proveedor:

• Google Cloud Platform (GCP): la nube de Google ofrece librerías específicas por servicio (por ejemplo, almacenamiento, BigQuery, Pub/Sub, etc.). Este enfoque permite instalar únicamente los clientes necesarios, dando mayor control sobre las dependencias y manteniendo un entorno de desarrollo más liviano.

  • Docs: https://docs.cloud.google.com/python/docs/reference

• Azure: presenta una estrategia similar a la de GCP. Se eligen una o más librerías en función de los servicios con los que se necesite interactuar, lo que favorece una gestión más granular de dependencias.

  • Docs: https://learn.microsoft.com/en-us/azure/developer/python/sdk/azure-sdk-overview

• AWS: Amazon optó por un enfoque distinto y centralizó el acceso a sus servicios en boto3, el SDK oficial de AWS para Python. A través de una única instalación, es posible interactuar con prácticamente todos los servicios de AWS mediante dos abstracciones principales: clients y resources. Ambas permiten realizar operaciones similares, pero con distintos niveles de abstracción y ergonomía. ¿Te gustaría que arme una guía rápida para empezar a usar boto3? Hace ya un par de años que lo utilizo y, si bien siempre hay algo nuevo por aprender, creo que puedo aportar una buena base práctica. Decime en los comentarios si te interesaría. 😊

  • Docs: https://aws.amazon.com/sdk-for-python/

APIs

Muchos sistemas exponen datos mediante APIs. Es por ello que las APIs son consideradas en la lista de source systems (sistemas fuente), lugares desde donde debemos extraer datos para transformación y posterior carga.

En términos generales, al comunicarnos con una API lo que hacemos es enviar una petición HTTP (por ejemplo, GET, POST, PUT, etc.), acompañada de ciertos parámetros, encabezados y, en algunos casos, un cuerpo (body). Como respuesta, la API nos devuelve los datos solicitados, habitualmente en formatos como JSON o XML.

• requests: probablemente la librería más conocida para realizar peticiones HTTP en Python. No es la única opción disponible, pero sí una de las más simples y amigables de usar. Su principal limitación es que no soporta asincronismo de forma nativa, lo cual puede ser una desventaja en escenarios I/O bound (por ejemplo, cuando realizamos muchas llamadas a APIs externas). En serio: investigá sobre concurrencia y paralelismo, porque tarde o temprano lo vas a necesitar en este contexto.

  • Pip: https://pypi.org/project/requests/

  • Docs: https://requests.readthedocs.io/en/latest/

• HTTPX: una librería moderna que ofrece soporte tanto sincrónico como asincrónico, con una sintaxis muy similar a requests. Hace un uso intensivo de type annotations, una característica de Python que vale la pena incorporar, ya que mejora la legibilidad del código y facilita el trabajo con herramientas de análisis estático.

  • Pip: https://pypi.org/project/httpx/

  • Docs: https://www.python-httpx.org/

• AIOHTTP: una librería puramente asíncrona, orientada a alto rendimiento y muy eficiente en escenarios que requieren alta concurrencia. Trabajar con concurrencia no siempre es sencillo de implementar ni de debuggear, pero es una habilidad clave en sistemas de datos y, en algún momento, conviene “pelearse” con este tipo de herramientas para entenderlas bien.

  • Pip: https://pypi.org/project/aiohttp/

  • Docs: https://docs.aiohttp.org/en/stable/

¡Gracias por leer El Ingeniero Consciente! Si te reenviaron este correo o estás leyendo desde la web, te invito a suscribirte para recibir más ediciones y potenciar tu camino IT con una pizca de consciencia y atención plena

Archivos

Este apartado puede subdividirse en dos grandes grupos: archivos locales (los que tenés en tu computadora o en el filesystem del entorno donde corre tu código) y archivos que deben extraerse desde o cargarse hacia servidores que utilizan protocolos como FTP y/o SFTP.

Archivos locales

• csv: librería estándar de Python (es decir, no hace falta instalar nada) para trabajar con archivos separados por comas. Ojo igual: el nombre engaña, porque el delimitador no siempre es una coma. Muchas veces vas a encontrarte con ;, | u otros separadores, así que no conviene confiarse. También es común utilizar esta librería para leer archivos .txt que sigan una estructura tabular similar.

  • Docs: https://docs.python.org/3/library/csv.html#module-csv

• Excel: acá decidí invertir el enfoque y, en lugar de mencionar una sola librería, hablar directamente del tipo de archivo. Y es que lidiar con Excel suele ser todo un desafío. Los datos rara vez vienen bien organizados (hay gente que los usa como si fuera Canva o Paint… mejor no profundizar), y si el archivo es grande, podés encontrarte con problemas de memoria. A diferencia de otros formatos, los archivos Excel no están pensados para ser leídos de forma verdaderamente streaming, por lo que en muchos casos terminan cargándose completos en memoria. Dicho esto, ¿qué librerías existen para lidiar con estos subproductos de Satanás?

  • openpyxl: una de las librerías más conocidas y confiables para trabajar con archivos Excel en formato moderno (.xlsx, Excel 2010 en adelante). Es una opción sólida para la mayoría de los casos.

    • Pip: https://pypi.org/project/openpyxl/

    • Docs: https://openpyxl.readthedocs.io/en/stable/

  • python-calamine: una alternativa muy rápida y robusta, especialmente útil cuando la estructura interna del archivo no puede ser interpretada correctamente por openpyxl. Personalmente, me ha salvado más de una vez en escenarios complicados.

    • Pip: https://pypi.org/project/python-calamine/

    • Docs: (no pude encontrar docs, asi que si tenés el link por ahí, avisame y lo coloco acá)

  • xlrd: llibrería pensada exclusivamente para leer archivos Excel en formato antiguo (.xls). Importante: no sirve para archivos .xlsx. En mi opinión, hoy en día solo la usaría como failover cuando necesito leer un .xls y las otras alternativas no funcionan o no aplican.

    • Pip: https://pypi.org/project/xlrd/

    • Docs: https://xlrd.readthedocs.io/en/latest/

Recomendación: si vas a lidiar frecuentemente con archivos Excel, pandas puede alivianarte bastante el proceso. A través de métodos como read_excel, podés importar los datos del archivo directamente a un DataFrame, una estructura en memoria que ofrece muchas abstracciones y utilidades para trabajar con datos tabulares.

Internamente, pandas se apoya en varias de las librerías mencionadas anteriormente. Mediante el argumento engine de read_excel, podés alternar entre distintos motores de lectura. Esto resulta muy útil para implementar estrategias de fallback: por ejemplo, si openpyxl no logra parsear un archivo, podés capturar la excepción y volver a intentar usando calamine como motor alternativo.

Servidores FTP/SFTP

Estos servidores se utilizan típicamente para proveer o intercambiar datos con clientes o terceros fuera de tu compañía. Como Data Engineer, es bastante común tener que conectarse a este tipo de servidores para extraer datos de un cliente, realizar procesos de transformación y limpieza, y luego devolver el resultado ya sea en una ruta específica del mismo servidor o cargándolo en un data warehouse como Snowflake para su posterior análisis.

Hay varios puntos importantes a tener en cuenta al trabajar con este tipo de servidores:

• FTP: si el protocolo a utilizar es FTP, la conexión es relativamente simple, pero insegura. Aunque se maneje autenticación mediante usuario y contraseña, las credenciales y los datos suelen viajar en texto plano, lo cual hace tiempo dejó de ser una opción aceptable desde el punto de vista de seguridad.

  • ftplib: librería estándar de Python (nuevamente, sin necesidad de instalaciones adicionales). Permite automatizar tareas típicas sobre servidores FTP, como conectarse, listar directorios, descargar archivos y subir resultados procesados.

    • Docs: https://docs.python.org/3/library/ftplib.html

• SFTP: acá la historia cambia. Este protocolo funciona sobre SSH, lo que implica una conexión segura, pero también un manejo más cuidadoso de la autenticación. En la práctica, suele requerirse el uso de llaves públicas y privadas, aunque también es posible combinar llaves con usuario y contraseña según la configuración del servidor.

  • paramiko: librería que implementa el protocolo SSHv2 y permite realizar prácticamente las mismas operaciones que ftplib, pero sobre una conexión segura. Un detalle a tener en cuenta es que paramiko es relativamente pesada en tamaño, lo cual puede convertirse en un problema en entornos con límites estrictos de despliegue. Por ejemplo, si tu aplicación Python se ejecuta como una función AWS Lambda, es posible que el peso total del paquete supere el límite permitido. En esos casos, suele ser necesario recurrir a Lambda Layers u otras estrategias de empaquetado. Si necesitás ayuda con este contexto de despliegue en particular, escribime 😉

    • Pip: https://pypi.org/project/paramiko/

    • Docs: https://www.paramiko.org/

Lo que quiero que te lleves

Como vimos, existen muchas librerías en Python para extracción y carga de datos. El truco es elegir la herramienta adecuada para la situación correcta.

Además, está bueno saber que Python de por sí viene equipado con librerías para distintos escenarios, por lo que salir corriendo a instalar librerías de terceros no siempre tiene que ser la mejor alternativa.

¿Crees que falta alguna librería para agregar? ¿Hay algo que debería corregir? Avisame en los comentarios, siempre estoy atento a cualquier feedback que puedan darme. La idea no es demostrar quién sabe más, sino llegar a las conclusiones correctas mediante información precisa.

En la próxima edición de Taller de Datos, vamos a charlar sobre cómo abordar el proceso de transformación de datos en Python a través de librerías.

PD: te odio Excel.

Quería avisarte de un cambio importante que se viene en El Ingeniero Consciente.

A partir de ahora, la newsletter estará organizada en secciones temáticas, y cada edición semanal estará enfocada en un solo pilar:

• 🛠️ Taller de Datos — Data Engineering, Python, SQL, Git y herramientas técnicas

• ☁️ La Senda del Nubearquitecto — AWS, cloud y arquitectura

• 💼 Carrera y Habilidades — crecimiento profesional en IT

• 🧠 Debug Mental — mentalidad, foco y el costado humano de trabajar en tecnología

¿Querés elegir qué secciones recibir?

Tenés dos opciones:

Opción 1: desde Substack (paso a paso)

1. Abrí el menú de Substack

2. Entrá en Suscripciones

3. Hacé click en El Ingeniero Consciente

4. En la página de la newsletter, hacé click en tu ícono de usuario (arriba a la derecha)

5. Seleccioná Gestionar suscripción

6. Elegí las secciones que querés recibir

Opción 2: acceso directo

Podés gestionar tus preferencias directamente desde este enlace:
👉 https://elingenieroconsciente.substack.com/account?utm_source=user-menu

Cualquiera sea la opción que elijas, deberías poder llegar a una página como esta:

Gracias por estar del otro lado y por acompañar esta nueva etapa.

La idea es simple: más foco, menos ruido y contenido que realmente te sirva.

¡Un abrazo!
— Elias (Kani)

Y antes de que el año termine del todo, quería hacer una pequeña pausa para decir gracias.

Gracias a quienes leen en silencio.

Gracias a quienes responden con un “esto me sirvió”.

Y gracias especialmente a quienes se tomaron el tiempo de responder la encuesta de la edición anterior. Aunque no fueron muchos en cantidad, sí fueron más que suficientes para darme claridad.

Con ese feedback pude confirmar algo importante: El Ingeniero Consciente está creciendo, y es momento de darle una estructura más clara y sostenible de cara al 2026.

Lo que fue (y lo que aprendí)

Este año la newsletter fue, en muchos sentidos, un laboratorio.

Como cuando te mandás a probar el free tier de AWS y levantás 2 instancias EC2, 1 Lambda y subis un archivo a S3 a ver cómo funca la nube 🤣

Probé formatos, extensiones, mezclas de contenido técnico con reflexión, y fui ajustando sobre la marcha.

Algo que apareció con fuerza en la encuesta fue esto:
👉 no todos leen todo, y está perfecto.
👉 la gente valora saber qué va a leer antes de abrir.
👉 el contenido técnico y el humano funcionan mejor cuando tienen foco.

Así que decidí ordenar todo eso.

El nuevo formato de El Ingeniero Consciente (2026)

A partir del año que viene, la newsletter tendrá una frecuencia semanal y cada edición estará enfocada en un solo pilar.

🛠️ Taller de Datos

Data Engineering, Python, SQL, Git y herramientas técnicas.
Conceptos fundamentales explicados de forma práctica y aplicable.

☁️ La Senda del Nubearquitecto

AWS, cloud computing y arquitectura.
Aprendizajes reales, buenas prácticas y herramientas desde el recorrido, no desde el manual.

💼 Carrera y Habilidades

Crecimiento profesional en IT: salario, seniority, comunicación, foco, toma de decisiones y desarrollo de habilidades clave.

🧠 Debug Mental

Reflexiones, mentalidad, hábitos, foco y el costado humano de trabajar en tecnología.

Nota: En cada edición puede aparecer una sección llamada Datazo, que acompaña al pilar principal con un recurso, herramienta o idea concreta para profundizar.

Nota 2: Además, si bien la frecuencia es semanal, esto no implica que haya una edición todas las semanas del mes. Algunos meses estarán más cargaditos que otros, pero mi compromiso es brindarte contenido de calidad con frecuencia.

El espíritu no cambia

Aunque el formato se ordena, la esencia sigue siendo la misma.

Con El Ingeniero Consciente no busco decirte qué hacer desde un pedestal o como una especie de gurú.

Busco acompañarte desde el camino.

Todo lo que comparto nace de lo que estoy aprendiendo, probando, investigando y, muchas veces, equivocándome. Siempre con la intención de aportar valor real, con honestidad y sin humo.

• Si algo me interesa, lo estudio.

• Si algo me sirve, lo comparto.

• Y si me equivoco, lo corrijo.

Para cerrar

De verdad: gracias por estar del otro lado.

Esta newsletter existe porque hay alguien leyéndola.

Espero que el 2026 nos encuentre con más foco, más aprendizaje y mejores conversaciones.

Nos leemos el año que viene.

¡Un abrazo grande! 🫂

— Elias 🧘‍♂️
El Ingeniero Consciente

Hoy no vengo a contarte sobre mi año, sino a pedirte algo muy importante: tu opinión.

Vos, que le das sentido a esta newsletter, a mi blog y a todo lo que comparto en X y LinkedIn.

Vos, que con cada “¡esto me sirvió!” me recordás por qué escribo.

Antes de planificar el 2026 de El Ingeniero Consciente, quiero saber:

👉 ¿Qué te gusta de la newsletter?
👉 ¿Qué mejorarías?
👉 ¿Qué contenido te aporta más valor?

Preparé una encuesta cortita (lo prometo), y tu respuesta —5, 10 o 15 minutos— va a ayudarme muchísimo a diseñar lo que viene.

¿Me ayudás a diseñar el 2026 de “El Ingeniero Consciente”? Acá te va la encuesta. 👇

🧠 Encuesta Oficial – El Ingeniero Consciente 2025

Sección 1 — Qué contenido te interesa más

⏱️ Sección 2 — Formato y frecuencia

🔍 Sección 3 — Validando la nueva estructura

Tengo en mente una nueva estructura que quiero validar junto a vos. Básicamente me gustaría dividir la newsletter en más ediciones al mes, pero más breves, concisas, y enfocadas.

🌱 Sección 4 — Extra

💬 Sección 5 — Feedback abierto

Y acá van las preguntas difíciles (?

Sé que responder estas en particular toma más tiempo que las otras, pero definitivamente me encantaría leerte.

Podés responder a este mismo mail con tus respuestas, algo que te agradeceré enormemente.

Sin embargo, sé que un “muchas gracias” puede quedarse algo corto, asi que quiere ser más tangible.

Preguntas de respuesta libre:

12) ¿Cuál fue la edición o tema que más te gustó? ¿Por qué?

13) Si pudieras mejorar la newsletter en un aspecto, ¿cuál sería?

14) ¿Algo extra que quieras decir antes de arrancar 2026?
(Podés sincerarte: ¿estás acá por el tech, por la filosofía, o por los memes? 😄)

Muchísimas gracias por haber decidido formar parte de esta aventura.

¿Qué esperar para el mes próximo? Bueno, decidí tomarme un respiro mientras espero los resultados de estas encuestas. Una vez las tenga, será cuestión de ponerme a preparar el contenido para Enero.

En el mientras, te animo a seguirme en mis redes y mi blog, ya que iré publicando cositas por esos lados también. Tenés todos mis enlaces acá.

Espero que me sigas acompañando en el 2026. 🚀

¡Nos leemos pronto! 😊

• Qué son los entornos virtuales de Python y porqué deberías usarlos

• Una forma probada para incrementar tu sueldo como profesional IT

• Y cómo seguir tus talentos es mejor que seguir tu pasión

¡Gracias por leer El Ingeniero Consciente! Si te reenviaron este correo, te invito a suscribirte para recibir más ediciones y potenciar tu camino IT con una pizca de consciencia y atención plena

🧠 El Núcleo

Entornos virtuales de Python

Si bien este concepto podría haberlo abarcado antes, creo que este es el momento ideal para hacerlo.

En una edición anterior vimos conceptos básicos de Python que todo/a Data Engineer debería conocer, comprender y dominar para realizar un trabajo efectivo con este lenguaje.

Ahora podemos sumar uno más, y bastante importante, a esa lista de temas: los entornos virtuales. Quizá te preguntes: “¿y si es tan importante, porqué no lo incluiste en esa lista?”.

Es una pregunta muy válida. La respuesta corta es que no quería abrumarte con tantos conceptos. Pero existe un motivo más, y tiene que ver con el timing de los diferentes temas que estamos abarcando hasta ahora en esta sección de la newsletter:

• Ya vimos que las pipelines son sistemas que construyen los Data Engineers para mover y procesar datos

• ETL o ELT son patrones de diseño para dichos sistemas.

Mi intención original para esta edición era contarte cómo poder implementar las etapas de extracción y carga (E y L) con Python mediante algunas librerías muy utilizadas para tal fin.

Pero acá está el asunto: si vas a instalar librerías de Python para un proyecto, hay que evitar un error muy común que se comete cuando somos nuevos con el lenguaje, y que de hecho cometí, que es instalar librerías en el Python global del sistema.

Vayamos por partes:

• ¿Qué es el Python *global* y qué problemas hay con instalar muchas librerías ahí?

• ¿Cómo solucionan este problema los entornos virtuales?

• ¿Qué es un entorno virtual de Python? ¿Cómo se instalan y gestionan dichos entornos?

¿Qué es el Python global y qué problemas hay con instalar muchas librerías ahí?

Cuando instalás Python, tu sistema operativo te deja un “Python base” o también llamado “Instalación global”, una especie de caja de herramientas compartida para todos tus proyectos. Esa instalación global es conveniente… hasta que ya no lo es.

¿Por qué? Por varios motivos:

• Dependencias que chocan entre sí: imaginá que un proyecto requiere pandas==1.5 y otro, pandas==2.2. Si instalás todo en el Python global… boom, conflicto. Un proyecto va a andar, el otro no, o ninguno.

• Ensuciás el sistema: después de un tiempo, terminás con un Python global inflado, lleno de paquetes que ni sabés quién usa. Algo así como tu carpeta de Descargas, pero con consecuencias en tus proyectos.

• Difícil de replicar: si querés enviarle tu proyecto a alguien o desplegarlo en un servidor, ¿cómo garantizás que tiene exactamente las versiones que vos tenés instaladas? Spoiler: no podés. O a lo mejor sí, pero eso implicaría instalar la misma versión de Python e instalar manualmente todas y cada una de las dependencias (en la misma versión exacta) en el sistema destino.

En otras palabras: instalar cosas en el Python global es como guardar todas tus herramientas en una caja de cartón. Funciona, tenés todo ahí…pero después te arrepentís ya que el desorden que genera termina haciéndote perder tiempo.

¿Cómo solucionan este problema los entornos virtuales?

Los entornos virtuales existen para darte aislamiento.

Cada proyecto tiene su propio mini-Python, con sus librerías, sus versiones y su ecosistema independiente del resto del sistema.

Es como tener “burbujitas”, cada una con la misma versión de Python, pero con cada burbuja siguiendo sus propias reglas. Un proyecto puede usar Django 4.0 y otro Django 5.1 sin drama alguno. Lo que pase en ese entorno, queda en ese entorno. Lo que pasa en la “burbuja”…se queda en la “burbuja”.

Los entornos virtuales también facilitan:

• Reproducibilidad: podés generar un archivo requirements.txt y cualquiera puede levantar tu proyecto con las mismas dependencias. Es decir, podés reconstruir en el mismo entorno en donde lo necesites.

• Higiene técnica: tu sistema se mantiene limpio y tus proyectos también. Nada de tener el Python global lleno de cosas que no hacen falta.

• Portabilidad: si desplegás en AWS Lambda, Cloud Run, Docker o donde sea, necesitás saber qué dependencias exactas usa tu proyecto. Los entornos virtuales te obligan a ser explícito. Y en esto tengo una anécdota donde no ser explícito con las versiones nos rompió la cabeza a mí y a un compañero del trabajo cuando nos tocó colaborar en un mismo proyecto. ¿Querés que te la comparta? Contactame a través de mis redes y charlemos 😊

¿Qué es un entorno virtual de Python? ¿Cómo se instalan y gestionan dichos entornos?

Un entorno virtual es una carpeta que contiene:

• una copia ligera del intérprete de Python

• una carpeta site-packages donde se guardan las dependencias

• scripts para activar ese “mini-Python” o el “Python burbuja”

Los podés crear con varias herramientas, pero la más estándar (y que ya viene con Python) es venv.

Crear un entorno virtual

python3 -m venv .venv

Activar el entorno

Linux / MacOS:

source .venv/bin/activate

Windows (PowerShell):

.\\.venv\\Scripts\\activate

Instalar librerías dentro del entorno

pip install pandas
pip install requests

Exportar dependencias a un requirements.txt

pip freeze > requirements.txt

Desactivar el entorno

# Con esto volvés al Python global, como si nunca hubiera pasado nada.
deactivate 

Ahora que ya despejamos el terreno y tenemos nuestras herramientas bien ordenadas dentro de su propio entorno, estamos listos para dar el siguiente paso.

En la próxima edición vamos a meternos de lleno en algo mucho más práctico: **cómo realizar las etapas de Extracción y Carga (E y L) usando Python**. Vamos a ver librerías muy usadas en el día a día de un/a Data Engineer para traer datos desde APIs, archivos, bases de datos… y luego cargarlos hacia donde los necesites.

🚀 Carrera y Habilidades

Cómo acrecentar tu sueldo

Hace un tiempo que no escribo en esta sección, así que espero que lo que leas acá te sirva o al menos te deje pensando.

Como siempre, te invito a filtrar cualquier consejo —incluido este— y quedarte solo con lo que realmente resuene con vos.

En estos días estuve leyendo El Álgebra de la Riqueza, de Scott Galloway, un libro que me viene resultando sorprendentemente iluminador. En una de sus secciones, el autor habla sobre el “Foco” y propone una idea bastante simple, pero bien expresada, sobre qué cosas pueden ayudarte a aumentar tu sueldo.

No es que haya descubierto la pólvora, pero la forma en que lo plantea me pareció clara y útil. Así que acá va mi versión resumida y digerida.

Picos y valles, no una escalera

El autor arranca abordando este concepto con algo muy interesante. Una verdad algo amarga de la naturaleza humana es que es más probable que gente externa a la empresa donde estás te valore más que tu actual empleador.

Las personas nos enganchamos más con lo nuevo, y los jefes no son distintos.

De hecho un error común de los managers es que ven al empleado como aquella persona que se sumó hace unos años a la compañía, en vez de verla como el profesional con experiencia que ahora es.

La realidad de esto es que cambiar de trabajo de manera estratégica suele traer aparejados saltos en responsabilidades y también compensación.

Para Marzo de 2023, los estadounidenses que cambiaron de trabajo en los últimos doce meses vieron su salario incrementado en un 7.7%. Quienes se quedaron donde estaban vieron incrementada su compensación en un 5.7%.

Además, otro beneficio de cambiar de trabajo es que nuevos entornos expanden tu experiencia, volviéndote alguien más flexible y adaptable en una economía cambiante.

Por eso Galloway dice que deberíamos ver nuestra carrera no como una escalera que subir de manera lineal, sino como montañas o valles a cruzar, con diferentes desafíos y entornos a dominar. Esta variedad nos expone a oportunidades “diagonales”, que nos permitirán expandir nuestro kit de herramientas y habilidades.

El “market check”

Pero incluso si no cambias de trabajo, los “market checks” (es decir, comprobar tu valor actual en el mercado) pueden pagar dividendos. Imaginate tener una entrevista con otra empresa y que te ofrezcan cierto salario o compensaciones, y que estos sean superiores a los que te ofrecen en tu empleo actual.

Un consejo accionable a considerar es hablar con tu actual empleador y decirle algo como: “Este es mi valor de mercado. Me gustaría quedarme, y te pido que por favor lo puedas reflejar”.

Si querés crecer tu compensación a un ritmo más acelerado que la inflación, probablemente tengas que irte a otra empresa que te valore más, o demostrar una disposición creíble de que lo vas a hacer (siempre que tengas una oferta real de otra empresa bajo el brazo).

Lo importante es conocer tu valor de mercado y dónde podría aprovecharse al máximo. Por eso es importante tener contactos y ser visible en redes como LinkedIn.

Hablá con tus contactos de vez en cuando y preguntales:

• ¿Quién está contratanto?

• ¿Qué están buscando?

• ¿Qué habilidades y características son las más demandadas ahora mismo?

Es importante actualizarse con frecuencia en este tipo de aspectos.

Solo tu empleador se beneficia de tu ignorancia.

Espada de doble filo

Explorar otras oportunidades puede ofrecer beneficios, pero es importante regular expectativas.

Antes de considerar cambiar de trabajo, está bueno reflexionar en qué cosas nos gustan de nuestro empleo y organización actual. Todos los trabajos tienen sus frustraciones, cada jefe tiene sus actitudes irritables, y lo que ahora parece una oportunidad increíble muy probablemente, luego de seis meses, simplemente sea…tu trabajo.

Otro aspecto a evaluar es: ¿qué pasa con todo el tiempo que nos tomó aprender sobre nuestra actual empresa, y la reputación que construimos en ese espacio con los años? Irnos a otro lado implicaría reconstruir esa reputación y la red de contactos que hicimos con el tiempo.

También hay otro riesgo significativo: ninguna cantidad de entrevistas te puede asegurar de que vas a ser un fit, o que vas a encajar, en la nueva organización.

Adicionalmente, es importante considerar el efecto que esto puede tener en tu hoja de vida, el mensaje que tu historial de trabajo le transmita a tus futuros empleadores. Por ejemplo, si tuviste 3 trabajos en 5 años, la persona que te entrevista probablemente piense que el problema sos vos.

¿Cuándo cambiar de trabajo?

Pregunta super importante que el autor nos responde, en mi opinión, con mucha precisión.

Es válido cambiar de trabajo cuando hay un valor estratégico en hacerlo y el restulado de hacerlo es materialmente mejor, no solamente diferente. Preguntate:

• ¿Estoy añadiendo un nombre (de empresa) de valor a mi hoja de vida?

• ¿Es una oportunidad para expandir mi red de contactos de una manera productiva?

• ¿Me permitirá la posición o el empleador expandir mi conjunto de habilidades?

Si no podés articular ventajas claras y concretas de irte a la nueva empresa, entonces quizá no sea bueno cambiar de trabajo ahora mismo. Cuestionate si estás cambiando simplemente por cambiar y si hacerlo no te va a empujar a buscar trabajo nuevamente en 1 año.

💭 Debug Mental

No Sigas tu Pasión, Sigue tu Talento

En la edición anterior vimos que, según una investigación académica, perseguir tu pasión puede ser algo que traiga mucha frustración y ansiedad. El famoso consejo de “sigue tu pasión” podría estar haciendo más daño que bien.

Hoy te traigo otra reflexión basada en el libro que ya cité en la sección anterior, “El Álgebra de la Riqueza” de Scott Galloway.

¿Y si resulta que hay algo mejor que perseguir la pasión? Según Galloway, lo hay, y ese es nuestro talento.

La hipótesis de la pasión

Para la mayoría de nosotros, encontrar la pasión no es algo accionable ya que no sabemos qué es. Incluso si podemos “articular una pasión”, a menudo está determinada socialmente, reflejando lo que nuestra cultura espera de nosotros, sin ser algo inherente a nosotros mismos.

El autor Cal Newport escribió un libro titulado “Tan bueno que no puedan ignorarte”, desmintiendo lo que él llama “la hipótesis de la pasión”. Newport comienza analizando lo que él considera el mayor representante de este mito: Steve Jobs.

En 2005, Jobs dió un discurso en Stanford e instó a los graduados a “encontrar lo que aman” y construir una carrera alrededor de eso. Ese discurso fue visto más de 40 millones de veces en YouTube. Pero tal como indica Newport, la carrera de Jobs contradice el consejo dado en el discurso.

Antes de iniciar en Apple, Jobs tuvo varias pasiones: meditación, caligrafía, frutarianismo, etc. Su interés inicial en la tecnología fue construir un accesorio que permitiera realizar llamadas telefónicas a distancia gratuitamente.

Cuando finalmente recibió “el llamado”, no fue ninguna de estas cosas. Fue la promoción de una computadora construida por alguien más, su amigo Steve Wozniak. Jobs no encontró lo que amaba, encontró su talento. Se volvió apasionado por el marketing de computadoras destinadas a usuarios hogareños, lo que él luego llamaría “bicicletas para la mente”, porque realmente era bueno en eso.

Sigue tu talento

En contraste con la pasión, el talento es observable y testeable, puede ser más fácilmente convertible en una carrera de altos ingresos y se vuelve mejor a medida que lo explotas.

Hacer aquello en lo que eres bueno crea un círculo virtuoso. Tus logros vienen más rápido, lo que refuerza tu confianza y fomenta el esfuerzo enfocado.

La idea es encontrar aquello en lo que eres bueno y dedicar las miles de horas de determinación y sacrificio necesarios para volverte alguien realmente competente (según el libro, “ser grande”) en eso.

Las preguntas ahora son:

• ¿Qué es el talento?

• ¿Cuál podría ser mi/tu talento o talentos?

Talento

El talento es cualquier cosa que puedas hacer que otros no puedan o no quieran hacer.

La clave es descubrir qué es eso que puedes hacer que otros no estén dispuestos a hacer o no puedan hacer.

• El trabajo duro es un talento.

• La curiosidad es un talento.

• La paciencia y la empatía son talentos.

El punto es “lanzar una red amplia” y considerar no solamente tus habilidades, sino tus ventajas, tus diferencias, lo que puedes tolerar, lo que te hace único. Esto requiere tiempo, flexibilidad y autoreflexión.

De todos los consejos ofrecidos por el autor, este me pareció clave:

colócate a ti mismo en diferentes contextos, posiciones y organizaciones.

Trabajo voluntario, trabajo gubernamental, deportes, etc. Distintos entornos revelan talentos, asi que explora varios.

Busca evidencia que revele tus talentos reales.

• ¿Cuáles son esos roles que la gente pide que asumas?

• ¿Dónde tuviste éxito?

• ¿Cuál te costó más?

Acá te va un ejemplo. Si organizas grandes fiestas, eso no significa que deberías ser un/a Planificador/a de Fiestas. Pero puede revelar que…

• eres creativo/a

• organizado/a

• bueno/a en publicitar y vender

• tienes habilidades de emprendedor o una habilidad para lograr que la gente haga lo que quieres (ir a tu fiesta)

Si hay algo por lo que sientes pasión, investiga esa relación.

• ¿Qué disfrutas específicamente de eso? Seguramente sea el aspecto relacionado a tu talento.

• ¿Qué otra cosa puedes hacer con ese talento?

Del talento a la pasión

He aquí lo que más me impacto cuando leí esta sección del libro y que es realmente lo que quiero que te lleves de todo esto: la búsqueda de talento lleva a la pasión.

Esa pasión viene de la maestría, de la sensación de hacer algo difícil muy pero muy bien. De construir una relación con esa actividad (pasión armoniosa, tal como vimos en la edición anterior).

Los profesores Bill Burnet y Dave Evans, autores del libro Diseñando tu vida, lo ponen de esta manera:

¿Cuál es tu talento? ¿Cuál es mi talento?

Sea cual sea (y obvio que podemos tener más de uno), nuestra misión es dedicar tiempo, esfuerzo, perseverancia y constancia en ese talento. Volvernos realmente buenos en eso. La relación que construyamos con nuestro talento es la que nos producirá satisfacción y sensación de significado.

Resumen nivel 5

Lo que quiero que te lleves de esta edición es:

• Antes de instalar cualquier librería para trabajar con datos en Python, asegurate de tener tu entorno virtual listo. Te ahorra problemas, te hace más profesional… y te evita querer golpear a tu futuro yo.

• Cambiar de empleo puede representar un salto en responsabilidades, compensaciones, contactos y habilidades. Pero hay que ser estratégicos y chequear nuestro valor de mercado con frecuencia. Solo tu jefe se beneficia de tu ignorancia en este aspecto.

• Seguir nuestros talentos es mejor que seguir nuestra pasión, ya que es algo más accionable, medible, y ofrece mejores resultados. Eso sí, encontrarlos es el primer paso. Luego hay que perfeccionarse y desarrollar maestría. Lo bueno es que esa maestría puede llevarnos a la pasión.

• Dos enfoques súper importantes para construir pipelines de datos

• “Sigue tu pasión”…¿es realmente un buen consejo?

• No gastes dinero innecesariamente si estás desarrollando con Amazon S3

🧠 El Núcleo

ETL vs ELT

En la edición anterior, aprendimos que los Data Engineers construimos pipelines para automatizar el movimiento y procesamiento de datos de manera eficiente, escalable, y segura.

Lo que nos toca ver hoy son dos maneras (aunque no las únicas) para construir dichos sistemas. Te las presento: ETL y ELT, dos enfoques o patrones distintos —aunque complementarios— para mover datos desde su origen hasta su destino.

¿Qué son?

ETL y ELT son patrones de diseño de pipelines de datos, es decir, son una secuencia o forma estructurada de definir el flujo que siguen los datos, desde que se extraen, hasta que transforman y almacenan. Arranquemos con ETL, el que se suele utilizar con más frecuencia (aunque parece que la tendencia está empezando a ir más por ELT).

ETL — Extract, Transform, Load

ETL es el framework más antiguo y aún el más común para diseñar pipelines de datos, desgranando el flujo de datos en tres pasos secuenciales:

• Extract - extracción de datos desde un sistema fuente (source system, término que conviene anotar), como lo puede ser una API, una base de datos, un archivo Excel generado por algún sistema de reportes, etc.

• Transform - transformar los datos extraídos, ya sea mediante:

  • cambiar los tipos de datos (de número a texto)

  • su formato (como suele suceder con las fechas)

  • los nombres de los campos

  • aplicar lógica de negocio

  • eliminar elementos no deseados (como cuando te viene un precio con el signo $ y vos querés guardar números, no texto)

  • agregar metadatos (otro término importante) para enriquecer a los datos originales y darles contexto, etc.

  • o simplemente hacerlos coherentes para análisis posterior

  • esto lo vimos en la edición anterior, ¿te acordás?

• Load - cargar los datos en una base de datos destino, un warehouse, otro archivo Excel o cualquier otro activo de datos que el usuario final de estos datos utilice

Este enfoque se usa mucho cuando:

• Las transformaciones son pesadas y requieren motores externos (Python, Spark, etc.).

• El destino no está preparado para hacer cómputo intensivo (por ejemplo, un Data Warehouse clásico).

• Querés controlar toda la lógica de transformación fuera del sistema final.

ELT — Extract, Load, Transform

En los últimos años, con la aparición de data warehouses modernos (como Snowflake, BigQuery o Redshift), el orden de las letras cambió… y también la forma de trabajar.

En el enfoque ELT, primero se:

1. Extraen los datos desde la fuente,

2. Cargan tal cual (en crudo) en el warehouse,

3. Y Transforman directamente dentro del warehouse, usualmente con SQL.

La idea es aprovechar el poder de cómputo y la escalabilidad del warehouse para transformar los datos una vez cargados.

Este patrón es ideal cuando:

• El warehouse es potente y soporta grandes volúmenes.

• Las transformaciones están mayormente basadas en SQL.

• Se quiere guardar el los datos en crudo (también llamado raw data o capa raw) sin modificar, para poder re-procesarlo o auditarlo después.

¿Cuál patrón utilizar?

Si te estás haciendo esta pregunta, dejame decirte que es perfectamente válida. ¿En qué casos cargo todo primero y luego transformo (ELT)? ¿O cuándo me conviene irme por el clásico de extraer, transformar y servir los datos al usuario final (ETL)? ¿O es que uno de los dos patrones es definitivamente mejor en general? Como me gusta decir…depende.

No existe bala de plata, no hay uno mejor que el otro per se, y es más, hasta puede suceder (y sucede) que un mismo proyecto requiera una combinación de ambos enfoques, y de hecho, en muchos proyectos se combinan ambos.

Por ejemplo:

• Extraés datos crudos (E),

• Los transformás con Spark (T),

• Los cargás en un warehouse (L),

• Y luego hacés transformaciones adicionales con SQL (T).

¿ETLT? Podríamos decir que sí 😄

Lo importante es que tu pipeline tenga claridad, trazabilidad y eficiencia, sin importar la etiqueta.

Lo que quiero que te lleves

• ETL → Extract → Transform → Load → los datos se limpian antes de almacenarse.

• ELT → Extract → Load → Transform → los datos se cargan primero y se transforman dentro del warehouse.

• Ninguno es “mejor”: todo depende del contexto, los recursos y los objetivos del proyecto.

• Y sí, incluso puede haber pipelines que sean solo EL (sin transformación), cuando el destino ya está preparado para consumir los datos en bruto.

• No existe una bala de plata que solucione y abarque todos los casos. ETL no es mejor que ELT per se, y lo inverso también es cierto. Todo depende de las necesidades del negocio, las fechas límite y las limitaciones técnicas/monetarias.

💭 Debug Mental

La Trampa de la Pasión

Lo habrás escuchado mil veces: “Encontrá tu pasión y seguila”, “Si sigues tu pasión, la felicidad viene a continuación”. Y estoy seguro de que debe haber muchas formas más de decir lo mismo.

El punto es que…¿qué significa “encontrar la pasión”? ¿Es acaso algo accionable? Para la mayoría de personas, está complicado. ¿Qué es nuestra pasión? ¿Vos sabés cuál es la tuya? E incluso si la encontraste, ¿tenés un plan para “seguirla”?

¿Será que acaso este consejo hace más mal que bien?

En una investigación de 2012 liderada por Robert J. Vallerand titulada “El papel de la pasión en el bienestar psicológico sostenible”, se presentó el Modelo Dualista de la Pasión (MDP), que distingue entre dos tipos de pasiones, la pasión armoniosa y la pasión obsesiva:

• Armoniosa: cuando se elige libremente una actividad que te aporta significado, que sentís que te llena como individuo e integrás esa actividad en tu vida, sin que la actividad te controle

• Obsesiva: cuando tu identidad depende de cierta actividad, al punto tal de que se siente como una carga a la que no podés renunciar

Y acá viene lo interesante: la opinión principal del artículo es que el simple hecho de dedicarse a una actividad que nos apasiona no garantiza resultados positivos; lo que realmente importa es el tipo de pasión que se tiene.

Las personas con pasiones armoniosas reportaron mayores niveles de alegría, concentración o foco. En cambio, quienes perseguian una pasión obsesiva experimentaron estrés, conflictos emocionales, y, ojo con esto, burnout.

En el artículo se previene sobre el famoso consejo que mencioné al principio, de “seguir (o encontrar) tu pasión”. Este consejo implica que la pasión es algo con lo que se nace, o que a lo mejor se descubre de forma instantánea, ahí formada y lista para que la sigas.

Creer esto generalmente conduce a mucha frustración. Y claro, intentás algo, no sentís esa “chispa” (que supuestamente deberías sentir) y entonces…lo abandonás ante la primera señal de dificultad.

Los investigadores argumentan que la alegría proviene de construir una relación significativa con una actividad, sin esperar que dicha actividad produzca felicidad instantáneamente.

¿Y si resulta que la pasión no es algo que se encuentre? A lo mejor la pasión puede venir como resultado de algo más.

Según un autor que descubrí hace poco, Scott Galloway, seguir nuestros talentos puede conducir a la pasión. Pasión que proviene del esfuerzo, la maestría y la conexión.

Opiniones hay muchas, pero yo estoy cada vez más convencido de que la pasión puede construirse. Pero hay que esforzarse y ser consistente, a la vez que exploramos actividades que nos den una sensación de plenitud, nos llenen como personas y también se nos dé bien realizar.

¿Difícil? Sí. ¿Posible? También.

📚 Datazo

Tené tu propio S3 en tu PC

Hoy te traigo una herramienta muy copada si trabajás con Amazon S3 frecuentemente.

¿Te imaginás contar con tu propio S3 de manera local y totalmente gratis y sin depender de la nube? Eso es lo lindo de MinIo.

¿Qué es MinIo?

MinIO es una herramienta open source que emula el servicio de almacenamiento de objetos de AWS (Amazon S3).

En otras palabras, podés crear y administrar tus propios buckets, subir y descargar archivos, generar presigned URLs y mucho más… sin salir de tu máquina.

Y lo mejor: habla el mismo idioma que S3.

Eso significa que si en tu código usás el SDK de AWS (por ejemplo, boto3 en Python), prácticamente no necesitás cambiar nada para usar MinIO en lugar del S3 real. Mirá:

Listo. Tenés un sandbox de S3 completamente funcional para tus desarrollos o experimentos.

¿Por qué usarlo?

Acá te van algunas razones por las que vale la pena tenerlo en tu toolkit 👇

1. Entorno local y sin costo: perfecto para practicar o testear sin preocuparte por gastos en AWS.

2. Aislamiento: podés experimentar sin afectar buckets reales o datos sensibles.

3. Velocidad: al correr localmente, las pruebas son mucho más rápidas que subir y bajar archivos desde la nube.

4. Integración con herramientas de Data Engineering: MinIO se lleva de maravilla con frameworks como Airflow, Spark o Prefect, que suelen interactuar con almacenamiento tipo S3.

¿Cómo instalarlo?

Existen varias maneras, pero la que te recomiendo (y de hecho yo mismo uso) es su versión contenedor de Docker. En este post de mi autoría vas a encontrar un paso a paso bien preciso y detallado para que tengas MinIo instalado en tu máquina, ¡con interfaz gráfica y todo!

En resumen

MinIO es una herramienta genial para quienes:

• Quieren practicar o testear integraciones con S3 sin depender de AWS.

• Necesitan un entorno local rápido y seguro.

• Buscan aprender sobre almacenamiento de objetos y su arquitectura.

En definitiva, es un gran aliado para Data Engineers y Developers que trabajan en entornos híbridos o con pipelines complejos.

Resumen nivel 5

Lo que quiero que te lleves de esta edición es:

• ETL y ELT son dos patrones de diseño muy utilizados para construir pipelines de datos. Aprendé sus bases, pero sobre todo, el propósito detrás de cada uno. Son herramientas después de todo.

• A lo mejor no hay que encontrar y seguir tu pasión. A lo mejor simplemente se trata elegir una actividad significativa, comprometerse y construir una relación sana con esa actividad. Puede que ahí nazca una pasión armoniosa, esa pasión que de verdad pueda nutrir tu alma.

• MinIo es una hermosa herramienta para desarrollar con S3 de manera veloz, sin mayores consecuencias y gratarola.

• Cómo mueve y procesa datos un/a Data Engineer

• Los conceptos de redes que te pueden servir en AWS (y cualquier nube)

• La lección que nos comparte un sabio estoico sobre estar en varios lados a la vez

• Y una herramienta muy útil si te manejas con varias cuentas en AWS

🧠 El Núcleo

Cómo mover y procesar datos

Si estás siguiendo esta newsletter desde el principio, recordarás que en ediciones anteriores vimos qué es la Ingeniería de Datos y los conceptos que hay que dominar para tener una base sólida. También charlamos un poco sobre aspectos relacionados, como Python y Git.

Es hora de entrar en lo “divertido” (que lo es, sí, pero a veces no tanto): ¿cómo es que el/la Data Engineer mueve y procesa los datos?

Sabemos que este profesional construye sistemas encargados de procesar datos. Estos sistemas ingieren datos y los llevan a cierto lugar. Las preguntas que ahora surgen son:

• ¿cómo lo hacen?

• ¿cómo se mueven los datos de un lugar a otro de manera que su estado final (o intermedio dependiendo del caso) genere valor para los interesados en dichos datos?

La respuesta es una palabrita/concepto que quizá escuchaste antes: una pipeline.

Pero antes de eso, la duda más importante es: ¿qué es procesar datos? ¿Agarro un Excel y lo paso por una picadora para obtener 200gr. de datos de clientes?

Más allá del chiste malo, la necesidad de procesar datos es muy real. Esto suele involucrar:

• remover datos indeseados o que ya no son necesarios

• convertir datos de un tipo hacia otro tipo que resulte más sencillo de utilizar

• organizar los datos, de modo que otros interesados, como los Data Analysts, puedan encontrar fácilmente lo que necesitan

• …y varios motivos más

Para lograr estos y otros cometidos se construyen sistemas que lo hagan de manera automática, eficiente y segura (aspectos muy importantes, no los olvides), como una pipeline.

Una pipeline (o tubería o canalización) de datos asegura que los datos fluyan de manera eficiente en una organización, automatizando:

• Extracción

• Transformación

• Combinación

• Validación

• Carga

• y otros factores…

…y de esta manera, reducir:

• intervención humana

• errores

• el tiempo que le toma a los datos para fluir

Pero esto es tan solo la punta del iceberg:

• ¿sabías que generalmente cada componente de una pipeline debe ejecutarse en un orden y, a veces, intervalos específicos?

• ¿Y si te digo que hay formas distintas de ingerir datos desde una fuente (o sistema fuente, como vimos en la primera edición)?

• Es más, ¿sabías que hay varios enfoques para mover y procesar datos?

Si te piqué la curiosidad con alguna de estas preguntas (o todas), pasate por mi blog donde toco este y otros temas relacionados con las tuberías de una manera un poco más completa en este post.

Y como suelo decir, si tenés alguna duda (o crees que hay algo que falta o podría mejorarse), no dudes en contactarme a través de mis redes.

En la próxima edición vamos a hablar sobre ETL y ELT, dos enfoques muy utilizados al momento de construir pipelines.

☁️ La Senda del Nubearquitecto

Networking para Arquitectos de Soluciones

Primero que nada, no. Con “networking” no me refiero al acto de hacer contactos. Esta vez hablo de las viejas y queridas redes de computadoras. ¿IP? ¿DNS? ¿Puertos? ¿Te suenan esos términos?

Hace ya unos meses que empecé a prepararme para la certificación SAA-C03 de AWS y llegó un momento donde tuve que frenar momentáneamente dicha preparación ya que me estaba faltando un concepto general muy importante para moverse dentro del ecosistema de AWS (aunque en realidad te sirve para cualquier nube), y eso es redes o networking.

El tema es: ¿cuánto hay que saber? Si estás interesado/a en certificarte en AWS esto seguramente te interesa. Te doy la buena noticia (y esto es mi opinión personal combinada con una pequeña investigación que hice al respecto): no hace falta saber TODO.

De hecho cuando empecé a moverme en AWS tenía muy poco conocimiento de redes en general. Y no fue muy buena idea.

Muchas cosas me hacían ruido, no las entendía y eso me dejaba en la duda de si realmente estaba ofreciendo una buena solución. Pero igual podía moverme con cierta confianza.

Mi recomendación es que no te saltes estos conceptos. Prestales atención, incorporalos, al menos tené nociones.

Vamos con lo que considero es Networking Basics para Arquitectos de Soluciones (o personas que aspiran a moverse en AWS con confianza y buenas bases).

Atenti que esto viene un poquito cargado.

Conceptos básicos de redes para la nube

• Clientes y servidores

  • Un cliente hace una petición, un servidor responde.

  • Ejemplo: Tu navegador (cliente) pide una página a Google (servidor).

• Hosts y dispositivos de red

  • Host = dispositivo final que se conecta a la red (PC, celular, servidor).

  • Dispositivos de red = routers, switches, access points.

  • Ejemplo: Tu notebook conectada al router Wi-Fi de tu casa.

• Conexiones cableadas e inalámbricas

  • Cableadas: Ethernet, más estables.

  • Inalámbricas: Wi-Fi (802.11a/b/g/n/ac/ax), más cómodas pero menos estables.

  • Ejemplo: Conectarte al router con cable vs Wi-Fi.

• Modelos de capas (TCP/IP y OSI)

  • Sirven para entender en qué nivel actúan los protocolos.

  • Ejemplo: IP (capa 3) se encarga de llegar al host, TCP (capa 4) asegura el orden de los datos, HTTP (capa 7) define el contenido.

• Ethernet, MAC y ARP

  • Ethernet: protocolo de enlace cableado.

  • MAC: dirección física única de cada interfaz de red.

  • ARP: traduce una IP a una MAC.

  • Ejemplo: Tu PC necesita enviar algo a 192.168.1.10 → usa ARP para preguntar: “¿Quién tiene esta IP?”.

• Protocolo IP (IPv4, IPv6, CIDR)

  • IP identifica hosts en la red.

  • CIDR (/24, /16) define el rango de direcciones en una subnet.

  • Ejemplo: 192.168.1.0/24 → IPs de 192.168.1.1 a 192.168.1.254.

• DHCP (Dynamic Host Configuration Protocol)

  • Asigna IPs automáticamente a los hosts.

  • Ejemplo: Te conectás al Wi-Fi y el router te da 192.168.1.45.

• Enrutamiento entre redes

  • Los routers conectan redes distintas.

  • Ejemplo: Tu LAN hogareña (192.168.1.0/24) → Router → Internet (WAN).

• TCP y UDP

  • TCP: confiable, ordenado (ej: web, correo).

  • UDP: rápido, sin control (ej: videollamadas, juegos online).

  • Ejemplo: YouTube usa TCP para cargar la página, UDP para transmitir el video.

• Protocolos de la capa de Aplicación

  • Definen reglas de comunicación entre aplicaciones.

  • Ejemplo: HTTP (web), FTP/SFTP (archivos), SMTP/IMAP (correo).

Conceptos que aparecen mucho en la nube

• Subnets públicas y privadas

  • Pública: accesible desde Internet.

  • Privada: accesible solo dentro de la VPC.

  • Ejemplo en AWS: un servidor web en subnet pública, una base de datos en subnet privada.

• NAT (Network Address Translation)

  • Traduce IPs privadas a una IP pública para salir a Internet.

  • Ejemplo: 100 PCs en tu casa salen a Internet usando una sola IP pública.

• Firewalls y reglas de seguridad

  • Definen qué tráfico entra o sale.

  • Ejemplo en AWS: Security Group que permite solo HTTP (80) y HTTPS (443).

• VPNs y túneles

  • Conectan redes privadas a través de Internet de forma segura.

  • Ejemplo: Una empresa conecta su oficina con su VPC en AWS mediante VPN.

• DNS (Domain Name System)

  • Traduce nombres a IPs.

  • Ejemplo: google.com → 142.251.128.142.

  • En AWS: Route 53 administra tus dominios.

• Load Balancers (Balanceadores de carga)

  • Distribuyen tráfico entre varios servidores.

  • Ejemplo en AWS: un ELB reparte las peticiones entre 3 instancias de tu aplicación web.

Si, parece un MONTÓN para aprender. Pero como te dije anteriormente, lo importante no es saberlo todo en profundidad.

Andá concepto por concepto, entendé lo básico pero sobre todo comprendé qué problema resuelve cada uno.

¿Te gustaría abarcar estos y otros conceptos de manera ordenada, con un montón de ejemplos y ejercicios para practicarlos?

Entonces este curso gratuito, organizando nada más y nada menos que por Cisco te va a venir de 10.

Sumate al Networking Basics. Es una verdadera inversión en tu camino profesional dentro de la nube.

💭 Debug Mental

No estés en varios lados a la vez

Hoy voy a ponerme filosófico y a darme el lujo de ser un poco hipócrita, porque sí. Yo también tengo mi lado oscuro, tengo mis falencias y hay una que otra mentira que me cuento a mi mismo. Pero peor aún, me creo esas mentiras.

Lo importante es siempre tomar consciencia de todo eso, traerlo “a la luz” y reflexionar: ¿qué es eso que sé que no está bien, que podría remediar y que realmente remediaría?

Porque yo vengo ahora a darte un consejo que yo mismo rompo en más de una oportunidad. Por lo que, de humano a humano, te pido que me tengas paciencia, y que puedas hacer el esfuerzo de “escuchar” el mensaje que quiero transmitirte.

Un gran filósofo estoico de la antiguedad dijo:

“Cuando intentas estar en demasiados sitios a la vez, no estás en ninguno. Concéntrate en algo hasta que lo consigas. Luego, a por otra cosa” — Séneca, hace un montón de años

En la sociedad moderna en la que vivimos, donde parece que se valora mucho el ser multitasking y escuchar un podcast mientras se está cocinando (si es algo que haces, por fa no te sientas atacado/a, es solo un ejemplo para ilustrar un punto), el concentrarse en una sola cosa parece un acto de rebeldía.

Y Dios mío que los que estamos en la industria IT padecemos de esto eh. Me pasó mil veces de estar estudiando algo y decirme “bueno, voy a completar este curso de punta a punta, voy a ponerme las pilas y ser constante”. ¡PERO NO!

Heme aquí…

• haciendo un curso de Cisco sobre Networking (el que te pasé más arriba jeje)

• preparándome para la Solutions Architect Associate de AWS

• intentando ponerme al día con un programa de especialización en Ingeniería de Datos.

¿Te despierta algo de admiración todo eso que te cuento? Si por alguna razón te resulta admirable, dejame decirte que no es nada divertido…ni admirable.

Anotarme en todo es pasar por alto el consejo que dió Séneca miles de años atrás (qué loco, hace miles de años algunas personas la tenían más clara que nosotros, que vivimos en la era de la IA).

Pero esta idea no aplica solo a tus estudios, aplica a

• hábitos

• lecturas

• proyectos

• propósitos

Sé que no es fácil aplicar algo como esto.

El mundo, que es cada vez más depredador de nuestro tiempo, nos empuja a hacer de todo y para ayer.

Pero si podés llegar a anclarte a un propósito, uno solo, el tiempo suficiente para llevarlo a cabo de la manera más eficiente que puedas, entonces creo que habrás ganado.

Igual, ojo. Esto tampoco quiere decirte que te entregues a algo y que descuide todos los demás aspectos de tu vida.

Hacer un solo curso no implica que por ejemplo descuides tu salud, o alimentación, a tu familia/hijos, etc.

Balance, mi joven padawan.

Creo que es sano tener más de un objetivo, siempre y cuando sea una cantidad manejable y realista.

Espero poder un día decirte con total confianza: “Logré concentrarme en una sola cosa. Logré dominar mi impulso y gané FOCO.”

Si ese día llega, dá por seguro que voy a contarlo por acá.

En el mientras, te acompaño en el sentimiento si esto es algo que también te cuesta. 🫂

📚 Datazo

¿Manejás varias cuentas de AWS? Esto te puede servir

Como de costumbre, en esta sección te comparto un recurso o herramienta para hacerte la vida más fácil.

Si trabajás con AWS y gestionás múltiples cuentas (la tuya, la de clientes, entornos distintos...), sabés que manejar perfiles, sesiones, y credenciales temporales puede ser un dolor de cabeza. 😵‍💫

Hace poco empecé a usar Leapp y me cambió la forma de trabajar con AWS.

Es una app de escritorio open source que te permite:

✅ Iniciar sesión fácil

✅ Gestionar múltiples cuentas

✅ Obtener credenciales temporales

✅ Trabajar seguro, sin exponer secretos

Yo lo uso en conjunto con boto3 (SDK de Python para AWS). En lugar de lidiar con sesiones que vencen o editar archivos .aws/credentials, simplemente elijo un perfil en Leapp, y TUKI. ¡Listo para trabajar! 🔧🐍

Ideal para devs, freelancers, y equipos que cambian seguido entre cuentas o roles.

Si usás AWS todos los días, probalo. Es de esas herramientas que no sabés que necesitás hasta que la usás.

🔗https://leapp.sh

Resumen nivel 5

Lo que quiero que te lleves de esta edición es:

• Los Data Engineers construimos pipelines para mover y procesar datos. Esto nos permite automatizar la extracción, procesamiento y entrega de datos a las personas correctas, de la forma correcta, en el tiempo correcto, y de una manera eficiente y costo-efectiva.

• Podés aprender AWS sin saber redes, pero no te lo recomiendo para nada. Empapate de los conceptos básicos, entendé qué problemas resuelve cada concepto y asegurate unos buenos fundamentos en tu camino en la nube.

• No estés en varios lados a la vez, aunque el mundo quiera llevarte en esa dirección. 1 libro, 1 curso, 1 proyecto, 1 objetivo. Completalos, y luego a seguir con otra cosa. (Y sí, lo estoy escribiendo para mí esto también).

• ¿Te movés entre varias cuentas de AWS? ¡Usá Leapp papá! Hermosa herramienta

¡AH! Y por cierto, si por una de esas casualidades estás leyendo esto desde el Konex por motivo de la Nerdearla, ¡búscame! Hoy voy a estar trabajando desde allí. ¡Será un placer conocerte! 🤝🏻

• 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:

1. git init → crear un repositorio

2. git add → preparar archivos para guardar

3. git commit -m "mensaje" → guardar un cambio (tomar la “foto”)

4. git status → ver qué cambió

5. 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!

• 8 conceptos esenciales de Python para Data Engineering

• ¿Cómo comenzar en AWS? Una guía práctica

• ¿Sos perfeccionista? Esto te interesa

• El libro de AWS que necesitabas

🧠 El Núcleo

8 conceptos esenciales de Python para Data Engineering

Python es lo que mucho denominan el lenguaje de facto en data. El rol de la Ingeniería de Datos no es ajeno a este lenguaje, de hecho, todo lo contrario, puede llegar a una herramienta del día a día en muchas empresas.

Pero, ¿qué es lo que tiene que conocer un Data Engineer sobre este lenguaje para ser competente? Veamos brevemente 8 conceptos básicos.

1. Variables: un espacio de almacenamiento en memoria volátil (RAM) que lleva un identificador (el nombre) y guarda un valor.

2. Operadores: aritméticos, de comparación y lógicos para trabajar con variables.

3. Estructuras de datos: formas de representar datos. Cada una tiene sus pros y contras, como así también casos de uso ideales. Consideralas como herramientas que deben usarse en el momento indicado (un martillo no siempre es la mejor opción, a veces es bueno ir por un destornillador). Algunas estructuras destacadas para estudiar…

   1. Listas: colección ordenada de elementos que pueden ser accedidos si se conoce la ubicación del elemento (también conocido como índice)

   2. Diccionarios: colección de pares clave-valor donde cada clave está mapeada a un valor usando una función hash. Muy eficientes en búsquedas

   3. Set: también conocida como “conjunto”, es otra colección de elementos similar a la lista pero que no admite valores duplicados

   4. Tupla: colección ordenada de elementos que no puede ser modificada, o en otras palabras, es inmutable

4. Loops: o bucles, que permiten que una porción de código pueda ser repetida una cierta cantidad de veces.

   1. Comprehension: una manera de escribir loops de forma compacta en listas, diccionarios o sets

5. Funciones: un bloque de código que puede ser reutilizado según sea necesario. Esto permite tener cierta lógica definida en un único lugar, permitiendo que nuestro código sea más mantenible y fácil de utilizar.

6. Clases y Objetos: esto hace referencia al paradigma de programación orientada a objetos, concepto importantísimo. Se puede pensar en una clase como un plano y a los objetos como creaciones realizadas en base a ese plano.

7. Librería: conjuntos de módulos y funciones reutilizables. Python trae muchas por defecto y se pueden instalar más con pip, su gestor de paquetes más famoso. En próximas ediciones vamos a ahondar en algunas librerías particularmente útiles para Data Engineering.

8. Excepciones: manejo de errores para que el programa siga funcionando ante problemas.

Como todo lenguaje, Python es un mundo. Pero no te abrumes. Si no sabes nada de nada, lo mejor es ver cuál puede ser tu próximo paso y arrancar por ahí.

¿Te gustaría aprender este lenguaje de manera ordenada, concepto por concepto y con ejercicios para practicar? Entonces tengo lo que buscás: Exercism.

Exercism es una plataforma gratuita (en inglés) con ejercicios guiados, mentoría de otros programadores y retos prácticos. Te ayuda a pasar de la teoría a la práctica rápido, con feedback real y casos concretos que simulan problemas del mundo real. Ideal para afianzar lo que aprendas en tus primeras lecciones.

☁️ La Senda del Nubearquitecto

¿Cómo comenzar en AWS?

En la edición anterior vimos razones para comenzar nuestro viaje en la nube en AWS. El tema ahora es: ¿cómo? Recuerdo haberme hecho la misma pregunta en su momento cuando decidí que quería certificarme.

Quizá te preguntes: “Pero Elias, ¿decidiste certificarte sin saber cómo empezar en AWS?”

Bueno, mi exposición a la nube de Amazon comenzó cuando arranqué en mi trabajo actual. Me vi forzado a aprender conceptos mediante práctica y error, junto a la supervisión de algunos compañeros que tuvieron la paciencia y amabilidad de transmitirme sus conocimientos.

Fue díficil, tuve que complementar con búsquedas en Google, la documentación de AWS, Stack Overflow, la IA de turno, etc.

Digamos que empecé, pero…

• sin ninguna base teórica fuerte

• con el estrés añadido de tocar cosas en producción (donde sí, me mandé algunos mocos, hay que decirlo)

• y casi que en tiempo récord porque había que resolver cuanto antes los requisitos del cliente (así es el mundo startup jeje).

Pero eso no tiene porqué pasarte a vos. Te traigo una mini guía que lejos está de ser infalible, pero que de verdad espero te permita dar tus primeros pasos en este proveedor de la nube. ¿Qué vas a ver?

1. Pequeña intro a Cloud Computing

2. Qué es AWS y porqué importa

3. Conceptos básicos a tener presente

4. Servicios esenciales y más usados

5. Recursos para empezar a empaparte con la filosofía de la nube de Amazon

¡Bajate la guía desde acá y ponete en acción hoy mismo! 🚀

💭 Debug Mental

¿Sos perfeccionista? Esto te interesa

En 1931, Martha Graham —una de las coreógrafas más influyentes del siglo XX— dijo: "Está perdido, todo el trabajo de un invierno está perdido". Estaba abrumada por la autocrítica, consumida por la idea de no estar a la altura.

Personas como Da Vinci, Steve Jobs o Ralph Ellison también sufrían lo mismo: altos estándares que los hacían geniales, pero también los paralizaban.

A mí también me pasó. Me pasa. Ese perfeccionismo que se disfraza de “exigencia” y te convence de que mejor no hagas nada hasta que esté impecable. Y cuando te das cuenta, no hiciste nada.

El perfeccionismo es un disfraz elegante de la procrastinación. Si no lo hiciste, no importa si fue por vagancia o por miedo a no estar a la altura. El resultado es el mismo: no lo hiciste. Y tu potencial se queda ahí, detenido.

¿Cómo salió Martha de esa trampa mental? Gracias a Louis Horst, su director musical, que le dijo:

“No siempre se puede crear en el mismo nivel. La Sexta Sinfonía siguió a la Quinta, pero sin la Sexta, no tendríamos la Séptima. Las transiciones son igual de importantes que los logros.”

¿Tenés una idea? ¿Un proyecto que quieras encarar? ¿Un negocio que emprender, una carrera que iniciar, un sueño que perseguir? Mandate. Arrancá.

Investigá pero no te quedes ahí. EJECUTÁ.

Acción, acción, acción.

Obvio, que tus pasos también estén acompañados de visión, pero ponete en movimiento. A medida que lo hagas, vas a ir transicionando hacia algo nuevo, hacia una nueva versión tuya. Y ese recorrido tiene el mismo valor que los logros que alcances.

PD: si me hubiera quedado paralizado por el análisis, hoy no estarías leyendo esto ni estarías suscrito/a a esta newsletter, porque no existiría 😉

📚 Datazo

El libro de AWS que necesitabas

Ahora que vimos algunas recomendaciones y lineamientos para dar tus primeros pasos en AWS, acá te va una recomendación especial: AWS Fundamentals.

Primero que nada no quiero venderte humo: el libro no es gratuito. Podría subir el PDF o archivo ebook en algún lado y pasarte el link, pero no me parece ético. Hay un trabajo muy grande detrás del libro y dártelo gratis sería pisotear el trabajo de todas las personas que contribuyeron en él.

Con eso en mente, te comparto rapidito mi opinión personal de porqué creo que es un muy buen recurso para interiorizarte en la filosofía de AWS y su amplia gama de servicios:

• Nada de vueltas innecesarias. El libro va al núcleo de cada servicio y te cuenta casos de uso reales. Los ejemplos me parecen super didácticos

• No abarca todos los servicios habidos y por haber, sino que va a los más importantes y los que componen la oferta principal de AWS

• No está orientado a ninguna certificación, simplemente intenta darte lo que necesitás para resolver problemas de verdad

• Tiene una gran introducción a IAM y desde entrada te comenta su importancia (y no exageran eh), algo que me parece vital ya que la seguridad tiene que ser nuestra principal preocupación como profesionales en cualquier área de IT

• Hay unas infografías (vendidas por separado, o en combo con el libro, hay que decirlo) que son excelentes para visualizar los puntos claves de cada servicio de un vistazo rápido

• El libro y las infografías se actualizan constantemente y cada nueva actualización es gratis, no tenés que comprar el libro/infografías de nuevo. Simplemente te envían la nueva versión a tu correo.

Si todo esto te cierra y te parece interesante, te dejo el enlace acá para que lo puedas comprar. Ojalá sea una buena guía para tu camino en AWS.

Ahora, si decidís que no te interesa o momentáneamente te es imposible comprarlo, tranqui. Por fortuna estás suscrito/a a esta newsletter y buena parte del contenido de AWS que voy a compartir pronto está basado en este libro 😉

• ¿Qué es la Ingeniería de Datos? ¿Qué hay que aprender?

• Porqué aprender AWS

• No digas solamente “hola” por Slack!

• El Valor de hacer Comunidad

• Un blog post que seguro te va a servir

🧠 El Núcleo

¿Qué es la Ingeniería de Datos? ¿Qué hay que aprender?

Tal como conté en el post introductorio de esta newsletter, actualmente me desempeño como Ingeniero de Datos en una startup con clientes alrededor del mundo. Y honestamente no pensé que este rol me terminaría gustando tanto. Obviamente no todo es color de rosas, hubo y hay momentos donde las cosas se complican y no es tan “divertido”, pero si decidí aceptar el rol, es porque:

1. Me gustan los buenos desafíos

2. Me encanta aprender

Pero no vengo a contarte en detalle mi experiencia en este rol aún, sino que el enfoque que quiero tomar en esta primera edición es más general y abarcativo. Ya habrá tiempo para contarte un poco mi historia en detalle, cómo entre al rol, etc.

Arranquemos por lo más importante: ¿Qué es la Ingenieria de Datos? ¿Qué hace un profesional en este rol?

Te lo digo en una oracion simple: movemos datos de un lugar a otro. ¿Qué tipos de datos? Uff, de lo que te imagines. Existen muchos tipos y estos pueden tomar distintas formas y venir en distintos “envases”, como un archivo Excel, un CSV, desde una API, una base de datos, y un largo etc.

Nuestra misión (generalmente) consiste en:

• extraer los datos desde una fuente (tal como te comento en el parrafo anterior)

• “meter mano” en dichos datos a traves de transformaciones que enriquecen estos datos, o los limpian, o les aplican ciertos calculos, etc. Ojo, no es que alteramos los datos como se nos dé la gana, para nada. En la mayoria de las situaciones estas transformaciones siguen lo que se conoce como “reglas de negocio”, es decir, lo que determina la empresa, el cliente o el dominio en el que estamos trabajando (no es lo mismo procesar datos financieros que datos referentes a la salud o datos provenientes de redes sociales).

• y finalmente entregamos estos datos de la forma correcta, a las personas correctas, en el tiempo correcto. Lo ideal es que todo lo que hagamos con estos datos sirvan a un propósito y que los consumidores de estos datos puedan acceder a ellos en el tiempo y forma que mejor resuelva sus necesidades.

Lo que te cuento aca es solamente un aspecto de todas las tareas que puede desempeñar un/a Data Engineer. Existen muchos otras cuestiones a considerar, como la seguridad, qué solucion de almacenamiento es ideal para cada caso, los tiempos o el timing para extraer o servir los datos, y un largo etc. Puede parecer abrumador, y un poco lo es, no te voy a mentir. Pero siempre intento mirar este tipo de situaciones bajo otro cristal y a veces me digo a mi mismo: “Es mucho, ¡pero mirá todo lo que tengo para descubrir!”.

Ah, y esto no es todo. Dependiendo de la empresa, se espera que este/a profesional tambien sepa de:

• desarrollo de software (vas a tener que programar bastante)

• alguito de Machine Learning

• alguna que otra cosita de DevOps (CI/CD, Docker, etc.)

• que tengas conocimiento sobre la nube y que tengas nociones de algun proveedor en particular (como AWS, Azure, GCP, etc.)

• y que te comuniques muy bien, no todo es tecnologia mi joven padawan (?, hay que saber hablar con la gente y formular las preguntas correctas para llegar a las respuestas correctas

¿Qué hay que aprender?

Existen un montón de herramientas y soluciones a aprender. Pero no nos volvamos locos, porque por ahora parece que solamente te estoy diciendo “toma, aprendete toooooodo esto si querés arrancar en Ingeniería de Datos”. Como decimos en Argentina, vamos a bajar un cambio.

¿Qué conocimientos fundamentales te pueden servir mucho en este rol, independientemente de donde trabajes? Acá te va una mini guía:

• Python, el lenguaje “oficial” (notese las comillas) para trabajar en datos

• Obviamente, conceptos de programacion (o al menos nociones) como programacion funcional, OOP (objetos). Y es un gran plus si sabes sobre complejidad algoritmica. No es que te tengas que saber Big O de pies a cabeza, pero sí saber que tener bucles for anidados puede llegar a comprometer la eficiencia de tu script o flujo.

• SQL, otro lenguaje importantisimo. Te va a tocar lidiar con bases de datos y warehouses basados en este lenguaje. Y de hecho tu calidad y habilidades para escribir consultas claras, legibles, eficientes y escalables van a impactar en los sistemas que construyas con los años.

• NoSQL, o al menos nociones de cómo funciona y las diferencias con bases de datos relacionales. No todo puede ir en tablas y no todo puede o tiene que estar expresado mediante relaciones.

Y la lista puede seguir. Pero no te desanimes. Lo principal es ir tranqui, despacio. Si queres entrar más en detalle fijate la sección “Datazo” de esta misma edición, donde te dejo algo que te va a servir 😉

☁️ La Senda del Nubearquitecto

Porqué aprender AWS

Como vimos antes, parte clave del rol de un/a Data Engineer es entender la nube y cómo usar servicios como AWS, Azure o GCP.

Pero incluso si no te interesa la Ingeniería de Datos, tener nociones de cloud suma mucho a tu perfil profesional. No es la solución mágica a todo (¡nada lo es en informática!), pero la nube llegó para quedarse.

Pensá esto: desde tu compu podés levantar una base de datos (como RDS), un servidor virtual (EC2), o un almacenamiento escalable (S3), con unos pocos clicks. Sin instalar casi nada, y todo gestionado por equipos que se dedican 100% a eso. Alta disponibilidad, seguridad, eficiencia... y vos sin mover un cable.

Ese es el poder de la nube pública: acceso rápido a infra y servicios complejos, pagando solo por lo que usás. Por eso dicen que “la nube es la computadora de otra persona”.

Ahora bien, si estás pensando por dónde empezar tu camino en la nube, te cuento por qué AWS es una excelente opción:

• Es el proveedor líder del mercado, muchas empresas ya lo usan.

• Tiene excelente documentación, recursos gratuitos y comunidad.

• Es ideal para aprender conceptos clave que podés aplicar en otras nubes.

• Sus certificaciones (como la Solutions Architect Associate) están muy bien valoradas en el mercado laboral.

• ¡Y lo podés probar gratis! (el famoso “free tier”, bien aprovechado, da para mucho).

Eso sí: no te cases con ningún proveedor. Entender la nube es más importante que volverse fanático/a de uno. ¡Mantené la cabeza abierta y sé adaptable!

¿Listo? ¿Te convenci? Bueno, atento/a que en proximas ediciones te voy a contar cómo comenzar tu viaje en la nube de AWS y cuál certificación puede ser la ideal para vos según tu experiencia y objetivos.

🚀 Carrera y Habilidades

¡No digas solamente “Hola” por Slack!

Imaginate esta conversacion por Slack o, dios no lo quiera, Teams.

Un compa: “Hola, como estas?

Vos: “Hola, todo bien. Decime, que necesitas?”

El compa a los 5 minutos: “Tenes idea de donde puedo encontrar la key de la API que me trae los datos de los clientes?”

Ahora, imaginate la misma conversación pero yendo mas al grano.

Un compa: “Hola, como estas? Tenes idea de donde puedo encontrar la key de la API que me trae los datos de los clientes?”

Vos: “Hola, buen dia! Si, la podes encontrar en SecretsManager bajo el nombre customers_service_api_key.”

Puede parecer tonto, pero hay una diferencia importante entre ambas conversaciones. En la primera conversacion, tuviste que esperar a que tu compañero te cuente que es lo que necesita, y extender la conversacion innecesariamente. Ademas, no se si te pasa, pero cuando estoy concentrado en la tarea que tengo entre manos, lo que menos quiero es distracciones innecesarias. Y un mensaje solamente saludando o diciendo “hola” puede llegar a ser una distraccion innecesaria.

La comunicación efectiva es importante en todo ámbito y más a nivel profesional. La empatía forma parte de esa comunicación efectiva, asi que si queres evitarle estas situaciones a tus compas, mejor, no envies solamente “hola” por Slack (o Teams, o Discord, o cual sea el sistema de mensajería que uses en tu trabajo).

Saludá, claro, pero también andá al grano. Comunicá en tu primer mensaje qué es lo que necesitas de tu compa, y si podés ser lo más descriptivo/a posible, mejor aún. Tus compas te lo van a agradecer y si necesitás pedirle a otro compa que aplique estos consejos, vos ya vas a estar predicando con el ejemplo primero.

Te dejo más info en esta web que me parece super interesante y expande un poquito más lo que te digo en esta seccion: https://nomedigashola.com/

💭 Debug Mental

El Valor de hacer Comunidad

Hace poco comencé a leer un libro titulado “El Algebra de la Riqueza” del autor Scott Galloway. Primera vez que leo una de sus obras. Si bien es un libro orientado a economía y finanzas, existe un componente en dicho libro orientado a las relaciones que construimos con otras personas a lo largo de nuestra vida, ya sea familia, amigos, pareja, contactos profesionales, etc. Según el autor, las relaciones humanas son un eje esencial de lo que él denomina “seguridad económica”.

De muchas de las expresiones del autor que rescato, hay una en particular que resonó bastante con mi visión actual de la vida y las relaciones interpersonales, y es:

“El verdadero potencial se desbloquea en colaboración (y a veces competencia) con otros”.

Hubo una época de mi vida donde llegué a considerar que involucrarse demasiado con las personas podía llegar a ser un lastre. A fin de cuentas, las personas son molestas, desagradecidas, conflictivas, egoistas, etc. Y si bien es cierto, con el tiempo me di cuenta de que me estaba concentrando en el lado negativo del asunto.

Claro que existen personas con esas cualidades, pero también hay personas colaborativas, agradecidas, resolutivas, abnegadas y altruistas, que buscan cambiar el mundo a su modo y dejarlo, al menos, un poquitito mejor de cómo lo encontraron. Esas personas que están alineadas con tu visión y tu dirección, que definitivamente pueden potenciar tus buenas cualidades a la vez que te permiten aprender cosas nuevas, ya sean habilidades, puntos de vista, y más.

Si me hubiera quedado con ese punto de vista negativo del que te comenté, no podría haber conocido a esa clase positiva de personas. Pero para llegar a ellas, primero tuve que encontrarme con las indeseadas. Dicho de otro modo, tuve que conocer gente e ir filtrando, pero sin perder la fe.

No podemos perder la fe en las personas. Hay gente buena por la que vale esforzarse y que de hecho, retribuirá el esfuerzo que vos hagas por ellas. Además, somos animales sociales. Quien decida autoaislarse solamente retrasará y perjudicará su propio progreso.

Por eso mi palabra de aliento y recomendacion para vos es: hacé comunidad. Buscá tu grupo. Puede que lleve tiempo y obviamente va a requerir esfuerzo de tu parte. Pero es posible encontrarlo. O en todo caso, podés construirlo. No hay soluciones mágicas en este aspecto y hay muchos factores incluidos, pero si decidís quedarte quieto/a, o “en el molde” como decimos en Argentina, muy dificilmente encuentres a tu grupo y a esas personas que pueden enriquecer tu experiencia de vida.

Si estás leyendo esta newsletter muy seguramente es porque te interesa construir un camino profesional en el rubro IT, y es por eso que quiero extenderte la invitacion a ShareIT, la comunidad de WhatsApp/Discord que he fundado con el objetivo de lograr esto que te cuento: encontrar un grupo, crear relaciones, alimentarlas y crecer junto a otras personas con una vision similar. Si te interesa unirte, te dejo el enlace.

Pero incluso si decidís no unirte, el mensaje que quiero dejarte es este: nadie nació para quedarse solo. Existen amigos y amigas en el mundo, esas personas que están buscando conocerte tanto como vos buscas conocerlas a ellas. Encontrarlas es posible. Yo lo he logrado afortunadamente, pero requirió mucha proactividad de mi parte. La gente que sirve “no crece en los arboles” y se aparece en tu puerta ofreciéndote oportunidades y su amistad. Buscalas, pero con la fe de que es posible encontrarlas.

📚 Datazo

Data Engineering 1 - Intro

Cerramos esta primera edición con un post que escribí en mi blog un tiempo atrás donde te cuento:

• qué hace un/a Data Engineer

• los conocimientos técnicos como habilidades blandas que se espera que tengas para ser bueno/a de verdad

• y recursos gratuitos y pagos de los que podés valerte para comenzar tu camino en este rol tan apasionante

Consideralo una extensión más precisa y detallada de lo que te comenté más arriba. Espero te sea de utilidad y apreciaré muchísimo que me cuentes si te pareció interesante, si te sirvió o si agregarías algo. El feedback positivo y constructivo me sirve un monton, de verdad 🙏🏻

El enlace al post acá.

Subscribe now

Punto de partida

¡Hola! Bienvenido/a a “El Ingeniero Consciente”, el espacio que he elegido crear para compartir lo que sé y lo que aprendo tanto en tecnología como en este camino llamado vida.

¿Bastante original la intro, no? Siendo completamente honesto, no te das una idea de lo que procrastiné crear una newsletter.

A veces las ideas se me amontonan y me sobreviene una súbita inspiración que no puedo contener y siento el ímpetu de tener que crear y compartir.

Y a veces simplemente la inspiración decide abandonarme, como ahora, que no sé exactamente qué escribir para que esta introducción no sea aburrida o pesada y que te enganche para leer hasta el final.

Pero heme aquí, intentándolo.

Porque a fin de cuentas de eso se trata todo esto. De probar, de intentar.

Lo cierto (y no lo digo yo) es que nos vamos a arrepentir más por los riesgos que no nos hemos animado a correr que por las consecuencias de eso que sí decidimos hacer.

No quiero sumar esta newsletter a esa pila de cosas que aún no me animo a hacer, así que me largo con todo:

• con ideas y con la falta de ellas

• con propósito y con algo de confusión

• con algo de miedo y con muchas ganas

…sin tener a lo mejor la visión más clara de hacia donde llevar esto, pero con la firme noción de que sé qué es lo que quiero lograr. ¿Y qué sería exactamente eso?

🎯 El Objetivo

Esta newsletter nace como producto de haber adquirido y ejercitado un hábito: compartir. Soy muy partidario de la idea de que lo que uno aprende puede servir a dos propósitos:

• Mejorarse uno mismo

• Mejorar a los demás

La grandeza se logra poniéndose al servicios de los demás, ya sea tu familia, amigos, compañeros de estudio/trabajo, tu comunidad, tu país, y un largo etc.

No nacimos para quedarnos solos y el verdadero crecimiento, la manera en que realmente podés explotar todo tu potencial es en colaboración (y a veces competencia) con otros.

Por eso hace ya un tiempo comparto contenido sobre tecnología en LinkedIn, X/Twitter e incluso mi propio blog.

En noviembre del 2024 decidí dar rienda suelta a una idea que llevaba cultivando unos meses y fundé ShareIT, una comunidad de WhatsApp/Discord conformada por miembros de distintas edades, países, orígenes y trasfondos, pero unidos por un mismo deseo: crecer en la industria tech.

Sé que no dije nada aún sobre mi trasfondo profesional, pero supongo que la palabra Ingeniero da algunas pistas jeje. Luego te cuento por qué Consciente va en el título también).

¿Por qué esto? ¿Por qué ahora?

Crear el Ingeniero Consciente no es solamente compartir contenido, va más allá.

Ojo que tampoco busco que todos piensen como yo, todo lo contrario, me nutre encontrar puntos de vista diferentes y opuestos (incluso si al principio no me cierra del todo).

Ahora, si de repente sentís que no sos de esa clase de personas, dejame decirte algo: también te estoy buscando a vos (esto sonaba mejor en mi mente, ahora que lo leo bien suena medio creepy pero dame un segundo y te explico xD).

Porque esto no se trata de señalar con el dedo a nadie y decir cosas como “Hey, deberías ser fuerte”. No hay nada de malo en ser débil, el problema está en elegir quedarse así.

Yo tuve mis períodos bajos en la vida, donde fui perezoso, egoísta, deshonesto, hedonista y también fui cobarde, llorón y me quejaba.

Pero no me machaco, hice las pases con esa versión anterior mía y hoy, desde un lugar mejor (donde he superado algunas de esas malas cualidades y donde también batallo contra otras) intento compartir mi progreso, y mis errores, para que a lo mejor sirvan de faro que ilumine el camino de alguien más.

No son pocas las personas que me ayudaron a ser quien soy hoy (nadie se construye realmente solo o quien decida hacerlo solamente está retrasando su progreso) y aunque puede que hoy no nos conozcamos en persona, que nunca nos lleguemos a conocer en persona, o que nunca lleguemos a cruzar palabra, me gustaría ser una de esas personas (si me lo permitís, claro) que te ayude a crecer en varios sentidos.

No soy un maestro de la vida, solamente soy otro humano más intentando vivir su vida de la mejor forma que puede y que sabe, con las herramientas que tiene a su alcance. Y a veces, muchas veces, eso es más que suficiente.

Bueno, basta de tanta cháchara. Te cuento en un toque de qué va El Ingeniero Consciente y te comparto los detalles jugosos de esta newsletter.

📌¿Qué esperar de todo esto?

El Ingeniero Consciente es una newsletter sobre:

• Ingeniería de Datos (el rol que actualmente estoy ejerciendo)

• Programación (sobre todo en Python)

• Cloud (muchísimo AWS)

• Consejos profesionales (propios y los que vaya encontrando)

• Espiritualidad, atención plena y consciencia, porque la tecnología no lo es todo

Ahora, con respecto a la frecuencia del contenido: me pasa con algunas newsletters que tienen una frecuencia tan alta y un contenido tan abultado, que en un punto me abruman.

No quiero que mis lectores sufran eso. Por eso mi idea es ir al grano con las cosas y darte algo de valor (aunque sí, va a haber posts en formato largo, mas o menos como este que estás leyendo, ya que algunos temas requieren profundidad).

Pero mi idea es darte a vos el control. Acá vos elegís qué consumir y cuándo :)

Para más info acerca de la frecuencia y organización del contenido, te recomiendo leer el Acerca De de la newsletter.

Bienvenido, bienvenida

Si, medio raro terminar un post con la bienvenida, pero a veces me gusta creer que el final de algo también es el comienzo de algo nuevo. Y en este caso no podría ser más cierto.

Espero que El Ingeniero Consciente sea eso que te acompañe en tu crecimiento profesional, en esos momentos donde necesitás un consejo, inspiración o tan solo una palmadita en la espalda, un “abrazo a la distancia” para cargar pilas y seguir.

Es un enorme placer tenerte a bordo y me pone contento saber que elegiste formar parte de esto.

¡Nos leemos pronto! 🚀

— Elias (Kani)