REGAM @STEMREGAM

Que tu código corra no significa que tu proyecto sea fácil de usar. A veces haces un script que funciona perfecto… Pero solo tú sabes: Qué archivo ejecutar. Qué datos necesita. Qué librerías instalar. Qué resultado esperar. Y qué pasos seguir antes de correrlo. Eso también importa. Porque programar no es solo escribir código. También es dejar instrucciones para que el proyecto pueda vivir fuera de tu cabeza. Ejemplo simple: Si tienes un script como analisis.py, no basta con que funcione en tu computadora. Conviene dejar claro: Qué hace. Qué archivo de datos usa. Cómo se ejecuta. Qué salida genera. Y qué necesita instalarse. Algo tan simple como un README.md puede cambiar mucho: “Este proyecto analiza ventas.csv” “Para correrlo: python analisis.py “Genera una gráfica en resultados/” “Necesita pandas y matplotlib” Eso no es decoración. Es hacer que el proyecto sea entendible. Para otra persona. Para tu equipo. Para tu profesor. O para tu yo de dentro de tres meses. La idea no es llenar el proyecto de archivos raros. La idea es que el código no dependa de que tú estés ahí para explicarlo. Código que solo tú entiendes todavía vive demasiado dentro de tu cabeza.

Tu proyecto no debería depender de que tú te acuerdes de revisar todo. Cuando programas, es fácil olvidar cosas: Correr pruebas. Revisar estilo. Eliminar imports que ya no usas. O comprobar si rompiste algo viejo. Ahí entran dos ideas importantes: Calidad del código e integración continua. La calidad del código no es solo que el código se vea bonito. Es poner reglas y revisiones para que el proyecto sea más fácil de mantener. Por ejemplo, en Python podrías correr: ruff check . pytest Uno revisa posibles problemas en el código. El otro corre pruebas. Y si eso pasa automáticamente cada vez que subes cambios al repositorio, ya estás entrando en la idea de la integración continua: Que el proyecto se revise solo antes de confiar en el cambio. No elimina los bugs. Pero sí te da una red de seguridad. Menos revisar a mano. Más checks automáticos. Más confianza antes de confiar en un cambio.

No siempre necesitas abrir Excel, pandas o un notebook. A veces solo quieres hacerle preguntas simples a un archivo. Por ejemplo, tienes un CSV: ventas.csv Antes de hacer un análisis más grande, puedes empezar con cosas pequeñas. Ver las primeras líneas: head ventas.csv Contar cuántas líneas tiene: wc -l ventas.csv Ver una columna específica: cut -d, -f2 ventas.csv Eso también es una forma básica de data wrangling desde la terminal. No estás construyendo un modelo. No estás haciendo una gráfica. Estás entendiendo qué tienes enfrente. Y eso importa más de lo que parece. Porque muchas veces el problema no es calcular algo difícil. El problema es no saber: Qué columnas hay. Cuántos registros tienes. Si hay valores raros. O si el archivo tiene la forma que esperabas. La terminal sirve mucho para eso: Mirar rápido. Contar rápido. Extraer rápido. Decidir el siguiente paso. No reemplaza pandas, Excel o SQL. Pero sí te evita abrir una herramienta pesada solo para responder una pregunta pequeña.

Analizar datos no empieza con modelos. Empieza cuando logras que una tabla tenga sentido. Porque los datos casi nunca llegan limpios. Llegan con: Fechas mezcladas. Columnas mal nombradas. Valores vacíos. Números guardados como texto. Duplicados. O categorías escritas de varias formas distintas. Aquí entra el data wrangling: Tomar datos crudos y convertirlos en datos que sí puedes usar. Ejemplo simple: Si una columna de montos viene así: $120 $80 N/A $300 antes de sumar, tienes que: Quitar el símbolo $. Decidir qué hacer con N/A. Convertir texto a número. Y verificar que todo tenga sentido. Eso no es un detalle menor. Es parte central del análisis. Porque si los datos están mal preparados, la gráfica puede verse bonita, el modelo puede correr, y el promedio puede salir, pero la conclusión puede estar construida sobre basura. La idea no es limpiar por limpiar. La idea es hacer que los datos respondan mejor tus preguntas. Data wrangling es ese puente incómodo pero necesario: De datos como llegaron a datos que ya puedes analizar.

