Respuesta a una sugerencia de corrección de errores que solo informa errores (no sugiere soluciones). ¿Es esto típico? [cerrado]

No, esto no es habitual. Sin embargo, te has encontrado con una bestia bastante común, el desarrollador elitista con súper títulos. Él es más inteligente que todos los demás en su propia mente y tiene derecho a ser grosero por la misma razón. Tiene un hacha para moler contra Morty. Evítalo cuando sea posible y sigue adelante.

Si bien está en su derecho de querer investigar el problema él mismo, una respuesta civilizada es "Gracias por la sugerencia, lo investigaré". Puede haber mala sangre preexistente entre los dos o él puede ser salvaje, pero en cualquier caso, aunque este comportamiento no es desconocido en tecnología, no es aceptable ni "habitual".

Como desarrollador, encuentro el primer informe muy, muy útil. No hay una explicación larga, no hay un rastro largo de valgrind para leer. Con ese parche, pude ver de inmediato cuál es el problema, y ​​si trabajé en ese código recientemente, probablemente sabría si es la solución correcta o no, incluso sin verificar el código. Así que solo respondería "Gracias por captarlo", o "Gracias, ese puntero no debería compartirse, pero sé cómo debería solucionarse el problema ahora que me lo ha llamado la atención" o algo así.

Tampoco detecto ningún sentimiento de superioridad en el mensaje.

Ahora enviarles CC a todos podría o no ser malo. El código puede ser algo que otros también conocen, por lo que si la lista de destinatarios de CC es lo suficientemente corta, esto es bueno. El correo es lo suficientemente corto, y todo el mundo puede ver inmediatamente desde el parche si debería estar interesado o no, perdiendo solo un poco de tiempo. Sin embargo, si hay personas que no están involucradas con esa base de código fuente en CC, entonces fue inapropiado.

Otro problema es si la persona debería dedicar su tiempo a depurar un problema como este. Sin embargo, a menos que no estén a la altura de sus propios objetivos, asumir la responsabilidad de todo el software como este es generalmente un rasgo muy, muy valioso. Muestra entusiasmo y cariño, cosa realmente rara. Estas cosas pueden ir demasiado lejos, pero es mucho más común ver a compañeros de equipo a los que no les importa un error en el código de otra persona, a menos que los afecte directamente.

Para responder a la pregunta del título. El tono de Morty tal como se presenta en cuestión es, a mi juicio, profesional y normal. El tono de Rick es... desafortunadamente tampoco tan inusual, pero es desafortunado. Sin embargo, todos tenemos días malos, por lo que no analizaré más un solo mensaje anónimo. Podría ser una mala señal (y lo parece, TBH), o podría ser parte de una cultura laboral bastante decente a la que solo debes acostumbrarte.

Sé que la pregunta ya fue respondida y estoy de acuerdo con la respuesta aceptada, pero solo quería ampliar esto con más información.

Lo que has visto aquí es un problema potencial XY . Los problemas XY son, en mi opinión, algo que todo solucionador de problemas (no solo los programadores) debe tener en cuenta y evitar.

El principio de un problema XY es bastante simple:

• X es un problema y necesita ser arreglado.
• Y es una solución, pero no la mejor solución. Independientemente, se elige (ya sea por pereza o por no entender que hay una solución mejor)
• Cuando surge un problema con la implementación de Y, las personas dedican tiempo a intentar que Y funcione, en lugar de buscar realmente que haya una solución Z que se adapte mejor.

Como un claro ejemplo:

• X = Quiero ordenar estos datos de Excel.
• Y = Puedo escribir una aplicación para ordenar los datos y guardar el archivo.
• Z = Debería aprender a usar la funcionalidad de clasificación de Excel.

Esto es esencialmente lo que sucedió en el correo electrónico de Morty. Rick es incapaz de etiquetar la solicitud como Y o Z, porque Morty no explica X. Explicar X es más importante que ofrecer la solución Y/Z, ya que Rick es capaz de encontrar Z cuando conoce X, pero no puede. No adivine X de la nada.

Este es el problema X:

una pérdida de memoria en parte del código de la plataforma

