Cuando entendí cómo GTFS Schedule y GTFS Realtime podían funcionar juntos, vi una matriz de preguntas útiles sobre el transporte público de Montreal. GTFS Schedule aportaba la parte planificada: rutas, viajes, paradas y horarios. GTFS Realtime podía añadir actualizaciones de viajes en tiempo real, posiciones de vehículos, el retraso como valor numérico e información opcional sobre ocupación. Una fecha, un rango de fechas o un período más amplio añadía otra dimensión. transit.yesid.dev surgió en parte de ver cómo esas dimensiones podían cruzarse, en lugar de tratar cada flujo de datos o métrica como un dato aislado.
Pon una ruta en un eje y el tiempo en otro; luego pregunta dónde divergen el servicio planificado y las observaciones en tiempo real. ¿Qué rutas presentan retrasos durante el período elegido? ¿Cambia el patrón cuando cambia el rango de fechas? ¿Dónde muestra la información disponible sobre ocupación un patrón distinto a cierta hora? ¿Qué viajes programados de autobús deberían estar circulando ahora, pero no tienen ningún vehículo en tiempo real correspondiente? Cada pregunta surge de una intersección distinta entre el servicio planificado, la información en tiempo real, una interpretación del producto y un control temporal. La matriz convierte una lista de campos en algo que puedo examinar.
Estas preguntas exigen mantener separadas las capas de la fuente y del producto. El retraso es numérico; «adelantado», «a tiempo», «retrasado» y «grave» son interpretaciones creadas por el producto. La ocupación es opcional y experimental, así que puede estar ausente o incompleta, y no se garantiza que forme una escala lineal. El estado «sin reporte» es distinto: es una señal derivada por el producto para un viaje programado de autobús que debería estar circulando ahora, pero no tiene un vehículo en tiempo real correspondiente; no es un valor temporal oficial de GTFS.
Veo una matriz de verdad. Veo filas y columnas. Es algo visual. La granularidad puede ser una parte de la imagen: un elemento, un grupo o un nivel más amplio. Los filtros y las opciones que dejan pueden ser otra. Las decisiones, los campos de base de datos y las combinaciones ocupan el mismo tipo de espacio visual. El contenido cambia según el tema, pero sigo viendo las filas y las columnas.
Para una decisión, puedo imaginar las opciones como filas y las restricciones como columnas. Un filtro reduce las opciones; otro añade una condición. Puedo ver qué combinaciones quedan. Las entradas exactas dependen de la decisión, pero aun así veo las relaciones como una cuadrícula.
SQL encaja con esa imagen. En una tabla, cada fila es un registro y cada columna es un campo. Los filtros seleccionan qué registros quedan a la vista, y una consulta puede combinar varias condiciones. Las relaciones me permiten pasar de un registro a los registros relacionados cuando una sola tabla no explica lo suficiente. La granularidad también cambia la imagen: un solo registro, un resultado agrupado y un conjunto más amplio responden preguntas distintas. SQL da nombres y operaciones precisos a las filas, las columnas, los filtros, los campos de base de datos y las combinaciones que veo.
La contabilidad y SQL se conectan en mi cabeza. Antes de trabajar como desarrollador SQL, estudié contabilidad. Cuando un monto era incierto, una fecha y un monto eran un punto de partida. Eran pistas, no claves únicas garantizadas, porque otro registro podía compartir ambos valores. El contexto que los rodeaba podía estar en el flujo de caja, un presupuesto, un estado financiero o una transacción. A veces la fecha podía apuntar a la cuenta correcta; a veces el monto solo reducía la búsqueda. Podía recorrer esos registros y preguntar dónde aparecía el monto, con qué se relacionaba y si otro registro lo explicaba mejor. Los JOINs y la normalización me dieron después herramientas y un lenguaje más precisos para seguir las relaciones entre los datos. Para mí, la conexión personal está en el acto de seguir el rastro: el primer valor apunta a algún lugar, los registros relacionados reducen la incertidumbre y la respuesta completa depende del contexto.
Recuerdo que, cuando trabajaba lavando platos, una mujer me dijo: «Tienes dos manos. Usa las dos».
Me quedé con esa instrucción. Todavía noto cuando una mano está desocupada y ya podría estar ayudando. Una mano puede mantener una acción en marcha mientras la otra inicia la siguiente. Las dos manos pueden moverse en direcciones distintas y ocuparse de tareas diferentes. Ese hábito no se quedó en el trabajo lavando platos; lo llevé a otros trabajos físicos. Cuando trabajo o hago algo físico, busco esa oportunidad en lugar de esperar a que termine una acción. Ahorra tiempo, y me doy cuenta de que uso ese hábito todo el tiempo. El cambio es físico y específico: notar la mano desocupada, darle una parte del trabajo y dejar que las dos acciones avancen juntas.
Los datos funcionan porque los campos tienen definiciones. Un retraso puede almacenarse como número, un rango de fechas tiene límites y un producto puede agrupar observaciones en categorías declaradas. Las personas no son parámetros rígidos de la misma manera. Puedes recopilar las métricas más importantes y aun así nunca medir por completo a una persona. Una puntuación, una categoría o una observación puede describir algo real, pero respalda una afirmación limitada.
El hábito de las dos manos deja clara la diferencia. Puedo describir qué cambió: ambas manos trabajan, las acciones avanzan en direcciones distintas y se ahorra tiempo. Esas mediciones pueden describir el hábito, pero no pueden contener a la persona que me lo enseñó.
Así es también como trabajo con IA: puede convertir una conversación en una estructura, pero leo cada bloque de principio a fin y tomo la decisión final.
Este es el capítulo 3 de una serie de seis capítulos. Capítulos 1–3: quién soy. Capítulos 4–6: lo que construyo. Anterior: Cómo aprendo: orbitar un sistema hasta que encaja · Siguiente: Acelerado por IA, en manos humanas: mi flujo de trabajo real.
¿Necesitas un sistema que se mantenga editable?