Comuniquémonos eficazmente electrónicamente en el trabajo / Sudo Null IT News

Me pareció que las recomendaciones y reglas que se describen a continuación siempre fueron obvias y lógicas para los empleados de las empresas de TI. Pero la práctica deprimente muestra que hay muchas personas que no pensaron ni miraron desde fuera cómo se comunican con sus colegas. Después de todo, con un poco de esfuerzo, puedes mejorar significativamente la efectividad de la interacción con ellos. Los desarrolladores experimentados ya saben todo esto, pero a menudo no lo saben los jóvenes que no han visto ningún otro medio de comunicación que no sea la mensajería instantánea en tiempo real. Y el cambio forzado al trabajo remoto durante la COVID demostró cómo pocas personas (¡empresas enteras!) pueden trabajar de manera efectiva sin comunicación cara a cara.

Me parece que lo primero que más irrita en la comunicación online es el único “hola” enviado.

(13:01) Он: Привет!

Recibes una notificación de que alguien ha escrito. Cambias al terminal con el cliente de mensajería instantánea y respondes:

(13:01) Вы: Привет!

En este momento no pasa nada en el chat, ya que un colega escribe y formula una pregunta. Ya estás distraído. ¿Volverás a la terminal donde estabas haciendo tu trabajo como si nada? ¡No importa cómo sea! Ahora su cabeza está ocupada con la pregunta “¿qué podría necesitar este colega de mí?” Recuerda exactamente qué programas y bibliotecas tocó por última vez y tal vez hizo algo en los servidores. Su cabeza está llena de anticipación a la pregunta que le podrían hacer.

(13:04:20) Он: Я сделал вот такую штуку вот так-то. Нормально?
(13:04:30) Вы: Да, хорошо.

Como resultado, ha perdido por completo varios minutos y, además, al pensar en los motivos del “hola”, ya ha cambiado el contexto de atención de su trabajo. ¿Pero sólo unos minutos? Irritación debido a objetivamente el tiempo perdido y el hecho de que hayas desperdiciado energía en anticipar la pregunta, te sacan de la rutina del trabajo por inercia por un tiempo más. Dicen que el cambio de contexto nunca dura menos de 15 minutos.

¿Cuál es el punto y por qué escribir “hola”? De todos modos escribirás un mensaje de seguimiento, así que ¿por qué interrumpir prematuramente a tu colega? Si tu “Hola. Lo hice… ¿Está bien? estaba en un mensaje, entonces el colega no necesita adivinar qué pregunta le harán, inmediatamente puede gastar su poder cerebral solo en procesar esta pregunta, estos 10 segundos, sin irritación por los minutos perdidos y el cambio forzado de contexto.

Alguien escribe “Hola. ¿Puedo hacer una pregunta?” Esto es igual de repugnante. Esta es la probabilidad de que su compañero de trabajo responda: “Hola. No, no puedes”? Lo más probable es que no sea alto. Es decir, es casi seguro que aún tendrás que escribir y hacer tu pregunta. Entonces, ¿por qué no enviarlo de inmediato? Si un colega realmente no puede responder, bueno, eso sucede.

Algunos pueden sentir que sin recibir un “sí, puedes preguntar” afirmativo, sería de mala educación preguntar de todos modos. Alguien probablemente podría incluso escribirlo con anticipación para que cuando reciba “sí, puedes”, pueda enviarlo inmediatamente para ahorrar tiempo. Sólo esto:

(16:00) Он: Привет. Можно вопрос?
    а вы не вернулись с совещания
(17:00) Вы: Привет. Да, можно.
    теперь уже он ушёл на обед/совещание/покурить/по нужде
(18:00) Он: Вот такой-то вопрос: ...
    вы же уже ушли домой, конец рабочего дня

Como resultado, condujeron de vacío en vacío y nunca recibiste la pregunta, aunque ya podrías haberlo pensado y no perder el tiempo a la mañana siguiente dando una respuesta.

