Checklist de "¿esta idea merece un artículo técnico?"

Publicado el 16 de febrero de 2026 • 8 minutos • 1659 palabras

Table of contents

¿Problema real o juguete brillante?
¿Arregla algo … mejor que lo que ya tenías?
¿Moda pasajera o tendencia que está para quedarse?
¿Hay chicha… sin convertirlo en tesis doctoral?
¿Puedes contar al menos una historia decente?
¿Estás aportando algo… o solo cambiando la plantilla?
¿Le será útil a tu yo del futuro?
Checklist rápido (la versión que puedes pegar en un README)
Fuentes y referencias

La mayoría de los buenos artículos técnicos nacen de lo mismo: alguien se ha hecho daño con un problema real y ha decidido que, ya que ha sangrado, al menos que otros no tropiecen en el mismo sitio. Luego está el otro tipo de artículo: el que sale después de ver el enésimo post en LinkedIn diciendo que “X va a revolucionar el desarrollo de software” y pensar “esto huele a humo, pero déjame mirarlo por si acaso”.

Este texto va de eso: de cómo decidir si una idea merece un artículo (y tu tiempo) o si es mejor dejarla pasar, cerrar la pestaña y seguir con tu café. Y, de rebote, sirve también como checklist para evaluar si una “nueva” tecnología o patrón vale la pena, más allá del marketing.

¿Problema real o juguete brillante?

La primera pregunta es casi existencial:

“¿Esto resuelve un problema que yo o mi audiencia ya sufrimos… o solo es una cosa brillante que me apetece trastear?”

Si no puedes explicar el dolor sin mencionar el nombre del framework o patrón, mala señal. “Necesitamos Kafka” no es un problema; “nuestro sistema se ahoga porque hemos metido toda la comunicación asíncrona en una sola cola casera sin orden ni garantías” sí lo es.

Piensa en cosas muy concretas:

¿Qué se está haciendo hoy a mano que podría automatizarse sin montar un circo?
¿Qué parte del sistema da más guerra en cada release?
¿Dónde se quejan negocio, soporte, SRE o tus usuarios finales?

Si la respuesta sincera es “nadie tiene este problema todavía, pero he visto cuatro charlas de conferencia muy chulas/convincentes/espectaculares”… probablemente estás delante de un precioso shiny object, no de un tema de artículo serio.

Regla rápida: si no puedes describir el problema de forma sencilla, sin buzzwords ni nombres propios, el problema eres tú, no el framework.

¿Arregla algo … mejor que lo que ya tenías?

Supongamos que hay un problema de verdad. Siguiente filtro:

“¿La nueva idea mejora claramente algo que ya existe, o solo lo rehace con otro logo?”

Antes de lanzarte a escribir 1500 palabras sobre eso tan maravilloso, pregúntate:

¿Qué va a ser mejor si aplico esto? ¿Me hará la vida más fácil? ¿Reducirá gastos? ¿Me dará más velocidad de entrega ? ¿Sufriré menos sustos a las tres de la mañana?
¿Qué alternativa sensata había antes? ¿Un CRUD decente, un poco de caché, una cola sencilla, una BBDD bien diseñada?

Sospecha de todo lo que solo se puede vender con palabras tipo “revoluciona”, “transforma”, “disruptivo”, pero que nadie consigue ilustrar con un ejemplo de “antes/después” reconocible. Es el mismo patrón que se ve con mucho AI‑washing : promesas espectaculares, casos de uso concretos … cero.

Si la ventaja real no se ve clara en un escenario realista -un e‑commerce, un SaaS, un sistema interno-, aún no hay materia para un artículo técnico; hay materia para un meme.

¿Moda pasajera o tendencia que está para quedarse?

No se trata de ir de cínico profesional, que también, sino de distinguir entre la moda de este trimestre y algo que, como mínimo, va a seguir aquí dentro de 3 o 5 años .

Estas son algunas pistas de que algo es, probablemente, una moda:

Nadie se pone de acuerdo en qué problema exacto resuelve.
Todo el mundo lo menciona en presentaciones, casi nadie lo usa en producción a escala .
El marketing va muy por delante de las historias reales de batalla.

En cambio, una tendencia sólida suele traer otras señales:

Hay casos de estudio razonables , con pros y contras, no solo fuegos artificiales.
No solo lo venden los vendors: equipos normales cuentan cómo lo usan , con qué límites y qué dolor les ha quitado de encima.
Empieza a integrarse en ecosistemas conocidos, en lugar de vivir como juguete aislado.

Te propongo un par de de ejemplos:

Event Sourcing / CQRS : tiene sentido en dominios donde la auditabilidad, la trazabilidad y la reconstrucción de estado son críticas (finanzas, pagos, sistemas regulatorios). Si lo quieres solo porque viste una charla épica con diagramas hexagonales, quizá no es el momento.
IA en todas partes: etiquetar todo como “AI‑powered ” porque queda bien en el roadmap no es una tendencia, es marketing con esteroides . Usar IA para reducir trabajo repetitivo (clasificar, resumir, buscar mejor) donde hoy se hace a mano, eso sí empieza a parecer estructural.

