Feliz día 256: la única fiesta del año que hay que calcular

Hoy es domingo.

Domingo 13 de septiembre, para más señas. Y hoy es el Día de los Programadores, una fiesta a la que este año le ha tocado caer en el peor día posible: uno en el que ni siquiera hay nadie en la oficina para no felicitarte.

Porque esa es la diferencia. El Día del Sysadmin —del que ya escribí en julio— cae siempre en el último viernes de julio, que es una fecha con criterio: hay gente, hay tarta y hay caña después. El de los programadores cae donde caiga. Este año, domingo. El que viene, lunes. Y en 2028 se celebrará el 12 de septiembre, no el 13.

Sí: se mueve. Ya te vas oliendo por dónde va esto.

Un programa entero, en tarjetas perforadas. Foto: ArnoldReinhold, CC BY-SA 3.0; imagen recortada y disponible bajo la misma licencia.

No es el 13 de septiembre. Es el día 256

La fecha no es una fecha. Es el día 256 del año.

Que en un año normal cae el 13 de septiembre y en un año bisiesto cae el 12, porque febrero mete un día de más y todo lo que viene detrás se desplaza. El gremio que se dedica profesionalmente a que las cosas funcionen igual todos los días eligió, para su propia fiesta, una fecha con un caso especial.

Me parece perfecto. Es de una honestidad conmovedora.

¿Y por qué 256? Por dos motivos que en realidad son el mismo:

1. 256 = 2⁸: la cantidad de valores distintos que caben en un byte. Ocho bits, la unidad que lleva décadas apareciendo por todas partes en informática.
2. Es la mayor potencia de dos que cabe en un año. La siguiente, 512, se sale del calendario. Así que 256 no es solo bonito: es el máximo simbolismo disponible dentro del presupuesto de 365 días.

Y hay un tercer motivo, no escrito, que es el que de verdad explica la elección: el día 256 obliga a calcular. No te vale con mirar el calendario. Tienes que contar. Y contar días es exactamente el tipo de tarea que un programador delega en una función que luego se rompe en febrero.

El chiste que casi nadie cuenta

Aquí viene la parte que a mí me hace una gracia especial.

Un byte guarda 256 valores distintos: del 0 al 255.

O sea, que la profesión que ha convertido empezar a contar desde cero en seña de identidad —el índice 0, el array que arranca en 0, el primer elemento que es el elemento cero— eligió como fiesta el día 256 contando desde el 1.

Si contásemos los días como contamos los arrays, hoy sería el día 255. El 256 sería mañana.

Es un off-by-one institucionalizado. O eso me gusta contar, porque el decreto no tiene ningún fallo: los días ordinales del calendario se numeran desde uno, como debe ser, y el 256 es el 256. El chiste es nuestro, no suyo — humor profesional de gente a la que le enseñaron a empezar a contar por el cero.

Y así, no se puede pedir más.

La historia real: un tío, unas firmas y un decreto

Porque sí, hay un jefe de Estado de por medio, y la historia es tan de andar por casa como la del anuncio de impresoras que dio origen al Día del Sysadmin.

En 2002, un empleado de una empresa rusa de desarrollo web llamado Valentin Balt se puso a recoger firmas para pedirle al Gobierno de su país que reconociera oficialmente el día del programador. Una petición ciudadana, en 2002, hecha desde una empresa de diseño web. Con eso te haces una idea del volumen de la iniciativa.

Tardó siete años en llegar a algún sitio. El Ministerio de Comunicaciones redactó la propuesta en julio de 2009 y el 11 de septiembre de 2009 el presidente Dmitri Medvédev firmó el decreto. Dos días antes del día 256, que es un margen de despliegue muy de nuestro sector.

Desde entonces Rusia lo tiene reconocido oficialmente por decreto, con papel timbrado. En el resto del mundo es lo que suele ser todo en informática: una convención que se ha impuesto porque a la gente le hizo gracia y nadie propuso nada mejor.

China lo hizo mejor (y sin bugs)

En China el día del programador es el 24 de octubre. Escrito a la manera anglosajona, mes/día: 10/24. Y 1024 es 2¹⁰, el kilobyte de toda la vida.