¡Los chats/IM son una forma asincrónica de comunicarse! Sí, por definición son en tiempo real, pero nadie te impide cambiar a otra terminal/ventana o alejarte de tu lugar de trabajo. Una llamada telefónica es sincrónica: si su interlocutor contesta el teléfono, créanme, esto probablemente interrumpió su actividad y estará completamente involucrado en la conversación con usted con demoras mínimas entre la pregunta y la respuesta, ya que no hay adónde ir. fue interrumpido de todos modos. Por lo tanto, no es necesario hacer de la mensajería instantánea un medio de comunicación sincrónica, lo que implica que el interlocutor esté constantemente frente a la pantalla del chat, concentrado únicamente en leer su pregunta.

Un extremo separado podría ser:

Он: Привет.
Вы: Привет.
Он: Как дела?
Вы: Потихоньку.
Он: Можно задать вопрос?

donde entre cada pregunta/respuesta hay retrasos notables con el cambio de contexto.

No preguntes “¿puedo preguntar?”, ¡solo pregunta! Evalúe la probabilidad de que su pregunta sea rechazada (normalmente insignificante) y cuánto tiempo se ahorraría tanto a usted como a su colega.

Observo que los desarrolladores experimentados no cometen tales errores. Esto se ha dicho muchas veces: aquí, aquí, aquí, aquí, aquí, aquí.

Un tema aparte es la incapacidad de hacer preguntas competentes. No se trata del filosófico “una pregunta bien planteada ya contiene parte de la respuesta”, sino de lo siguiente:

Он: Привет. У меня не работает программа XXX.
Вы: Привет. Почему ты так решил?
Он: Она не выводит корректный результат для такой-то задачи.
Вы: Почему тебе кажется что он не правильный?
Он: Я ввожу вот так, ожидаю вот так.
Вы: А какие опции ты передал при запуске XXX?
Он: Вот такие.
Вы: Ты проверил права доступа на файл с результатами?
Он: Да, ls -l: ...
(...)

Esta es una locura de ineficiencia del tiempo. Si las respuestas a todas las preguntas planteadas ya están disponibles a priori, ¿por qué no proporcionarlas de inmediato? “Hola. Introduzco esos datos en XXX, con tales y tales argumentos, y espero recibir ese resultado. Pero él no está ahí. Comprobé que todo está bien con los derechos, hay espacio libre, … “. Aún tendrás que escribir todas estas respuestas (!), así como confirmar con soporte técnico que has verificado que hay electricidad y que el cable de alimentación está conectado a tu equipo. Pero la comunicación con el soporte técnico es, nuevamente, un proceso sincrónico por teléfono, en lugar de hacerlo electrónicamente con su colega.

Si surgen problemas de red, ¿qué enviamos siempre a los administradores para averiguar los motivos? ping, traceroute, netstat, tcpdump, etc… Lo cual parece obvio para todos. Entonces, ¿por qué no enumerar todas las medidas adoptadas y describir sus expectativas en detalle? ¿Cuál es la probabilidad de que todos los tcpdumps adjuntos le respondan “solo estábamos jugando con la red, nada funcionó”? Bueno, perderá un poco de tiempo en el diagnóstico; la probabilidad de que esto suceda no es alta. Si, sin previo aviso, sus administradores a menudo interrumpen las redes y los servidores, entonces el problema aquí es mucho más grave que si las preguntas son correctas.

Hay un articulo maravilloso. cómo hacer preguntas correctamente (originales en ingles) por Eric Raymond (ESR). Personalmente, no estoy muy de acuerdo con la propuesta de buscar primero la respuesta a una pregunta en Google, ya que después de recibir algún tipo de receta, una persona ni siquiera entenderá o pensará en cuál era la esencia del problema. Lo mismo se aplica a Stack Exchange, del que toman a ciegas recetas preparadas sin pensar.