Tenga en cuenta que es bastante vago. ¿Cuál fue el problema? ¿Dónde ocurrió? ¿Cuándo ocurrió? ¿Fue un caso extremo?

Entonces Morty propone una solución Y. Dado que no conocemos los detalles de X, no tenemos forma de evaluar si Y es una solución adecuada para X.

Es por eso que Rick lo rechaza. Se le pide que cambie algo (y que efectivamente asuma la responsabilidad de haber cambiado algo) sin tener otra opción . Morty ha socavado efectivamente la responsabilidad de Rick (escribir un buen código) y la está reemplazando con una solicitud de confianza ciega de que el código ofrecido es apropiado y bueno.

Piénsalo de esta manera: eres un oficial de policía. Un hombre se te acerca y te dice "Necesito que arrestes a ese hombre" (Y).

El oficial de policía no debe obedecer, ya que no puede confirmar personalmente que se justifica arrestar al hombre.

Sin embargo, si el hombre hubiera dicho "ese hombre acaba de matar a alguien a sangre fría", entonces el oficial de policía puede comprender el problema y decidir la solución (arrestar al hombre) por sí mismo.

Esto es básicamente lo que Morty hizo mal. Creo que Rick podría haberlo expresado de manera más amable (si esto fuera Interpersonal.SE, definitivamente reformularía algunas de las oraciones de Rick), pero su solicitud es válida.

Ignorando si existe una tensión subyacente entre los dos, un problema general de comunicación o el tono estándar en su lugar, me concentraré en su pregunta:

¿Este tono es inusual en un lugar de trabajo tecnológico?

No , este tono no es del todo inusual.

1. Las personas en la industria están acostumbradas a los lenguajes de programación sintácticos y las especificaciones técnicas exactas a veces tienden a olvidar el tono en su comunicación. A menudo, esto no es un problema, siempre y cuando los extraños no estén involucrados en la comunicación. Acostúmbrate a muchos mensajes directos al caso.

2. Es un cliché, pero sí, también existen esos nerds que simplemente tienen pocas habilidades sociales, así que es mejor que aprendas a lidiar con ellos y no te lo tomes como algo personal.

3. Para muchos programadores, "su" código es su bebé. Ser señalado con algunos errores innegables es una cosa: jugar con ellos puede desencadenar algunos mecanismos de defensa.

Dicho esto, se puede hacer de una mejor manera. Como regla general, para evitar este tipo de problemas:

• Elogie en público, critique en privado.
• Si tienes problemas con alguien, ¡no uses el correo electrónico para eso!
• Si encuentra un error, infórmelo a través de un mecanismo estándar aceptado por el equipo.
• No hagas el trabajo de otra persona, a menos que te lo pidan.

Hay algo de valor en su sentimiento. Sé de muchas ocasiones en las que mi corazonada sobre una causa raíz llevó a alguien por el camino equivocado y les hizo perder el tiempo.

Con la mayoría de los problemas, cada persona tiene ciertas corazonadas que simplemente se le ocurren. Creo que vale la pena tratar de aprovechar este poder. Cuando necesito ayuda con un error en el que estoy atascado, trato de evitar imponerles mis propias corazonadas, para que quizás las suyas sean novedosas y productivas.

Pero con la forma en que lo expresó... estaba siendo un completo imbécil.

Claramente, no todos están de acuerdo con esto, pero en mi opinión, esta es una respuesta normal, no lo tome como algo personal .

Es un correo electrónico fácil de entender, motiva sus razones por las que prefiere no escuchar su solución (no porque sea su solución, sino porque quiere una pizarra en blanco para empezar).

No es personal hacia ti, ni insultante, ni denigrante en absoluto, es una explicación. Es un poco directo para algunas personas, pero eso es a menudo un capricho de los programadores, siendo directo y (demasiado) objetivo. Puede leer todo este correo electrónico en un tono de voz normal, donde explica su método preferido. El hecho de que no seas un fanático de él no significa que sea una mala práctica, te encontrarás con muchas personas que trabajarán de manera diferente a ti.

Estoy de acuerdo en que podría expresarse un poco más cortésmente, pero nuevamente, un programador a menudo solo dice lo que quiere decir sin todas estas interpretaciones cargadas (lo cual no es una excusa, pero podría ser una explicación).

