El motivo más común por el cual los desarrolladores no pueden leer un artículo es que el contenido no está mal. En la mayoría de los casos, es porque los idiomas hablados son diferentes. Los desarrolladores hablan en el lenguaje de la tecnología, mientras que los lectores entienden en el lenguaje de la vida. Si no se supera esta brecha, incluso el mejor contenido no permanecerá en la mente de las personas.
Las personas no recuerdan el código, recuerdan la situación. Seguramente has visto un artículo como este: "Esta función tiene una complejidad O(n)", "Esta estructura es altamente escalable", "Este enfoque es más eficiente". No son afirmaciones incorrectas. Sin embargo, unos días después, casi nadie recuerda el contenido de este artículo. En cambio, frases como esta permanecen: "¿Podrá este código salvarme cuando el servidor falle a las 3 de la madrugada?" Esta oración no contiene una explicación técnica compleja, pero sí una situación. Las personas entienden a través de la situación, no de la tecnología, y recuerdan a través de la situación.
Las características comunes de un buen artículo de desarrollador que se lee bien incluyen: la situación aparece antes que el código, el contexto antes que la descripción de la función, y se enfatizan las razones de la elección en lugar de la respuesta correcta. En resumen, fluye de esta manera: situación → reflexión → juicio → elección → resultado. Esta estructura se asemeja más a una historia que a un blog técnico, y las historias son la forma más efectiva de ser comprendidas por la mente humana.
Traducir la tecnología al lenguaje de la vida no significa simplificar términos difíciles. Es un cambio de perspectiva. Por ejemplo: "Este API no es RESTful" se convierte en "Este API hace que los principiantes sigan consultando la documentación", "Esta estructura tiene un alto acoplamiento" se convierte en "Si intentas modificar un lugar, se romperá en otros lugares", "Se ha optimizado el rendimiento" se convierte en "Aunque haya un aumento de tráfico, ahora puedo dormir".
Los artículos centrados en la tecnología siempre tienen mucha competencia. Alguien más probablemente lo haya explicado mejor, con más detalle y de manera más rápida. Sin embargo, la situación que has experimentado no se puede replicar. Solo tú puedes hablar sobre en qué contexto encontraste el problema, por qué se necesitó esa elección y cómo esa elección cambió tu vida. Por lo tanto, los artículos tecnológicos traducidos al lenguaje de la vida no se comparan ni se reemplazan.
El branding se completa cuando las personas comienzan a decir: "Siempre me identifico con los escritos de esta persona". Cuando esto sucede, las personas regresan no por la información que proporciona el artículo, sino porque les refleja a sí mismos.
Antes de escribir un artículo, hazte estas preguntas: ¿Cuándo necesitaba esta tecnología? ¿En qué estado me encontraba cuando tomé esa decisión? ¿Cuál fue la diferencia antes y después de implementar esto? Y comienza las oraciones de esta manera: "Lo que más me preocupaba al implementar esto por primera vez era...", "El día que decidí crear esta función fue...", "La razón por la que elegí esta estructura era simple...". Al hacerlo, la tecnología naturalmente retrocede y la historia avanza.
En el próximo artículo, se tratará cómo construir una marca con las historias acumuladas, dónde y cómo acumularlas para que se conviertan en una marca. Hablaremos sobre por qué no es la solución utilizar muchas plataformas, por qué es importante elegir un "hogar" y por qué el branding no es un juego disperso, sino un juego de acumulación. Continuemos en el próximo artículo.