En lo alto de mi lista de prioridades estaría la documentación del programa. Lo admito, a veces no existe, o no tiene nada de significativo, o tiene un tamaño enorme, o simplemente está escrito de forma pésima y incomprensible. Pero como programador, me molesta que básicamente no se lea, como si fuera un electrodoméstico trivial más con un solo botón de encendido/apagado. ¿Para quién y por qué escribimos documentación? ¿Quizás para que no nos hagan preguntas para las que ya se han dado todas las respuestas? ¿Dónde, a veces, ya se tienen en cuenta configuraciones/características especiales que requieren atención y que podrían hacer que uno tropiece?

Me gustó la recomendación de no decir “encontré un error en el programa” a menos que haya absoluta certeza al respecto (en el buen sentido, y un parche). Si la mayoría de los usuarios tuvieran un problema, probablemente lo sabrían. De lo contrario, lo más probable es que estés haciendo algo mal. Si afirma que encontró un error, entonces está diciendo que los desarrolladores hicieron algo mal, lo cual probablemente no les guste. Personalmente, según mi experiencia, en la gran mayoría de los casos el usuario se equivoca. La discrepancia entre sus expectativas y lo que dice el programa no significa que sea incorrecto o tenga algún error.

Describe los síntomas del problema, no tus suposiciones. Describe el objetivo final, no los pasos. Cuando empezamos a trabajar con desarrolladores menos experimentados, cuando había una brecha notable en la experiencia entre colegas, lo primero que siempre teníamos que preguntar era “¿qué es exactamente lo que quieres conseguir/hacer?”. Muy a menudo, un colega novato elige un camino espinoso para alcanzar este objetivo. A menudo no es necesario tomar ninguna medida cuando surge el problema.

Si el problema/pregunta ya no es relevante, ¡infórmalo! Escribe una breve solución. Imagínese qué sentimientos negativos tendrá una persona que, después de leer la pregunta, se devanó los sesos, escribió sobre una posible solución y le dijeron “pero esto ya no es necesario, lo olvidé, resulta que olvidé la opción”. Esto equivale a “No me importa tu tiempo (el tuyo, si se trata de una pregunta grupal), ni siquiera recuerdo que te lo pregunté”.

I más Un enlace útil sobre este tema al que vale la pena enviar a sus colegas.

El misterio sigue siendo: por qué la gente envía una captura de pantalla del código fuente (o el resultado de un comando Shell) como captura de pantalla. ¿Existen realmente editores de texto o emuladores de terminal que no te permiten copiar un fragmento de texto de ellos?

No puede copiar texto de una imagen y pegarlo en su editor/lo que sea que desee verificar. Aún así lo pedirás o lo enviarás por mensaje de texto o simplemente no te molestarás. ¿Por qué no volver a escribirlo todo manualmente? Por supuesto, no estamos hablando de problemas de diseño o de visualización torpe de los programas de la consola, donde las capturas de pantalla son realmente necesarias.

Las preferencias de las personas varían mucho. Lo que puede parecer cómodo y agradable para una persona puede resultar difícil de percibir para otra. Las fuentes son una mierda, los colores son deslumbrantes y todo eso. Y es posible que algunos tengan un monitor HiDPI, pero otros no. ¿Por qué dificultar que un colega comprenda la información?

¿Y sabes lo molesto que puede ser un retraso perceptible para una persona? Una vez me vi obligado a desactivar la visualización de la rama VCS actual en la línea de comando, ya que podría crear un retraso visible en las computadoras con discos duros. Esto probablemente sea difícil de entender para los usuarios de teléfonos inteligentes, ya que, por lo que vi por encima del hombro, cada acción tiene un retraso, no hay reacciones instantáneas de los programas. Es casi seguro que descargar y decodificar un archivo JPEG/PNG de varios megabytes supone un retraso notable, incluso en ordenadores modernos y potentes.