Es su trabajo arreglar los problemas, no el tuyo. Acabas de pasar tiempo en algo que podría haberse usado de otra manera. No me malinterpreten, ¡practicar la corrección de errores es importante! Pero estudie la solución aplicada y compárela con la suya. Su solución puede parecer buena, pero la experiencia puede enseñarle lo contrario.

Ambos lados tienen la culpa aquí.

Morty no debería haber enviado copia a todos en el correo electrónico inicial. Al hacerlo, avergonzó a Rick al señalar su error a todos. No sé si Morty estaba tratando de sumar puntos al hacer esto o si simplemente fue un tonto. Sin embargo, el resultado fue el mismo desde el punto de vista de Ricks. Hubiera sido mejor que Morty enviara este correo electrónico solo a Rick para que pudieran solucionar el problema sin que nadie tuviera que quedar mal.

Rick, avergonzado de que se le señalara su error públicamente, reaccionó mal. No debería haber menospreciado a Morty. No debería haber criticado públicamente a Morty por intentar ayudar.

Un ejemplo de un intercambio de correo electrónico no nos dice nada sobre la cultura de una empresa. Sin embargo, si enviar correos electrónicos públicos señalando los errores de otras personas y enviar correos electrónicos diciéndoles a las personas que no deberían ofrecer ayuda son comunes, entonces tienes una cultura tóxica.

Desafortunadamente, este tipo de cultura tóxica es común en las empresas de software de los Estados Unidos. Mucho se ha escrito [1] [2] [3] y se ha dicho sobre la forma en que un tipo particular de ingenieros de software trata a los demás, especialmente a los que no son ingenieros de software y a las personas que no encajan en su estereotipo de ingeniero de software.

Esta cultura no es la forma correcta de tratar a las personas. Las buenas empresas, los jefes y los compañeros de trabajo no toleran este tipo de cultura. Los buenos empleados no se señalan públicamente los errores de los demás y los buenos empleados no descartan la ayuda de los demás.

Debe darse cuenta de que este comportamiento es aceptable en la cultura de su departamento y empresa. Si crees que estás en una empresa en la que esto es aceptado, debes decidir si crees que puedes cambiar la cultura y si vale la pena el esfuerzo. Una cosa importante a determinar es si esta cultura proviene del liderazgo o no. Si el liderazgo da un mal ejemplo, no habrá nada que puedas hacer. Si esta es la cultura de base, tienes alguna posibilidad de convencer a la gente para que cambie. Será un trabajo largo y duro, así que será mejor que decidas que vale la pena arreglar la empresa.

Lo normal es bastante subjetivo, especialmente porque no tienes ni idea de la historia de ese lugar de trabajo.

O Rick tiene terribles habilidades interpersonales o hay algo de mala sangre entre esas dos personas.

Es posible que Morty haya creado a propósito un correo electrónico "razonable" con la esperanza de provocar a Rick.

Como eres nuevo, deberás evaluar si este comportamiento tóxico también se ha extendido a otros o si se trata de una situación contenida.

Pase lo que pase, simplemente no dejes que se extienda a tu personalidad.

Estoy escribiendo esto con la perspectiva de un gerente con experiencia que cubre múltiples aspectos de este tipo de escenario.

¿Es esto normal en las empresas de tecnología?

Esto es completamente normal para cualquier empresa en prácticamente todas las industrias, no solo en tecnología.

En términos generales, el correo electrónico que se envió a todos los miembros de un equipo de desarrollo que:

• señaló una falla sospechosa (" Creo que encontré una pérdida de memoria...")
• declaró que se había encontrado una supuesta solución (" Creo que encontré la fuente y el problema...")
• presentó una larga lista de correcciones que se implementarán

Para generalizar esto, lo que está sucediendo aquí es que Morty le está dando una directiva a Rick que establece una justificación de la directiva primero y luego detalla los detalles de dicha directiva.

