Rob Pike Tenía Razón Desde el Principio
Las 5 reglas de Rob Pike están en tendencia en Lobste.rs. Lo que el resurgimiento de los fundamentos de programación significa cuando generar código es esencialmente gratis.
Algo está ocurriendo en los rincones más selectos de internet esta semana que merece más que un scroll de pasada. Las 5 Reglas de Programación de Rob Pike están circulando en Lobste.rs — junto a "To be a better programmer, write little proofs in your head", "Is simple actually good?", y un post antiguo sobre lo poco que pesaba Turbo Pascal. Tres o cuatro posts distintos, apuntando en la misma dirección. Eso no es coincidencia — es una comunidad tratando de resolver algo.
El momento es incómodo de una manera muy concreta.
Las Reglas Que Se Negaron a Caducar
Pike escribió sus cinco reglas en Bell Labs, en una era de limitaciones de 16 bits y memoria contada. Resumidas:
- No puedes predecir dónde pasa el tiempo un programa. Mídelo.
- Mide antes de optimizar. No adivines los cuellos de botella.
- Los algoritmos sofisticados son lentos cuando n es pequeño. n suele ser pequeño.
- Los algoritmos sofisticados tienen más bugs que los simples.
- Los datos dominan. Elige las estructuras de datos correctas y los algoritmos se vuelven obvios.
Lo llamativo no es que estas reglas sean profundas — cada una, por separado, suena casi ridículamente obvia. Lo llamativo es que siguen redescubriéndose. Aparecieron en los años 80, se citaron en todos los cursos de programación de sistemas durante los 2000, y aquí están de nuevo en 2026, recibiendo upvotes de ingenieros que tienen acceso a IAs capaces de armar un servicio entero en el tiempo que tarda en hacerse un café.
Las reglas sobreviven porque los fallos que abordan nunca se han resuelto. Simplemente seguimos encontrándolos a un nivel de abstracción más alto.
Qué Significa Realmente "Simple"
El post "Is simple actually good?" hace un argumento más afilado de lo que su título sugiere. No es una defensa del código ingenuo ni una queja sobre la abstracción. Es un análisis de una confusión que se ha vuelto profesionalmente peligrosa: simple y fácil no son lo mismo.
Fácil significa poca fricción para producir. Simple significa poco esfuerzo cognitivo para entender, verificar y modificar.
Gran parte del tooling moderno optimiza fuerte para lo fácil. Los generadores de scaffolding, los autocomplete con IA, los backends sin código — todos reducen la fricción para crear algo. Hacen muy poco para garantizar que lo que has creado sea comprensible en los límites. Esa brecha — entre fácil de producir y simple de razonar — es donde vive la mayoría de los incidentes en producción.
Por eso la trivia de Turbo Pascal es algo más que nostalgia. El IDE, compilador y runtime completos de Turbo Pascal 3.0 cabían en 39KB. No porque los ingenieros de 1983 fueran más inteligentes — sino porque las limitaciones los obligaban a cargar el modelo mental completo. No podías esconderte en una capa de abstracción que no habías construido tú mismo. Las condiciones de borde siempre eran visibles.
Esa restricción ha desaparecido prácticamente. En 2026 puedes poner un sistema en producción sin entender qué hace cuando n=0.
El Problema de las Pruebas
El post "write little proofs in your head" es el más directo del grupo. Su argumento central: la habilidad de programación más importante no es la fluidez con la sintaxis ni el conocimiento de frameworks — es el hábito de la verificación informal. En cada paso: ¿esto realmente funciona? ¿Puedo demostrar por qué?
No son pruebas formales al estilo Coq. Es el bucle informal: ¿qué hace esta función con una lista vacía? ¿Con n=1? ¿Con el entero máximo? ¿Qué pasa cuando esto devuelve null?
Los ingenieros senior hacen esto de forma automática, invisible. Está tan interiorizado que muchas veces no saben describirlo. Pero es exactamente la disciplina que se saltea cuando la presión por velocidad es alta y la sugerencia de la IA ya va tres líneas por delante. El autocomplete no espera a que termines de pensar.
Esto crea un fallo específico: bugs que viven en casos borde que ningún test cubrió, en suposiciones que nadie explicitó, en caminos que el profiler nunca vio porque el tráfico de producción aún no los había tocado. La Regla 1 de Pike — no puedes saber dónde pasará el tiempo un programa, así que mide — es un caso concreto del mismo principio: tus intuiciones sobre el comportamiento en runtime están equivocadas más a menudo de lo que crees.
Qué Significa Esto para los Equipos Ahora Mismo
Nada de esto es un argumento en contra del tooling moderno o del desarrollo asistido por IA. Pero hay una disciplina de ingeniería específica que el ecosistema actual no refuerza: detenerse a verificar tu propia comprensión antes de avanzar.
Algunas prácticas que traducen las reglas de Pike a los flujos de trabajo actuales:
- Perfila antes de optimizar. Sigue siendo cierto, más urgente que nunca. El código generado por IA suele ser ingenuo en cuanto a características de rendimiento. Mide antes de aceptar la primera solución que funciona.
- Elige estructuras de datos aburridas. Un HashMap y una lista ordenada te llevarán más lejos que un trie ingenioso en el 95% de los escenarios reales de producción. Empieza por ahí.
- Lee el código generado. No por encima — léelo de verdad y razona sobre él. ¿Qué hace esto con una lista vacía? ¿Qué pasa cuando esta llamada a la base de datos devuelve null?
- Resiste el impulso de abstraer. La regla de que "los datos dominan" es especialmente relevante: acertar con el modelo de datos vale más que cualquier ingenio algorítmico que pongas encima.
La ironía de 2026 es que los fundamentos importan más ahora, no menos — precisamente porque las herramientas que generan código no mantienen el modelo mental de corrección. Esa parte sigue siendo tuya.
Los ingenieros que están dando upvote a Rob Pike en Lobste.rs esta semana parecen saberlo. La pregunta es si lo asimilamos antes o después del informe de incidencia.
Fuentes: Rob Pike's 5 Rules of Programming · To be a better programmer, write little proofs in your head · Is simple actually good? · Things That Turbo Pascal Is Smaller Than