Mi sistema de notas en 2026¶

7 minutos de lectura · 2 abril 2026

Cada año reescribo cómo tomo notas. Cada año pienso que esta vez es definitivo. Cada año me equivoco. La novedad de 2026 es que esta vez sí parece estable, llevamos doce meses con el mismo sistema y la única razón es que el sistema es mucho más aburrido que los anteriores.

Cuanto más vistoso es tu sistema de notas, menos lo usas.

He pasado por Notion, por Obsidian con doscientos plugins, por Logseq, por Tana, por Roam. Cada herramienta brillante. Y cada vez gastaba más tiempo manteniendo el sistema que escribiendo notas.

El sistema actual, en una pantalla¶

• Markdown plano en una carpeta notas/ versionada con git.
• Tres tipos de fichero: diario/, proyectos/, referencia/.
• VS Code como editor por defecto. Sin plugins exóticos.
• ripgrep para buscar.
• Cero linking automático. Cero base de datos. Cero plugins.

Eso es todo. Está deliberadamente desnudo y por eso sigue vivo.

Lo que llamo "diario"¶

Un fichero por día en diario/YYYY/MM/YYYY-MM-DD.md. Lo abro a primera hora y lo cierro a última. Estructura mínima:

# 2026-04-02

## hilos abiertos
- [ ] revisar PR #142
- [x] llamar a M.

## notas
- charla con J.: piensa que el ramp del feature está demasiado rápido. apuntar.

## salud / fuera de trabajo
- 7h dormidas, corrí 30'. cansado.

No es un journal, no es una agenda, no es un task tracker. Es un sitio donde dejo el cerebro al final del día y lo recojo a la mañana siguiente. Si quiero revisar qué pasó hace dos meses un viernes, hago rg por la fecha.

Lo que llamo "proyectos"¶

Un fichero por proyecto activo, en proyectos/. Vivos mientras el proyecto lo está. Cuando termina, se mueve a proyectos/archivo/.

Cada fichero tiene cuatro secciones fijas:

# proyecto X

## objetivo
una frase, lo más concreta posible.

## estado actual
qué está pasando ahora. máximo cinco líneas.

## próximas decisiones
qué tengo que resolver y cuándo.

## bitácora
[2026-04-01] decisión: vamos con la opción B porque ...
[2026-03-28] reunión con M., quedamos en que ...

La sección de bitácora es la única que crece. Las otras tres se reescriben cuando cambian. Es deliberado: leer el archivo siempre debe darte el estado actual en los primeros tres bloques.

Lo que llamo "referencia"¶

Cosas que vuelvo a consultar: snippets de comandos, configuraciones que olvido, lecturas que quiero recordar.

Estructura libre. La única regla: si no he abierto un fichero en seis meses, se va a referencia/archivo/. Reducir la cantidad de cosas a las que mirar es más valioso que reordenarlas.

Las reglas que me funcionan¶

1. Una nota = un fichero. No subcarpetas profundas. No bases de datos. find y rg resuelven todo.
2. El presente vivo es siempre poco. Si tengo más de cinco proyectos abiertos, alguno se duplica con otro. Auditar mensualmente.
3. Búsqueda como interfaz principal. Linking elaborado es un proxy para "no sé buscar". rg -i ha resuelto el 95% de los problemas que un grafo prometía resolver.
4. Nada de etiquetas. El pasado intento de tags fue una piscina de basura. Las palabras del texto son suficientes.
5. Backup ≠ sistema. El backup es git push diario. El sistema es cómo escribes, no dónde lo guardas.

Por qué importa la aburrición¶

Cada sistema brillante que probé tenía una promesa: "esta vez no se va a romper". Y siempre se rompía cuando llegaba una semana intensa, porque mantener el sistema requería atención que no tenía.

Markdown plano + git + VS Code no requiere atención. Está ahí, no se rompe, no exige nada. Es lo mínimo que se puede hacer y por eso es lo que sobrevive a los meses malos.

Tu sistema de notas tiene que aguantar tu peor semana, no tu mejor sábado por la mañana.

¿Comentarios o correcciones? info@encodigo.es.