Fíjate en el detalle: 1024 es una potencia de dos más grande, más redonda para cualquiera que haya mirado alguna vez el tamaño de un fichero… y, sobre todo, cae siempre el mismo día. Sin bisiestos, sin desplazamientos, sin casos especiales.

Los chinos eligieron la fecha que no tiene edge case.

Nosotros elegimos la que hay que recalcular cada año.

Si tuviera que resumir en una sola imagen la diferencia entre diseñar pensando en el mantenimiento y diseñar pensando en que quede elegante hoy, usaría exactamente esta.

Septiembre de 1956: el abuelo del disco duro

También en septiembre de 1956 nació el abuelo del disco duro.

IBM presentó el 305 RAMAC, el primer ordenador comercial que usó almacenamiento en disco de acceso aleatorio. El primero de todos.

Sus números, para que te los guardes:

Cinco millones de caracteres. Una tonelada. Cincuenta discos del tamaño de la rueda de un coche girando dentro de un armario del tamaño de dos frigoríficos.

La foto que hiciste ayer con el móvil, sin mirar, para acordarte de dónde habías aparcado, podría no caber en ese armario.

Y ojo, que esto no va de reírse de 1956. Va de lo contrario. Aquella máquina resolvía un problema real de una empresa real, y alguien la programó sin depuradores decentes, sin Stack Overflow, sin autocompletado y, desde luego, sin pedirle a un modelo que le escribiera la función. Cuando dentro de setenta años alguien mire lo que hacemos hoy, la parte que le parecerá heroica no será la tecnología. Será que lo sacábamos adelante con lo que había.

Setenta años después: escribir código ya no es el trabajo

Y aquí es donde bajo del monte con la reflexión de rigor, porque este blog es lo que es.

En 2026 escribir el borrador de una función ya no es el cuello de botella: se lo pides a una IA y lo tienes en veinte segundos. Ojo con el atajo mental, porque no es lo mismo: lo que se ha abaratado enormemente es generar un borrador. Producir código correcto, integrado con el resto, revisado y mantenible sigue costando lo que costaba.

Lo caro sigue siendo, en buena medida, lo de siempre:

• Decidir qué hay que construir. Y, sobre todo, qué no hay que construir.
• Entender el código que ya existe. Un programador se pasa mucho más tiempo leyendo que escribiendo. Y ahora, además, leyendo cosas que ha escrito una máquina y que parecen correctas, que es la categoría de código más peligrosa que existe.
• Mantenerlo vivo diez años. Que es de lo que hablo siempre en «No necesito mantenimiento web» y es lo que nadie presupuesta.
• Responder a las tres de la mañana cuando eso que se escribió en veinte segundos hace dieciocho meses decide dejar de funcionar.

Cada línea de código que añades a un sistema es una línea que alguien tendrá que entender, actualizar, parchear y, con suerte, borrar.

El código no es un activo que se acumula: es un pasivo que se hereda.

Que ahora se genere más rápido no lo convierte en gratis. Lo convierte en más pasivo por hora.

Por eso el mejor programador que conozco no es el que más produce. Es el que, delante de un requisito, es capaz de decir: «esto no hay que hacerlo». Y de argumentarlo.

Esa frase cuesta arrancársela a una IA. No es que no pueda decirla: si le das el contexto y le planteas expresamente esa decisión, un modelo puede perfectamente recomendarte que no construyas algo. Lo que no tiene es lo demás — no conoce por sí solo las prioridades reales de tu empresa, no responde de la decisión y tiende a contestar al encargo tal y como se lo has formulado. Si le pides la función, te da la función.

Feliz día 256

Así que hoy, domingo, día 256 de 2026:

• Si programas: felicidades. Aunque nadie te felicite, que es la tradición.
• Si trabajas con alguien que programa: hoy no le mandes un mensaje preguntando si «es rápido». Mañana tampoco, ya que estamos.
• Si tienes una empresa y tu negocio depende de un software que escribió alguien: hoy es buen día para saber quién fue, si sigue disponible y qué pasaría si mañana no lo estuviera.

Y si eres de los que empiezan a contar desde cero: tranquilo, tu día es mañana. Nos vemos el 257.