Metodología para escribir artículos técnicos con mucha experiencia
TL;DR
Escribir un artículo técnico que funcione (que se lea, se comparta, se cite) no es cuestión de talento: es un proceso. Estructura: ángulo único + plan numerado + voz activa + recorte brutal. Edición: corta el 40 % del borrador, cita la fuente de cada cifra, relee en voz alta. Resultado: artículos que atraen lectores cualificados (otros devs, líderes técnicos, founders). En mi portfolio, los 5 artículos que siguen este proceso generan el 60 % del tráfico y el 80 % de las citas.
1. Antes de escribir: el problema de un mal ángulo
Error nº 1: quieres escribir "sobre un tema" (por ejemplo "Flutter vs React Native"). Por lo general es vago, demasiado amplio, imposible de tratar con honestidad.
Error nº 2: escribes para demostrar lo que sabes. Resultado: 5k palabras de enumeración de features, cero opinión, cero utilidad para el lector.
Error nº 3: escribes lo que ya existe. "Los 10 mejores frameworks" nº 42, "Por qué debes aprender Rust". Genéricos, olvidables, ahogados entre 10k resultados de Google.
Solución: definir un ángulo único antes de la primera palabra.
Un ángulo es: para QUIÉN, que se enfrenta a QUÉ PROBLEMA EXACTO, cuál es la respuesta que nadie más ha planteado con claridad.
Ejemplo de mal ángulo: "Flutter vs React Native."
Ejemplo de buen ángulo: "Flutter vs React Native para un dev experto en móvil que quiere lanzar un SaaS web + app, en las Antillas, sin ningún equipo detrás."
El buen ángulo te obliga a tomar posición. Es más arriesgado (vas a contradecir a gente), pero es muy preciso. Y la gente comparte lo que zanja.
2. Plan antes que prosa
Antes de escribir una sola frase del cuerpo, preparas un plan numerado. Es tu grafo de dependencias: ¿qué idea depende de cuál?
Regla: ninguna sección debe referenciar una noción introducida más abajo.
Mal plan:
- Benchmark de rendimiento
- Definición de "rendimiento"
- Trampas de interpretación
Buen plan:
- Definición de "rendimiento"
- Trampas comunes
- Benchmarks reales y por qué se contradicen
Cuando tu plan se sostiene (lógica lineal), se lo enseñas a alguien. No para que te lo apruebe, sino para que pregunte "¿por qué empiezas por ahí?". Si tienes que explicarlo, tu plan tiene un agujero.
3. Citar fuentes, no improvisar
Cada afirmación con cifras o técnica debe tener una fuente. No para cubrirte legalmente, sino porque escribes para gente cualificada. Van a verificar. Si hay un error, pierdes credibilidad.
Proceso:
- Afirmación: "React Native domina con 6 400 ofertas frente a 1 070 de Flutter (EE. UU. 2026)."
- Fuente: LinkedIn Recruiter, filtro de búsqueda "React Native", captura del contador en mayo de 2026.
- Nota: "Cifra variable según la plataforma (Indeed vs LinkedIn) y el momento. Orden de magnitud: de 2 a 8× más ofertas de RN."
- En el artículo: "React Native: ~6 400 ofertas vs Flutter ~1 070 (LinkedIn Recruiter, mayo de 2026). La proporción varía según la fuente (Indeed, Glassdoor), pero la ventaja de RN es clara."
Citas la fuente, anotas que depende del momento, conservas la confianza del lector.
Trampas:
- Una cifra que se cita por todas partes (pero nadie ha verificado): vuelve a la fuente primaria.
- Tu opinión presentada como un hecho: di "opinión". Ejemplo: "Creo que Flutter tiene mejor futuro" ≠ "Flutter crece más rápido".
- Una fuente de hace más de 3 años en un sector que cambia rápido: anota la fecha, di claramente que está desactualizada.
4. Voz y tono: reglas mecánicas
Olvida el "encuentra tu voz única". Empieza por reglas simples que se aplican de forma mecánica.
Voz activa
Mal: "Un framework es elegido por los devs en función de las ofertas."
Bien: "Los devs eligen su framework primero por las ofertas."
Prueba mecánica: si "por monos" encaja al final de tu frase y la frase se sostiene, es pasiva. Reescríbela.
Dirección directa
Mal: "El usuario debe instalar el CLI."
Bien: "Instalas el CLI con npm install -g."
¿A quién te diriges? Si es algo genérico ("los devs"), queda flojo. Di quién es. "Tú, dev de Flutter", "Tú, founder con un equipo JS", "Tú, arquitecto móvil".
Presente e imperativo
Mal: "Habría que plantearse instalar las dependencias."
Bien: "Instala las dependencias."
Nada de "habría que", nada de "deberíamos". Di el hecho. Y si es una recomendación condicional, di la condición.
Frases cortas
Mal: "Teniendo en cuenta los frameworks multiplataforma disponibles hoy en el mercado, que ofrecen todos una experiencia de desarrollo distinta y un rendimiento diferente según el contexto de uso, la elección se vuelve compleja."
Bien: "La elección del framework depende de tres factores: el rendimiento que necesitas, el equipo que tienes y el mercado laboral. Ningún framework gana en todo."
Cuenta las palabras: corta las frases de más de 20 palabras. Una regla simple, casi mágica para aclarar el texto.
5. Recorte brutal: corta el 40 %
Tu borrador es demasiado largo. Todos los borradores lo son.
Pasada de recorte, palabra por palabra:
- Adjetivos que no cambian nada: "muy", "solo", "realmente", "prácticamente". Córtalos. "Es un lenguaje muy flexible" → "Es un lenguaje flexible."
- Cuantificadores vagos: "muchos", "a menudo", "la mayoría", "raramente". Sustitúyelos por una cifra. "Muchos devs eligen RN" → "El 60 % de los proyectos móviles nuevos usan RN."
- Relleno informativo: párrafos que reformulan lo que acabas de leer. Córtalos por completo.
- Transiciones que resumen: "Hemos visto que X. Pasemos ahora a Y." → Pasa directo a Y, la transición es implícita.
Prueba: lee el borrador. Cada vez que pienses "vale, ya lo entendí, pasa al siguiente", ese pasaje se corta.
Resultado esperado: pierdes el 30-40 % de las palabras, pero la comprensión aumenta. Menos es más.
6. Estructura y formato: legibilidad
Títulos
- Mayúscula solo en la primera palabra (no "Análisis De Rendimiento", sino "Análisis del rendimiento").
- Descriptivos (no "Veredicto", sino "Veredicto: React Native para un SaaS web + móvil").
- Sin preguntas retóricas ("¿Por qué Flutter?" → "Por qué elegir Flutter").
Listas
- Introdúcelas con dos puntos.
- Sin orden (-) para elementos independientes, numeradas (1, 2, 3) para una secuencia.
- Formato
**Término**: descripción.
Ejemplo:
Ventajas de Flutter:
- **Hot reload**: modificas el código y ves el cambio en < 1 s.
- **Single codebase**: una sola base para móvil, web y escritorio.
Tablas
Excelentes para comparar. Peores para enumerar (usa una lista en su lugar).
Mala tabla: | Framework | Cosa | |---|---| | Flutter | Impeller | | RN | Hermes |
Buena tabla (comparar de verdad): | Métrica | Flutter | React Native | |---|---|---| | Rendimiento de animaciones | 9,5/10 | 8/10 | | Tamaño del binario | 15-25 MB | 8-15 MB |
7. Edición de fondo: la verdadera magia
Escribir es el 20 % del trabajo. Editar es el 80 %.
Pasada 1: estructura
Lee tu borrador. ¿El plan se sostiene? ¿Las dependencias? ¿Hay un salto sin explicar donde me pregunto "por qué dice eso?"
Si lo hay, reorganiza o añade una frase. No hace falta que sea perfecto, solo lógico.
Pasada 2: voz
Lee en voz alta (de verdad). Cada vez que tropieces con una frase o suene "corporativa", reescríbela. La verdadera prueba: ¿puede un colega que no es del sector tech entender el primer párrafo sin diccionario?
Pasada 3: hechos
Cifra por cifra. ¿Fuente? ¿Actualizada? ¿Mala fuente? Corrige o elimina.
Pasada 4: recorte
Aquí es donde cortas el 40 %. Elimina sin piedad lo flojo.
Pasada 5: detalle
Erratas, formato, enlaces, referencias. Es mecánico pero crítico. Una errata no cambia tu credibilidad, pero 5 erratas sí.
8. SEO ligero
Nada de keyword stuffing. Pero unas cuantas reglas evidentes:
- Título: debe contener una palabra clave útil ("Metodología para escribir", "Flutter vs React Native").
- Descripción: 160 caracteres, resume el artículo e incluye la misma palabra clave si es pertinente.
- Headings: tus H2 y H3 deben poder explorarse. Quien escanee los títulos tiene que entender el artículo.
- Enlaces: enlaza tus otros artículos cuando sea natural, no para hacer link building.
Sinceramente, si escribes bien y citas bien tus fuentes, Google te quiere. No hacen falta trucos.
9. Publicación y promoción
Cuando el artículo está listo (editado, con fuentes, releído), lo publicas. Pero el verdadero trabajo viene después.
Día 0: publicación
- Publica un extracto en LinkedIn (100-200 palabras, enlace al artículo).
- Publica en dev.to (si aplica).
- Envía un email a 3-5 personas a quienes pueda interesar.
Semana 1-2
- Recibe feedback (comentarios, citas, "me ayudó").
- Si encuentras un error, corrígelo y publica una actualización.
- Responde a cada comentario (demuestra que lees).
Mes 1-3
- Artículos que funcionan (muchas vistas, compartidos): retuitéalos, refiérelos en otros contenidos.
- Artículos que no funcionan: ¿qué falló? ¿Mal ángulo? ¿Mal momento? ¿Pocas fuentes?
10. Cuándo parar
No todos los temas merecen un artículo. Algunas señales de que deberías escribir:
- Tienes una opinión que contrasta con lo que existe ("todo el mundo dice X, pero es falso porque Y").
- Has pasado más de 40 horas aprendiendo, pruebas incluidas. Hay algo que compartir.
- Es accionable para el lector. No una reflexión, no algo filosófico, sino algo que se hace.
- Ya has visto la pregunta planteada 5 o más veces por personas distintas.
Si se cumplen 3 de 4, escribe.
Si no, probablemente sea un hilo de LinkedIn (2 min para escribirlo), no un artículo (2 días).
Resultados reales en mi portfolio
Desde 2024, 20 artículos publicados, ~40k vistas acumuladas.
| Artículo | Vistas | Compartidos | Citas | |---------|------|----------|-----------| | Flutter vs React Native 2026 | 8200 | 140 | 23 | | Impactos del open source en una startup | 3100 | 45 | 8 | | Instalar Hadoop en MacBook M1/M2 | 4500 | 62 | 15 | | (Otros 17 artículos) | 24k | 350+ | 40+ |
Los 5 que siguen este proceso exactamente (ángulo único, plan, voz, edición estricta) generan el 60 % del tráfico. ¿Los demás? Correctos pero olvidables.
En resumen
Un buen artículo no es cuestión de talento, es un proceso.
- Ángulo único y estrecho.
- Plan que se sostiene.
- Cita la fuente de cada hecho.
- Voz activa, frases cortas.
- Edita brutalmente.
- Lee en voz alta.
- Publica e interactúa.
Es un rollo de hacer. Por eso la mayoría de la gente escribe rápido (y olvida rápido). Si aceptas dedicar 2-3 días a un artículo, vas a escribir algo que se recuerde.
Buena suerte.