Complica aún más el asunto en el sentido de que la directiva se dio en un entorno grupal (cc'd a todos los miembros del equipo).

La relación organizacional de Rick y Morty

No sabemos la relación con respecto a los dos individuos. Sin embargo, generalmente se puede resumir como una de tres posibilidades:

• Rick es mayor que Morty.
• Morty es mayor que Rick.
• Rick y Morty son iguales

¿Se supone que Rick debe tomar la directiva de Morty?

• ¿No? Entonces Rick está justificado en retroceder.
• ¿Sí? Entonces no hay necesidad de hacer CC a todos. Rick todavía está justificado para decirle a Morty cómo realiza mejor su trabajo.

Esta situación no sería diferente si lo fuera....

• Médico. El Dr. Oz le dice al Dr. No que ha diagnosticado al paciente del Dr. No y que haga X, Y y Z sin proporcionarle los síntomas al Dr. No.
• Automotor. El ingeniero 1 le dice al ingeniero 2 que se encontró un problema en el diseño de la suspensión del ingeniero 2 y que la solución es soldar la lengüeta A a la ranura B sin proporcionar los datos de prueba para mostrar el problema.
• Soporte técnico: Tech 1 le dice a Tech 2 que hay un problema con el sistema de Tech 2 y que la solución es implementar los parches A, B y C sin proporcionar los mensajes de error que indicaron el problema.

TL;RD

En pocas palabras, la persona responsable de hacer la reparación real le dice a la persona lo que necesita para hacer el trabajo correctamente. La única persona que está potencialmente "fuera de lugar" es Morty por el comportamiento pasivo agresivo de hacer cc'ing a todos.

Esto sucede todos los días en todas las industrias. No es nada nuevo o inusual.

--- a/spaceship/DoBattle.cpp  
+++ b/spaceship/DoBattle.cpp  
 vector<part> parts = getSpaceShipParts();  
+shared_ptr<SpaceShip> p = new SpaceShip(parts);  
-SpaceShip * p = new SpaceShip(parts);  
 engageInBattle(p, enemy); 

Desafortunadamente, este cambio soluciona el error (pretender que la prueba valgrind es adecuada), pero introdujo algo no deseado, una pelea de filosofía del código. Si no es un colaborador habitual, no se meta en peleas de filosofía del código.

Para evitar la pelea de filosofía, esto debería haber sido enviado en su lugar. Sí, es objetivamente peor, pero está en consonancia con el estilo del código que ya existe:

--- a/spaceship/DoBattle.cpp  
+++ b/spaceship/DoBattle.cpp  
 SpaceShip * p = new SpaceShip(parts);  
 engageInBattle(p, enemy); 
+delete p;

Pero con esta respuesta del desarrollador, supongo que tampoco le habría gustado. Escucho demasiado este tono, incluso de personas que deberían saberlo mejor. No es normal, pero es suficiente que lo escuches mucho. Estoy decepcionado.

1) Comunicación: OP hace que parezca que es una práctica estándar enviar CC al resto del equipo de desarrollo. Nunca veo una razón para no incluir al resto del equipo de desarrollo en un problema/solución que afecta a todos.

2) Problema/Solución: No veo nada malo aquí. Debería hacerse con una solicitud de extracción, pero suponiendo que eso no sea posible aquí, está bien.

3) Respuesta: Hay tantas cosas mal que no sé ni por dónde empezar.
a) 'No leo las correcciones sugeridas': Esto es absolutamente terrible. Lea siempre el código propuesto. Hay una posibilidad decente de que sea mejor que cualquier cosa que se te ocurra...
b) 'Tengo que esperar unos días antes de poder encontrar una solución': Permítanme traducir eso: "Tengo que esperar unos días antes de que pueda ignorar por completo el trabajo que hiciste y descartar tu solución. No solo perderé tiempo para implementar una solución, sino que también perderé más tiempo para encontrar una solución para un problema que ya se resolvió (por el código que escribió que descartaré)"
c) 'vea cuál es el verdadero problema y vea cuál debería ser la solución': pruébelo. Pruébalo para ver si hay algún problema. Luego pruébelo para ver si el problema se resolvió. No gana nada al idear su propia solución que debe probarse en lugar de probar la solución propuesta para ver si soluciona todo. Si no soluciona el problema , puede intentar encontrar una solución para la solución propuesta o una solución para el problema por completo.

En mi empresa, habría enviado la respuesta a mi gerente de inmediato y sin comentarios. Es simplemente inaceptable.