Buscar archivos bien no es tener mejor memoria. Es aprender a describir lo que estás buscando. Porque cuando un proyecto crece, pasa esto: “Sé que el archivo existe” “Creo que era de Python” “Según yo tenía datos en el nombre” “Pero no recuerdo dónde lo guardé” Ahí la terminal ayuda bastante. Ejemplo: find . -name "*.py" Eso busca, desde la carpeta actual, archivos cuyo nombre termine en .py. Si recuerdas una parte del nombre: find . -name "*datos*" Y si solo quieres archivos, no carpetas: find . -type f -name "*datos*" La idea no es buscar abriendo carpeta por carpeta. La idea es aprender a hacer preguntas mejores: ¿Desde dónde busco? ¿Qué parte del nombre recuerdo? ¿Busco archivos o carpetas? ¿Qué extensión tenía? Abrir 20 carpetas a mano funciona… hasta que tu proyecto crece. No busques con memoria. Busca con patrones.

Trabajar en una máquina remota no debería depender de que tu conexión nunca falle. Cuando empiezas, es normal hacer esto: Entras por SSH. Corres un proceso largo. Dejas la terminal abierta. Y esperas que no se caiga internet. Pero hay una herramienta que cambia mucho el flujo: tmux. tmux te permite crear una sesión de terminal que puede seguir viva aunque cierres la ventana o se caiga la conexión. Ejemplo: ssh usuario@servidor tmux new -s simulacion python simulacion.py Luego puedes separarte de la sesión: Ctrl + b, luego d Y más tarde volver: tmux attach -t simulacion La idea es simple: SSH te deja entrar. tmux te deja quedarte. Eso importa si corres simulaciones, entrenas modelos, trabajas en servidores o dejas procesos largos. Menos miedo a perder el trabajo por una desconexión. Más sesiones persistentes. Más calma.

Una máquina remota no es “la nube” en abstracto. Es otra computadora. Solo que no la tienes enfrente. Puede estar en un laboratorio, en un servidor, en una VM o en la nube. Y con SSH puedes abrir una terminal ahí desde tu propia compu. Algo como: ssh usuario@servidor Después de entrar, los comandos ya no se ejecutan en tu computadora local. Se ejecutan en la máquina remota. Si escribes: ls ves los archivos de esa máquina. Si escribes: python simulacion.py la simulación corre allá. Si abres: nano notas.txt estás editando un archivo que vive allá. Esa es la idea bonita: Tu teclado está aquí, pero el trabajo ocurre en otra computadora. Esto sirve para usar servidores, correr procesos largos, trabajar con Linux, acceder a archivos remotos o usar una máquina más potente que la tuya. No es magia. Es aprender a trabajar con computadoras que no están físicamente frente a ti.

Editar archivos desde la terminal suena más difícil de lo que es. Pero la idea es simple: A veces no quieres abrir carpetas, buscar el archivo, abrir el editor y luego volver a la terminal. Solo quieres cambiar una línea. Por ejemplo: Estás en una carpeta y quieres editar tus notas: nano apuntes.txt O quieres abrir un script: nano script.sh Eso abre el archivo directamente desde la terminal. Editas. Guardas. Sales. Y sigues trabajando donde ya estabas. La idea no es “verte más técnico”. La idea es reducir pasos. Menos abrir ventanas. Menos buscar archivos a mano. Más seguir trabajando sin salir del flujo. Después puedes usar editores más potentes como Vim, Neovim o VS Code. Pero la idea empieza aquí: Abrir y editar archivos sin salir de la terminal.