Muchas personas no comprenden en absoluto las características de los formatos de compresión de imágenes y aún así logran enviarlas en compresión con pérdida basada en DCT, como JPEG, WebP. Aparentemente, para que probablemente tengas caracteres “il1”, debido a artefactos de compresión, se volverían indistinguibles y tendrías que jugar un juego de adivinanzas.

Y aún más gente no piensa en el volumen de información. En una de las listas de correo, vi recientemente a una persona enviar una foto de un monitor con 10 líneas de información útil. La foto ocupaba varios megabytes debido a la monstruosa resolución. Se le notó que ella sola generaba 19 GB de tráfico saliente desde sus servidores de correo. Si estuviera conectado a través de un canal de comunicación de 100 Mbps, entonces sería mucho tiempo enviar apenas 10 líneas de información útil.

Los canales de comunicación son el mismo recurso compartido que las redes de agua y electricidad. Nadie prohíbe claramente abrir todas las válvulas del baño y dejar que el agua corra y fluya. En nuestro país no es nada caro. Pero imagínese si todos en un edificio de varios pisos hicieran esto: esencialmente las tuberías se volverían inútiles. Las redes troncales de Internet no son diferentes aquí.

Además, para no ser infundado, mientras escribo este texto, fotografié mi monitor de 27″ con una vieja cámara digital de apuntar y disparar, donde hay dos mitades con texto en la pantalla. Cambiando el tamaño a 640×480 píxeles, puedo ver y comprender fácilmente cada carácter que contiene. Al comprimirlo en un alucinante JPEG XL con compresión con pérdida “-d 2”, obtengo un archivo de ~60 KB en el que no hay artefactos que interfieran con la percepción. que incluso hasta 100 KB, con un formato de imagen moderno, casi todo se puede transmitir perfectamente en una fotografía.

¡Finalmente, activa la revisión ortográfica en tu editor! Aunque, como usted sabe, solo hay dos editores: Emacs o Vim, ambos contienen herramientas de verificación integradas.

No estamos hablando de chat en tiempo real, sino de correo, que probablemente se escribe en el editor, y del código fuente con la documentación del programa. ¿Qué significan los errores tipográficos y la mala ortografía? Descuido, abandono o pereza para incluir el “hechizo fijado”. No todas las personas saben escribir correctamente o incluso notan errores; esto es normal, es un hecho. Pero es por eso que nuestras computadoras cuentan con herramientas que nos permiten al menos corregir la ortografía. La comunicación en tiempo real es una cosa, donde una alta velocidad de transferencia de datos es importante, aunque con errores y errores tipográficos. Otra cosa es el correo o el código con documentación, donde no hay prisas como “¡comprometerse más rápido tal como está y salir de aquí!”.

¿Cómo es leer texto (no mensajería instantánea) con errores? Es como conducir a gran velocidad por una carretera con grandes baches y baches, de la misma manera que el ojo detecta errores, lo que ralentiza drásticamente el ritmo de lectura. Varias de estas pistas y simplemente le resultará fisiológicamente desagradable leer el material que tiene delante. Debido a que estaba escrito “al diablo”, la persona era demasiado vaga para dedicar unos minutos a editar algo que un corrector ortográfico le habría resaltado claramente. Es posible que al propio autor no le importe la alfabetización, pero otros leerán su código, lo cual no debe olvidar. Y este es un trabajo descuidado, desatento y descuidado: esta es exactamente la impresión que creará.

Y personalmente, sólo me refiero a errores tipográficos y ortográficos obvios. No soy tan exigente con las terminaciones de palabras inconsistentes (las palabras tienen una ortografía correcta individualmente, pero no juntas) porque sé por mis propios textos cómo, después de numerosas refactorizaciones de texto, esta falta de coincidencia ocurre fácilmente. Además, el corrector ortográfico no te ayudará con las comas.

