Un plan de dominio continuo: profundizar, contribuir y no quemarse

Hasta ahora alguien decidía qué venía después. Esa comodidad se acaba en esta línea: no hay nivel cuarenta, y el siguiente paso no está escrito en ningún índice. Es la transición más difícil de cualquier disciplina, porque el aprendizaje deja de ser una secuencia y pasa a ser un sistema que tienes que diseñar y sostener tú. La mayoría fracasa aquí de dos maneras simétricas. Unos se detienen, siguen usando lo que ya saben y en tres años son buenos en un Swift que ya no existe. Otros intentan seguirlo todo, se suscriben a quince fuentes, leen cada propuesta y cada nota de versión, y abandonan a los seis meses convencidos de que el problema era su capacidad. Ninguno de los dos falla por falta de talento: fallan por no tener un sistema. Esta lección es ese sistema, y está construido sobre lo que la investigación sobre pericia sabe de verdad, no sobre motivación.

Tres bucles, no una lista

Una lista de temas pendientes no sobrevive a un trimestre ocupado. Un sistema de bucles sí, porque cada bucle tiene su propia frecuencia, su propio objetivo y su propia señal de que funcionó.

La razón de que sean tres y no uno es que el aprendizaje tiene tres necesidades incompatibles entre sí: exposición constante a lo desconocido, cierre de preguntas concretas y construcción de algo que no cabe en una sesión. Un solo ritmo no puede servir a las tres, y por eso la gente que solo lee nunca consolida, la que solo experimenta nunca amplía y la que solo hace proyectos grandes se queda sin repertorio.

El bucle diario dura entre quince y treinta minutos y su objetivo es el contacto, no el progreso. Consiste en una sola cosa: leer código que todavía no sabrías escribir. Un archivo de stdlib/public/core, una implementación de swift-collections, un módulo de un proyecto de código abierto que admires. No hay que terminarlo ni entenderlo entero; hay que anotar una pregunta. Las preguntas se acumulan en un fichero y son la materia prima del siguiente bucle.

El bucle semanal dura una o dos horas y su objetivo es la resolución. Tomas una pregunta del fichero y la conviertes en un experimento reproducible: un Package.swift mínimo, dos variantes que difieran en una decisión, una medición o un volcado de SIL, y tres líneas de conclusión escritas. Ese registro escrito es lo que distingue este bucle de simplemente cacharrear; sin la conclusión escrita, en dos meses tendrás la vaga sensación de haberlo mirado y ningún dato.

El bucle trimestral dura entre diez y veinte horas repartidas y su objetivo es la profundidad. Es un proyecto con entregable público: implementar una estructura de datos no trivial con ownership explícito, escribir una macro que resuelva un problema real de tu equipo, portar una biblioteca a Linux, o contribuir un parche. Uno por trimestre, terminado y publicado. Cuatro al año durante tres años son doce artefactos que constituyen una trayectoria visible, y la visibilidad importa porque es lo que convierte el conocimiento privado en oportunidades.

El experimento del bucle semanal no necesita infraestructura, y ese es su mérito: si montarlo cuesta más de dos minutos, no lo harás.

mkdir -p ~/lab/2026-w31 && cd ~/lab/2026-w31
swift package init --type executable --name Pregunta
# dos variantes en el mismo fichero, una sola diferencia entre ellas
swiftc -emit-sil -O Sources/Pregunta/main.swift | swift demangle > sil.txt

Y la conclusión escrita cabe en tres líneas, siempre con la misma estructura: qué preguntaste, qué observaste, qué criterio general se deriva. La tercera línea es la única que sobrevive al año, porque un criterio se transfiere a situaciones nuevas y una medición concreta no.

flowchart LR
D[Bucle diario: leer y preguntar] --> P[Fichero de preguntas]
P --> S[Bucle semanal: experimento y conclusion escrita]
S --> N[Cuaderno de decisiones]
N --> T[Bucle trimestral: artefacto publico]
T --> D
style D fill:#89b4fa,color:#11111b
style T fill:#a6e3a1,color:#11111b

La ruta corta hasta contribuir

Contribuir al proyecto Swift parece reservado a compiladoristas y no lo es. Hay una escalera, y los primeros peldaños son accesibles esta misma semana. Lo que hace valiosa la contribución no es el tamaño del cambio sino el ciclo completo que te obliga a recorrer: entender un sistema que no escribiste, defender una decisión ante alguien que sabe más y aceptar una corrección técnica sin tomártela en lo personal. Ese ciclo es difícil de conseguir de otra forma y es exactamente lo que acelera la pericia.

El procedimiento operativo es el mismo en los cuatro peldaños: abre una incidencia o comenta en una existente antes de escribir código, describe el enfoque en dos párrafos y espera confirmación, envía una PR pequeña y con test, y responde a la revisión sin defender el diseño más de lo que aguanta. La causa número uno de PRs abandonadas no es la calidad técnica: es empezar por el código en vez de por la conversación.