Editar texto bien no es escribir más rápido. Es repetir menos cambios manuales. Cuando programas, casi todo termina siendo texto: Código. Archivos de configuración. Scripts. Datos. Y si editas todo línea por línea, tarde o temprano tu editor se vuelve una máquina de perder tiempo. Ejemplo simple: Tienes esto: archivo1.txt archivo2.txt archivo3.txt y quieres moverlos a otra carpeta: mv archivo1.txt backup/ mv archivo2.txt backup/ mv archivo3.txt backup/ Puedes escribir cada línea a mano. O puedes usar multi-cursor, buscar/reemplazar, macros o comandos del editor. La idea no es aprender atajos para verte más profesional. La idea es entender esto: Tu editor no solo sirve para escribir. Sirve para hacer varios cambios sin repetirlos a mano. Ahí empiezan a tener sentido cosas como: Buscar y reemplazar. Selección por columnas. Multi-cursor. Macros. Atajos. Y editores modales como Vim. Menos edición repetitiva. Menos errores tontos. Más pensar en el cambio que quieres hacer.

Git no existe para que nunca rompas tu proyecto. Existe para que romperlo no sea una tragedia. Si usas bien el control de versiones, puedes: Probar ideas en ramas. Comparar cambios. Volver a una versión anterior. Trabajar con otras personas. Y encontrar qué cambio rompió algo. Ejemplo simple: Ayer tu código funcionaba. Hoy ya no. Sin historial, empiezas a adivinar: “¿Qué borré?” “¿Qué archivo toqué?” “¿Por qué comenté medio código?” Con Git tienes una línea de tiempo. Puedes revisar commits. Puedes comparar cambios. Puedes volver al punto donde todo funcionaba. Y en proyectos más grandes, incluso puedes usar git bisect para buscar qué commit introdujo el bug. La idea no es trabajar perfecto. La idea es trabajar con memoria. Menos miedo a experimentar. Más historial, ramas, commits y contexto.

Si tu carpeta se ve así: proyecto/ proyecto_copia/ proyecto_final/ proyecto_final_2/ proyecto_final_ahora_si/ ya estás haciendo control de versiones solo que a mano. Y con ansiedad. El control de versiones sirve para algo muy simple: Guardar la historia de un proyecto. No solo “la carpeta como está ahorita”, sino cómo fue cambiando. Qué agregaste. Qué rompiste. Qué corregiste. Y en qué punto todo todavía funcionaba. Con Git, por ejemplo, puedes trabajar así: 1. Modificas un archivo 2. Eliges qué cambios guardar 3. Haces un commit con un mensaje Algo como: git add simulacion.py git commit -m "modelo inicial funcionando" Ese commit es como decir: “Guarda este punto de la historia”. Después puedes seguir probando cosas. Si algo sale mal, ya no dependes de tener 5 copias del mismo proyecto con nombres raros. Tienes una línea de tiempo. Control de versiones no es solo para equipos grandes. También sirve para estudiar, programar, escribir notebooks, hacer simulaciones o construir proyectos sin miedo a romper todo.

Copiar comandos desde una nota se siente normal hasta que te das cuenta de que estás usando tu memoria como sistema de automatización. Si siempre escribes algo como: cd ~/apuntes && ls puedes convertirlo en un atajo: alias apuntes='cd ~/apuntes && ls' Y ahora solo escribes: apuntes Esa es una idea muy bonita del shell: Cuando una acción se repite, puedes darle un nombre. No tienes que recordar toda la receta cada vez. La guardas una vez. La usas muchas veces. Primero atajos simples. Luego scripts. Después tareas más grandes con herramientas como make. Pero la idea empieza aquí: Dejar de copiar comandos Y empezar a construir tus propias herramientas pequeñas.

El shell no es la terminal. La terminal es donde escribes. El shell es quien interpreta lo que escribes. Aprender shell no es memorizar comandos como si fueran hechizos. Es aprender a darle instrucciones al sistema. Por ejemplo: mkdir apuntes && cd apuntes && touch shell.txt Eso es una pequeña secuencia: crear una carpeta → entrar a esa carpeta → crear un archivo La parte importante está en el &&: “Haz lo siguiente solo si lo anterior funcionó”. Ahí cambia la idea: Ya no estás dando clicks sueltos. Empiezas a construir pequeñas recetas con texto.