Lo mismo se aplica al diseño de un mensaje de confirmación en los sistemas de control de versiones. Pero se han escrito tantos artículos sobre esto que no me repetiré, solo les recordaré nuevamente la ortografía.

Recuerde que el código y la documentación se escriben una vez, pero son leídos, a menudo por diferentes personas, muchas veces.

Me he encontrado con esto sólo unas pocas veces en mi vida, pero no todo el mundo puede imaginarlo: hay personas que continúan mirándote, tu teclado, tu monitor mientras escribes una frase de contraseña (contraseña en el peor de los casos).

Ya que estamos hablando de etiqueta, netiqueta, espiar a alguien que escribe contraseñas es un comportamiento inaceptable. Esta es una acción íntima que afecta directamente a la seguridad y la privacidad. Casi todos los colegas que conozco reflexivamente, sin preguntas ni solicitudes, simplemente se alejan si alguien ingresa una contraseña, incluso si es conocida.

Nadie ha podido nunca mostrarme argumentos o ejemplos convincentes de que cualquier medio de comunicación pueda compararse con la conveniencia y el poder del correo electrónico. Estamos hablando de discusiones y debates, no de cuestiones operativas.

El único problema con la impopularidad de las soluciones de correo electrónico es que para utilizar el correo electrónico de forma eficaz se necesita una herramienta eficaz y adecuada. Es decir, un buen agente de usuario de correo. Sin verlo y sin intentar utilizarlo, el correo electrónico no tendrá sentido ni comodidad. A lo largo de ~20 años de actividad profesional, si alguna vez he conocido a personas que no entendían por qué se necesitaba el correo, nunca habían tenido discusiones técnicas serias por vía electrónica.

A diferencia de la gran cantidad de otros medios de comunicación que nos imponen las corporaciones, existe una enorme cantidad de programas de correo electrónico para todos los gustos y colores. No estoy limitado por el software del servidor en mi capacidad de buscar entre letras como a mí como quieras. Quiero indexar todo a través del sistema basado en Xapian; lo hago. Quiero automatizar los procesos de toma de decisiones, filtrado, priorización y distribución de la correspondencia entrante con scripts Perl. Lo quiero. El ecosistema del correo electrónico (especialmente el corporativo) no depende de los caprichos de las empresas individuales. El correo electrónico no requiere una conexión permanente en línea; toda la correspondencia puede estar a mano.

Hay algunos buenos consejos sobre netiqueta en RFC 1855. Pero destacaré sólo algunos que son particularmente críticos.

Indique una línea de asunto razonable y apropiada para su carta. Mi sistema de correo electrónico está configurado para no aceptar mensajes sin ninguna línea de asunto. No tiene sentido comunicarse con una persona si no puede dedicar 10 segundos a escribir una línea de asunto sensata. “Hola”, “Pregunta”, “Necesito ayuda”: esto es lo mismo que no tener un tema.

Después de todo, basta con imaginar que cinco o diez personas te escribieron con un tema similar. Y no son diferentes entre sí. Un desastre, basura, una pérdida de tiempo. Con el tiempo, por lo que veo, las personas experimentadas simplemente comienzan a colocar silenciosamente esas letras inmediatamente en /dev/null sin leerlas. Escribir un tema adecuado es incluso más rápido que activar el corrector ortográfico en el editor. Y la ausencia de esta acción equivale a una total falta de respeto por su tiempo.

Cada letra tiene un identificador único (ID de mensaje). Al responder a una carta, se agrega claramente un encabezado (In-Reply-To) que indica que esta carta es una respuesta a algo que está claramente especificado y definido. Esta es la única forma (si te olvidas del encabezado Referencias) de unir letras en cadenas.