Conviene además tener calibrado el tamaño. Una PR de treinta líneas con un test se revisa en días; una de mil líneas que reorganiza un módulo se revisa en meses o nunca, por buena que sea. Si tu cambio no cabe en un párrafo de descripción, todavía no está listo para enviarse: está listo para partirse en tres.

Atención acotada, conocimiento acumulativo

El tercer frente no es aprender más, es decidir qué ignorar. Mantenerse al día es un problema de filtrado, no de volumen. La política que funciona tiene tres reglas. Primera, pocas fuentes primarias y ninguna secundaria: el repositorio de propuestas, los foros oficiales y las notas de versión del compilador. Los resúmenes de terceros son cómodos y te dejan siempre con la versión digerida de la decisión, nunca con el razonamiento. Segunda, una cadencia fija en lugar de flujo continuo: media hora cada quince días revisando qué propuestas cambiaron de estado, en vez de notificaciones. Tercera, y la más difícil, aprender bajo demanda con una excepción: no estudies una feature hasta que tengas un problema que la necesite, salvo que sea estructural, es decir, salvo que cambie el modelo mental y no solo añada una herramienta. La concurrencia estricta era estructural. Un nuevo operador de una biblioteca no lo es.

El criterio para distinguir una cosa de otra se puede escribir como una pregunta única: ¿esto cambia lo que el compilador acepta, o solo lo que yo escribo? Si cambia lo que el compilador acepta, tarde o temprano lo vas a encontrar en un error y conviene entenderlo antes. Si solo cambia lo que escribes, puede esperar a que lo necesites.

flowchart TD
N[Novedad detectada] --> Q[Cambia lo que el compilador acepta]
Q -->|si| E[Estructural: estudiar ahora]
Q -->|no| B[Herramienta: anotar y esperar demanda]
E --> A[Probar en un modulo pequeno]
B --> C[Cola de bajo interes]
style E fill:#f9e2af,color:#11111b
style B fill:#89b4fa,color:#11111b

Hay un cuarto elemento que casi nadie incluye y que sostiene a los otros tres: una fecha de caducidad para la ignorancia deliberada. Escribir «no voy a estudiar macros hasta abril» convierte una omisión angustiosa en una decisión con plazo, y es la diferencia entre elegir qué no aprender y sentir que vas siempre por detrás. La sensación es completamente distinta y el resultado técnico es el mismo.

El cuaderno de decisiones

Todo lo anterior se apoya en un único artefacto, y si solo puedes quedarte con una cosa de esta lección, que sea esta. Un cuaderno de decisiones no es un blog ni una colección de apuntes: es un registro fechado de preguntas cerradas, con el criterio general separado del caso concreto. Su formato importa poco mientras tenga cuatro campos.

2026-07-31 · Por que "any Coleccion" mata el rendimiento en el bucle de render

Pregunta.  El perfilador senala un 18% en retain y release dentro del bucle.
Evidencia. SIL de las dos variantes: la existencial mantiene witness_method y
           una caja por elemento; la generica se especializa y desaparece.
Criterio.  La especializacion necesita el tipo concreto en el sitio de llamada.
           Usar "any" solo si la heterogeneidad existe en tiempo de ejecucion.
Caduca.    Revisar cuando cambie la representacion de los existenciales.

El campo que hace el trabajo pesado es criterio, porque es lo único transferible: dentro de un año no recordarás el porcentaje ni el bucle, pero el criterio se aplicará a un problema que hoy no existe. El campo caduca es el segundo en importancia y casi nadie lo pone: registra que tu conclusión estaba atada a una versión del lenguaje, y evita que dentro de tres años sigas repitiendo como ley una limitación que ya se levantó.

Hay una objeción evidente y conviene responderla: escribir la entrada cuesta cinco minutos que preferirías dedicar al siguiente problema. El cálculo es correcto a una semana vista y desastroso a un año vista, porque sin registro la misma pregunta se investiga tres veces y las tres se olvida el criterio. Cinco minutos por entrada y cuarenta entradas al año son poco más de tres horas; reinvestigar cuarenta preguntas cuesta semanas. La escritura no es documentación del aprendizaje, es la parte del aprendizaje que lo hace permanente.

Al cabo de un año el cuaderno tiene entre treinta y cincuenta entradas, y ocurre algo que no se puede provocar de otra forma: al releerlo aparecen patrones entre criterios que se escribieron con meses de distancia, y de esos patrones salen las ideas que se convierten en el artefacto trimestral siguiente. El sistema empieza a alimentarse solo, y ese es el punto en el que el dominio deja de depender de tu fuerza de voluntad.