Personalmente, estoy totalmente a favor del #3 como una forma de aprender cualquier cosa y todo lo que tenga que ver con la escritura. Yo también pasé varios años estudiando ingeniería y he hecho mi parte justa de redacción técnica. Si no eres un escritor horrible para empezar, creo que no deberías tener problemas para captar el estilo y la voz de la escritura técnica al leerlo.

Sin embargo, debo señalar que hay un poco más que eso: puedes absorber el estilo simplemente leyéndolo mucho; se te meterá en la cabeza. Pero el contenido no se puede obtener de forma subconsciente, no tan fácilmente de todos modos. Necesitas pensar activamente en lo que estás leyendo. ¿Por qué se colocaron los componentes del informe en el orden en que se colocaron? ¿Qué trató en profundidad el autor y qué pasó por alto? ¿Cómo comenzaron y cómo concluyeron?

Una vez que conozca la voz de la escritura técnica, entender preguntas como estas le dirá qué decir con ella.

Mi experiencia: quería ser programador, ingresé a un programa de matemáticas en la universidad (porque así fue como llegaste a CS), amaba el CS pero odiaba las matemáticas, cambié a escritura técnica y tomó el CS de allí, y terminé haciendo un combinación de programación, redacción técnica y diseño de software para los próximos años .

Las clases y los libros, incluso leer buenos ejemplos, solo lo llevarán hasta cierto punto. Para aprender realmente a hacer redacción técnica, debe escribir y recibir comentarios.. Todavía recuerdo a un desarrollador senior que una vez me dio una conferencia (recién salido de la escuela) sobre el cambio de significado de un "solo" fuera de lugar. Los detalles quisquillosos son importantes, y la mejor manera de crecer es hacer que los quisquillosos revisen su trabajo. Dado que la mayoría de las personas no tienen tiempo para hacer eso por la bondad de sus corazones, debe buscar asignaciones que impliquen escribir: especificaciones de requisitos, documentos de diseño de interfaz, documentos de diseño detallados, quizás historias de usuarios, instrucciones de configuración, etc. . Si puede hacer arreglos para hacer algo de esto como parte de su trabajo, escribiendo la documentación interna necesaria que a sus compañeros de trabajo les importa que tenga razón, aproveche esa oportunidad.

Hacer eso te enseñará a escribir lo que a tus compañeros les gusta leer, pero ¿cómo sabes si es bueno en abstracto? Es por eso que también necesita revisar ejemplos de otros lugares. Preste atención, por ejemplo, a la documentación de la API con la que está trabajando como desarrollador. ¿Qué tiene de bueno? ¿Qué preguntas no responde? ¿Qué dice que te hace decir "duh, dime algo que no sepa ya?" Observa lo que está, lo que no está porque no hace falta, y lo que no está y deja un hueco. Busca patrones. (Por ejemplo, muchos recién llegados a la documentación de la API escriben descripciones de funciones que repiten lo que está en la firma. Ya conoce el tipo de valor de retorno; que significa ¿Cuándo puede ser nulo? ¿Hay códigos de error?)

(Estoy usando ejemplos de programación porque ese es mi campo, pero el mismo proceso se aplica a cualquier área técnica).

Sí, sí, las cosas básicas del inglés también son importantes: gramática, puntuación, consistencia, etc. La precisión importará más que en otros dominios de la escritura. Debe seguir una guía de estilo en aras de la coherencia. Y algunos aspectos de la escritura técnica requieren aprendizaje y práctica específicos, como la indexación. Pero lo que he esbozado en esta respuesta proporciona una buena base.

La clave para una buena redacción técnica no es el estilo. El estilo ayuda con la claridad, y eso es útil, pero no es suficiente. La clave es presentar la información correcta para permitir que un usuario en particular, con un historial y un conjunto de habilidades particulares, complete una tarea. El objetivo es la acción correcta, no necesariamente la comprensión.

Demasiada información es casi tan mala como insuficiente. En el mejor de los casos, ralentiza al lector. En el peor de los casos, socava su confianza. Si no pueden ver la relevancia de la información para su tarea, comienzan a preocuparse de no entender la tarea o la información.

La mejor manera de aprender a ser un buen escritor de tecnología, por lo tanto, es averiguar qué información necesita y qué no necesita la gente. Hay varias formas de hacer esto.

Uno es hacer la tarea usted mismo y anotar cuidadosamente qué información se necesita, especialmente cuando ya sabe algo que su público objetivo puede no saber.

Otra es observar a los usuarios reales, pero esto puede ser costoso.

Una tercera es estudiar foros que cubran productos como el suyo y ver qué tipo de preguntas hacen las personas y qué tipo de información necesitan antes de poder resolver su problema con éxito.

¡Escriba y busque retroalimentación!

Formas útiles de obtener comentarios:

1. Ofrézcase como voluntario para escribir proyectos que serán revisados ​​críticamente. Los revisores suelen ser más atentos y críticos cuando revisan contenido promocional que técnico. Sin embargo, para muchos productos, el contenido promocional debe ser técnico. Como redactor técnico, debe conocer bastante bien los productos de su empresa. Al ofrecerse como voluntario para proyectos que tradicionalmente se consideran "promocionales", puede ayudar a garantizar la precisión y la claridad del contenido promocional, al tiempo que se abre a más y mejores comentarios.
2. Cultive relaciones con revisores que valoran la comunicación clara. Aprecie a los revisores que dan buenas críticas constructivas. Asegúrese de que los revisores comprendan que sus críticas lo convierten en un mejor escritor, lo que se traduce en un mejor contenido y una mejor imagen de marca.
3. Participa en stackexchange. Aunque recién comencé a usar este sitio, ya me di cuenta de que los miembros de la comunidad son excelentes para editar preguntas/respuestas.