De la siguiente manera: si desea iniciar un tema completamente nuevo, una nueva discusión, entonces no es necesario que lo haga respondiendo a alguna carta anterior, ya que de forma predeterminada estarán conectados. O no olvide eliminar el encabezado En respuesta a después de esto. ¿Por qué es esto malo? El hecho de que su MUA mostrará esta carta como parte de alguna cadena de discusión del “programa XXX”, aunque ya no tiene nada que ver. ¿Cuál es la relación entre ellos? Ninguno, dices, incluso se indican diferentes temas. Sin embargo, sus MUA tienen una opinión diferente. Además, existe la posibilidad de que su carta sea ignorada. Si los colegas están discutiendo algún tema sobre XXX y no me interesa en absoluto, entonces no se considerarán todas las ramas de este hilo.

También ocurre el problema opuesto: una persona es demasiado vaga para “adjuntar” un mensaje a un hilo de discusión. Es demasiado vago para encontrar una cadena vieja para responder o configurar In-Reply-To con las manos. Por lo tanto, todos los destinatarios deberán realizar manualmente la operación de vincular la carta al hilo de discusión en su MUA. O una persona lo hará una vez o lo hará muchas, muchas veces. La elección, si piensas en tus compañeros, es obvia.

No pregunte “por favor envíe una respuesta a tal o cual dirección”, simplemente configure el encabezado “Responder a”/”Responder por correo a”. Si eres demasiado vago para dedicar unos segundos a hacer esto, ¿por qué los destinatarios y los respondedores deberían soportarlo?

Algunas soluciones de correo electrónico, como Gmail, han eliminado por completo la posibilidad de tener discusiones en forma de árbol, lo que hace que las discusiones por correo electrónico sean casi inútiles. Estas soluciones agrupan los correos electrónicos según los cambios en las líneas de asunto del correo electrónico, ignorando los encabezados. No debes utilizar herramientas maliciosas.

El próximo flagelo del correo electrónico es el exceso de citas de correos electrónicos. Por defecto, al responder a una carta, se sustituye completamente por una cita para que podamos dejar sólo las secciones necesarias del texto a las que damos nuestros comentarios/respuestas/sugerencias. Después de todo, sólo nosotros, las personas, podemos decir exactamente qué queremos comentar/discutir. ¿Por qué carajo dejar todo lo demás que no esté relacionado con la carga de información útil de la carta?

>Привет!
>
>Завтра такого-то-числа мы пойдём туда-сюда.
>Абзац текста
>
>Собираемся взять то да сё.
>Много пояснений и деталей.
>
>-- 
>Моя подпись

Привет. Я буду в отпуске в эти дни.

¿Cuál es el punto de dejar un saludo en la cita? ¿Firma? ¿Un párrafo de texto, detalles? Estrictamente hablando, nuestra carta de respuesta ya contendrá el “In-Resply-To: Message-ID” del mensaje al que estamos respondiendo, por lo que la cita en su conjunto es innecesaria. Pero para mostrar claramente el contexto de la respuesta, que estamos respondiendo a una sección consciente específica del texto, podemos dejar una sola línea importante y significativa de la cita:

>Завтра такого-то-числа (...)

Я буду в отпуске в эти дни.

Mucha gente me dirá: ¿te da pena el tráfico o el espacio en disco? Responderé:

Tú

Me envió este conjunto de información, esta cita: es la carga útil de su mensaje.

A mí

tienes que leerlo, analizarlo, interpretarlo y analizarlo todo. Para, en última instancia, comprender que casi toda la carga útil no es ni un ápice útil. ¿Pero por qué me obligas a hacer este trabajo? Publique una tonelada de texto legible por humanos, donde no haya ni una pizca de información útil, excepto una sola línea de respuesta/comentario/sugerencia y, posiblemente, el contexto con el que se relaciona.

Los tamaños de encabezado pueden ocupar decenas de kilobytes, pero están diseñados para el procesamiento automático. El texto del mensaje es para personas. Entonces, ¿por qué aumenta la carga cognitiva al procesar un mensaje de este tipo? ¿Agregas (dejas) más basura intencionalmente? Configure su editor MUA para recortar automáticamente saludos y firmas, que no son necesarios en el 99,99% de los casos. Esto también le ahorrará tiempo.