Si no sabes en qué lado cae tu tema, igual el artículo que toca escribir todavía no es “X explicado”, sino “qué me ha hecho desconfiar (o ilusionarme) con X”.

¿Hay chicha… sin convertirlo en tesis doctoral?

Un buen artículo técnico no es una chuleta de comandos ni un paper académico de 40 páginas. Necesita un equilibrio:

Un poco de contexto: de dónde sale esta idea , qué problemas intentaba resolver originalmente.
Uno o dos casos de uso concretos donde encaje.
Uno o dos sitios donde no encaje y te complique la vida.
Suficientos detalles prácticos como para que alguien pueda empezar a probarlo con sentido.

Si lo único que consigues sacar del tema es una lista de bullet points de marketing o un resumen destilado de la documentación oficial, todavía no tienes tu artículo: tienes apuntes.

Un test sencillo: en tu primer borrador, ¿eres capaz de escribir un párrafo sin trampa de “cuándo NO usar esto”? Si no, aún te falta comprensión. Y eso no es malo, solo significa que es pronto para recomendarlo a otros.

¿Puedes contar al menos una historia decente?

Los artículos que más se comparten no suelen titularse “El patrón X explicado”, sino cosas como “Cómo paramos de romper producción cada viernes usando X ” o “Qué aprendimos reescribiendo este módulo con Y ”.

Historias simples pero potentes:

“Qué problema teníamos.”
“Qué probamos antes que no funcionó.”
“Qué pasó cuando aplicamos X (lo bueno y lo malo).”

Pregúntate:

¿Tienes, al menos, un ejemplo realista con antes/después?
¿O puedes construir un ejemplo que funcione (un checkout, un flujo de pagos, un sistema de colas) y que no parezca sacado de un examen teórico?

Si todo lo que tienes son definiciones y diagramas genéricos, es posible que todavía te falte roce con el problema. En ese caso, el mejor siguiente paso no es publicar, es probar: un prototipo, una prueba controlada, un experimento del que ya saldrá un artículo con más criterio.

¿Estás aportando algo… o solo cambiando la plantilla?

A menos vayas a inventar un área nueva de la informática, no vas a ser la primera persona en escribir sobre casi nada. Eso está bien: tu valor no es ser el primero, es ser útil.

Hay cosas que sí suman:

Bajar la idea a problemas cotidianos: pagos que se duplican, colas que se llenan, logs imposibles de leer, SLOs incumplidos.
Compararla sin tapujos con alternativas más simples: ¿de verdad necesitas CQRS, o con un buen CRUD y eventos de dominio te basta?
Contar trade‑offs reales: qué te dio, qué te quitó, qué te complicó.
Traer experiencias de dominios menos trillados: nuclear, sanidad, banca regulada, etc., donde los requisitos son distintos a los de la típica startup SaaS.

Si al releer tu borrador piensas “bueno, esto se podría sustituir por un enlace a la página oficial y el lector perdería poco”, probablemente te falta ángulo propio. Mejor esperar a tenerlo que publicar lo mismo pero con otro tema de WordPress.

¿Le será útil a tu yo del futuro?

Este último criterio es egoísta, y la mayor parte de las veces es mi principal criterio, precisamente por eso creo que es buenísimo:

“¿Este artículo me servirá a MÍ como referencia dentro de un año?”

Si la respuesta es sí, casi seguro le servirá también a alguien más:

Porque documenta una decisión complicada (“por qué NO migramos a microservicios en 2025”).
Porque condensa información de varias fuentes dispersas en una guía coherente .
Porque captura cagadas que no quieres repetir y que otros se ahorrarían leyendo tus tropiezos.

Este filtro es especialmente útil para:

El framework salvador del mes.
Patrones avanzados que dan mucho juego … y mucho trabajo (Event Sourcing , CQRS , Data Mesh ).
Cosas “de moda” como no‑code/low‑code, features con IA , nuevo servicio cloud mágico.

Si ni siquiera tú crees que dentro de un año volverás a ese enlace, igual lo que estás escribiendo es para un algoritmo, no para personas.

Checklist rápido (la versión que puedes pegar en un README)

Antes de decidir “voy a escribir un artículo técnico sobre …”, lánzale estas preguntas:

¿Qué problema real resuelve y a quién le duele?
¿Mejora de verdad algo existente o es el mismo perro con otro collar?
¿Tiene pinta de tendencia sólida o solo de moda de slide?
¿Puedo explicar también cuándo NO usarlo?
¿Tengo al menos un ejemplo concreto, realista?
¿Aporto algo distinto a lo que ya dicen docs y blogs genéricos?
¿Yo mismo lo volvería a consultar dentro de un año?

Si la mayoría son “sí”, probablemente tienes material para un buen artículo (y para tomar una decisión técnica con cabeza). Si abundan los “mmm … no mucho”, igual lo único que tienes son ganas de jugar con un juguete nuevo. Y eso es maravilloso: juega, cacharrea, aprende… pero no hace falta convertir cada juguete en un manifiesto en Medium o LinkedIn.

La idea es sencilla: escribir menos sobre modas, y más sobre decisiones.

Tus lectores -y tu futuro yo- te lo van a agradecer.