análisis_final_v2_bueno_ESTE_SI.ipynb: el caos que todos creamos

Todos tenemos uno. Lo sabemos. Está en alguna carpeta, en algún escritorio, en alguna sesión de Google Colab medio olvidada. Se llama analisis_final_v2_bueno_ESTE_SI.ipynb y es el monumento más honesto que ha producido la humanidad: un fichero que grita el caos mental de quien lo creó.

Si te has sentido identificado al leer ese nombre, bienvenido. Este artículo es una sesión de terapia colectiva.

La arqueología del nombre

Pongámonos a excavar. ¿Cómo llega un fichero a llamarse así? Es una historia forense con varias capas.

Primero, lo creas con un nombre razonable: analisis.ipynb. Razonable. Limpio. Casi profesional. Pero luego la vida pasa: un compañero te pide “un cambio rápido”, llega un deadline, tu jefe quiere “solo una versión más”. Y haces lo que haría cualquier ser humano en tu lugar: creas una copia.

analisis_v2.ipynb. Hasta aquí, todo normal. Pero v2 también necesita su propia copia, y luego la “definitiva”, y luego la “que sí va”, y luego la “para el cliente”, y al final, después de un día largo, te encuentras con esta colección en tu escritorio:

analisis.ipynb
analisis_v2.ipynb
analisis_v2_bueno.ipynb
analisis_final.ipynb
analisis_final_v2_bueno.ipynb
analisis_final_v2_bueno_ESTE_SI.ipynb
analisis_final_v2_bueno_ESTE_SI_DE_VERDAD.ipynb
analisis_final_v2_bueno_ESTE_SI_DE_VERDAD_ahora_si.ipynb

Y aquí está la trampa: ninguna de esas versiones es la buena. Ni siquiera la que tiene más palabras. Todas son fotos de momentos distintos de un mismo proceso, sin contexto, sin orden y sin red de seguridad.

Por qué lo hacemos (spoiler: no es vagancia)

Aquí viene la parte incómoda: nadie hace esto por pereza. Lo hacemos porque nadie nos enseñó a no hacerlo. En la carrera, en el máster, en el bootcamp, en el ciclo formativo, nos enseñan a programar, a manejar datos, a hacer modelos. Lo que casi nunca nos enseñan es a organizar el trabajo como si fuera un proyecto de ingeniería.

Y eso, en parte, tiene sentido: cuando estás aprendiendo, lo urgente es que el código corra. No importa si la carpeta es un vertedero o si el nombre es horrible: lo que importa es que el print("hola mundo") funcione y el gráfico salga.

El problema es que esa forma de trabajar se nos pega. Y el día que te toca hacer un proyecto serio — para una empresa, para un cliente, para un TFG, para un examen con nota — el caos te explota en la cara. Porque el caos, al final, siempre pasa factura. Solo que a veces tarda semanas en llegar.

El día que el caos pasa factura

Te cuento tres escenas que, sospecho, también te han pasado a ti.

Escena 1 — El correo de las 23:47. Tu jefe (o tu profe) te pide “el análisis de ventas del mes pasado”. Tú sabes que lo tienes. Lo hiciste. Lo recuerdas perfectamente. Pero no recuerdas en cuál de los ocho analisis_* está la versión buena. Y como no pusiste comentarios, ni separaste los datos del código, ni versionaste nada, pasas dos horas reabriendo ficheros hasta encontrar el que parece “el bueno”. Si es que existe.

Escena 2 — El compañero nuevo. Llega alguien al equipo. Le pasas tu carpeta de proyecto. Y entonces te mira con esa mezcla de compasión y pánico que solo provoca el código de otro. Porque no hay README, no hay estructura, no hay nada que le diga “esto es lo importante”. Tiene que abrir diez notebooks a ciegas para entender qué hace cada uno.

Escena 3 — El “lo arreglo en un momento”. Estás a punto de enviar tu trabajo. Abres el notebook. Haces “un cambio pequeño”. Lo guardas. Lo rompes. Y ahora, ¿cuál era la versión que funcionaba? No lo sabes. No guardaste copia. No hay Git. Y tu yo del pasado, ese que tenía la versión buena, no puede ayudarte porque ya no existe.

Las tres escenas tienen la misma raíz: trabajamos como si fuéramos los únicos que vamos a tocar ese fichero, y como si nunca más fuéramos a necesitarlo. Las dos cosas son falsas. La primera, porque tu yo del futuro te odia cada vez que hereda un proyecto así. La segunda, porque ese código va a volver, te lo garantizo, justo cuando menos te lo esperes.

La cura no es disciplina: es método

La buena noticia es que la solución no requiere heroicidad. No necesitas convertirte en una persona ordenada ni cultivar hábitos de monje. Solo necesitas una estructura mínima que trabaje a tu favor, incluso en tus peores días.

Tres ideas, ninguna nueva, todas probadas:

• Una estructura de carpetas que se explique sola. Algo tan simple como data/ para los datasets, notebooks/ para los cuadernos y scripts/ para el código reutilizable. Si además metes output/ para los resultados, ya tienes el 80% del trabajo hecho. No hace falta más, ni tampoco un sistema complejo de doce carpetas: simple, predecible, repetible.

• Un naming convention que no dé vergüenza. Nombres descriptivos, fechas en formato ISO (2026-06-05), versiones con números, sin adjetivos emocionales. analisis_ventas_2026q2_v03.ipynb se puede ordenar, buscar y entender dentro de un año. analisis_final_v2_bueno_ESTE_SI_DE_VERDAD_ahora_si_v2.ipynb no hay quien lo ordene, ni lo busque, ni lo recuerde.

• Git, aunque sea un poco. No necesitas ser un gurú de las ramas ni entender rebase interactivo. Con cuatro comandos (add, commit, push, pull) ya tienes un historial de qué cambió, cuándo y por qué. Es la única máquina del tiempo fiable que existe para el código. Y, además, te obliga a pensar antes de guardar.

Y aquí viene el secreto a voces: estas tres cosas se enseñan el primer día de cualquier trabajo serio de datos. Quien las aprende pronto trabaja el doble de rápido que quien las aprende tarde. Y quien nunca las aprende acaba con un monumento al caos en su escritorio y con la misma escena de pánico cada trimestre.

Una pregunta para llevar

Y antes de cerrar, te dejo con la pregunta que de verdad importa:

¿Cuál es el nombre de fichero más vergonzoso que has creado tú, y qué aprendiste (o no) después?

Cuéntamelo. Prometo no juzgar: yo también guardo los míos como prueba de que todos empezamos igual.

Y si este tema te resuena y quieres empezar a montar tus proyectos con una estructura limpia desde el minuto uno, en la UT1 — El Detective de Datos del libro empezamos exactamente por aquí: el flujo de trabajo profesional, la organización de carpetas y las herramientas con las que un proyecto se entiende de un vistazo. A veces, lo más importante de un proyecto de datos no es el modelo. Es todo lo que hay alrededor del modelo.