A veces dan el siguiente argumento: si necesito reenviar una carta (o una correspondencia completa de varias) a otra persona, me veré obligado a citarla completa. Este es sólo un caso clásico de una persona que da pasos absolutamente equivocados hacia su objetivo. Si necesita reenviar una carta, ¡reenvíela! En forma de archivo adjunto RFC822, que guardará completamente la carta (o cadena) enviada sin cambios, sin pérdida de encabezados con Message-ID+In-Reply-To, sin pérdida de firmas criptográficas. Pero incluso si insertas el mensaje reenviado como un fragmento de texto, todavía no es una cita.

Y un horror más de los días de las versiones con fallas de Microsoft Outlook:

* Пожалуйста, да.
* Должен ли я избегать top-posting в этом списке рассылке?
* Потому-что из-за обратной последовательности беседы, читатель остаётся
  без контекста темы и это заставляет его читать сообщения в
  неестественном порядке.
* Почему top-posting так нервирует?
* Это практика размещения ответа на сообщение до самого цитируемого
  сообщения, вместо размещения его после (обрезанного до только нужных
  частей) сообщения.
* Что такое top-posting?

¿Parece una locura? ¿Como si el autor de este texto se hubiera pervertido deliberadamente y hubiera decidido mostrar las respuestas en orden cronológico inverso? Bueno, ¿complicar la comprensión y percepción de lo escrito? Esto es cierto. Y esto es exactamente lo que hace la publicación superior, que surgió debido a un error en un popular programa de correo electrónico de baja calidad. Y un pequeño número de otros MUA decidieron implementar la compatibilidad con errores como un loro.

A: Да.
Q: Ты уверен?
A: Потому что он переворачивает логический поток обсуждения.
Q: Почему так не любят top-posting?

Habiendo suscrito a cientos de listas de correo de discusión técnica durante más de 20 años, en casi todas partes uno es duramente castigado por su uso, porque destruye la oportunidad de discusión, convirtiendo el texto en un lío de fragmentos de información no relacionados. Después de 1 o 2 advertencias, la mayoría simplemente no responderá a tales cartas, porque esto es una completa falta de respeto hacia las personas al otro lado del MUA. Las calificaciones del desarrollador y su capacidad potencial para llevar a cabo discusiones técnicas (no verbalmente) casi siempre se pueden evaluar a través de sus cartas: si hay publicaciones destacadas allí, si se eliminan citas innecesarias, como mínimo.

Personalmente, todo esto me parece aún más tremendamente ilógico, porque cuando todavía era un colegial estaba en la red FidoNet (entonces no había Internet), donde el popular editor de mensajes GoldED no me permitía enviar cartas si el tamaño del texto citado superó algo así como una cuarta parte del volumen total del mensaje. Incluso, esta era una medida necesaria, ya que de lo contrario los módems simplemente no habrían podido bombear volúmenes de información entre nodos. Pero esto hizo posible llevar a cabo discusiones de manera clara, clara, concisa y más efectiva, hacer preguntas, hacer sugerencias, sin mucha basura de información y carga cognitiva inútil.

No digo nada sobre la (in)capacidad de utilizar el encabezado “Seguimiento de correo electrónico a”. Guardo silencio sobre el (inadmisible) uso de HTML en las cartas. Y muchas otras cosas. Porque los problemas son mayores, mucho más graves.

Intenta ponerte en el lugar de tu interlocutor y evalúa si tu método/protocolo de interacción es agradable y adecuado. Una buena eficiencia de las comunicaciones electrónicas en un equipo de TI es la clave para un trabajo eficiente y no inactivo donde, de otro modo, habría descansos y esperas regulares para reuniones en vivo.