Soy un estudiante de posgrado en ingeniería cuyo trabajo incluye mucha programación e implementación de las teorías desarrolladas. No soy un científico informático, pero soy un programador bastante hábil, al menos en comparación con otras personas en el campo.
En los últimos meses fui a algunas conferencias y reuniones con socios que participan en mi proyecto de investigación. En la mayoría de los casos, mi supervisor también asiste a estos eventos. No tenemos los mismos antecedentes, y si bien recibo mucho apoyo de él, hay algunos vacíos en los que no es competente y no tiene una buena visión general, especialmente sobre la cantidad de trabajo necesario para implementar algo. En tales tareas tenemos una relación que se basa en la confianza de que estoy haciendo un trabajo correcto, que se interrumpe cuando otros investigadores están involucrados, como se describe a continuación.
En tales eventos me he encontrado con el problema de que algunas personas preguntan audazmente por qué no investigué o desarrollé una característica particular (generalmente irrelevante), y dan sugerencias para la extensión del trabajo que están mucho más allá del alcance de mi proyecto y tiempo. Este es especialmente el caso de la programación, y proviene de personas que nunca han implementado nada. Para algunas de las sugerencias, necesitaría mi propio equipo de investigación y algunos años de financiación. Y, a veces, las personas que hacen esas preguntas tratan de presumir frente a los demás al trivializar mi investigación. Esto es molesto. Y esta situación empeora cuando doy una presentación simplificada de mi trabajo para que sea más comprensible para un público más amplio. En las conferencias veo que otros jóvenes investigadores experimentan el mismo problema. De hecho, soy un investigador joven y puede parecer que estoy sobreestimando mi trabajo, pero tengo una buena visión general del campo y no tengo problemas con las sugerencias que requieren una cantidad adicional pero razonable de trabajo. Hasta ahora, todos mis trabajos obtuvieron buenas críticas, y en mi departamento soy uno de los estudiantes de posgrado más productivos, lo que me da confianza de que estoy en el camino correcto y hago más que suficiente trabajo.
Si bien tiendo a ignorar tales demandas, esto me coloca en una posición difícil cuando se trata de un tema en el que mi supervisor no tiene experiencia. Mi supervisor tiene la impresión equivocada de que no estoy haciendo un trabajo correcto y que mi trabajo es básico y toca solo la punta del iceberg. Otras personas en la audiencia instantáneamente también obtienen esa opinión. Esto se intensificó hoy cuando recibí una muy buena revisión de un trabajo que le envié a mi supervisor. Desde el principio tenía mucha confianza en el trabajo, sin embargo, cuando lo presento, me encuentro con los problemas descritos anteriormente. Entonces, el comentario de mi supervisor sobre la revisión fue: “Estoy feliz de ver que ha mejorado su trabajo después de los contratiempos y la confusión iniciales. No investigaste lo que otros te dijeron que hicieras, así que hemos tenido suerte aquí. “Esto fue realmente molesto porque mi trabajo nunca estuvo en duda, y desde el primer día he seguido el mismo camino y no encontré ninguna dificultad. Así que esto le da una idea de cuánto pueden influir tales comentarios en la conferencia sobre la opinión de uno sobre un trabajo.
¿Existe una forma general de cómo tratar este tipo de situaciones en conferencias y reuniones? Afortunadamente, no me he encontrado con este comportamiento durante las revisiones por pares, pero si lo hubiera hecho, sería más fácil porque no requiere una reacción instantánea.
Tengo algunas respuestas genéricas como:
pero a veces no dan el resultado deseado porque las personas pueden ser persistentes.
Es importante reconocer que esto no le sucede a usted porque es un investigador junior. En cada momento de su carrera, alguien sentirá (y, con frecuencia de manera dolorosa, lo declarará abiertamente) que su trabajo no es lo suficientemente bueno, va en la dirección equivocada, no es ciencia "real", aborda los problemas equivocados, utiliza las herramientas equivocadas, o es de alguna otra manera defectuoso. Aprender a reaccionar ante las críticas sobre tu trabajo, incluso y especialmente si dichas críticas provienen de investigadores más experimentados, es una habilidad crucial que todo estudiante de doctorado debe aprender. Siento que es mejor dejar de depender de su asesor para justificar su contribución lo antes posible.
En ese sentido, creo que debería ver estas situaciones en conferencias y reuniones como oportunidades para aprender en lugar de situaciones feas de las que necesita salir lo más rápido posible. No quiero decir que deba meterse en peleas desagradables con la audiencia durante la parte de preguntas y respuestas de una presentación, pero estoy seguro de que tiene buenas razones por las que hizo algunas cosas y no hizo otras. No intentes evadir ( "Discutamos esto en el descanso, ¿de acuerdo?"), pero trata de explicar con calma por qué hiciste lo que hiciste. Sí, tal vez la persona que hace la pregunta no esté de acuerdo, pero ¿y qué? El hecho de que sus revisiones por pares sean buenas muestra que hay una cantidad no trivial de investigadores que realmente están de acuerdo con usted. La persona que hace la pregunta no es su supervisor, no es necesario que esté de acuerdo con él/ella específicamente sobre su agenda o enfoques de investigación.
Permítanme repasar sus declaraciones generales propuestas una por una:
"Gracias por tu sugerencia. He estado pensando en esto, pero requiere demasiado trabajo y eso está fuera del alcance de mi proyecto. Además, no contribuiría significativamente al valor del trabajo”.
Está bien, pero dejaría de lado la parte sobre "no contribuir significativamente al valor del trabajo". Eso suena un poco demasiado conflictivo para mí. Es mejor dejarlo en "eso es realmente interesante, pero actualmente no tenemos los recursos para abordar este problema complejo".
“Me lo he planteado, pero no me parece de interés, así que he decidido no hacerlo. Si te interesa este tema, te invito a colaborar.”
Manténgase alejado de la agresividad pasiva.
“Ese parece ser un punto interesante. Podemos discutir esto en el descanso con más detalles”.
Está bien, pero puede parecer demasiado defensivo. Usualmente uso la frase "bien, discutamos esto uno a uno" solo cuando alguien hace variaciones de la misma pregunta una y otra vez, y me parece probable que el resto de la audiencia ya se haya alejado del conversación. Sin embargo, en ese caso, un buen presidente de sesión ya intervino de todos modos.
La forma en que podría reaccionar es la siguiente:
"Gracias por su interesante sugerencia. De hecho, hemos discutido una variación de esto antes, pero implementarlo en la práctica requeriría que primero hagamos [cosa compleja A] y [cosa compleja B], que han demostrado no ser triviales esfuerzos en primer lugar en [óptimamente, tiene alguna referencia de por qué esto es realmente difícil]. Esto sin duda mejoraría la calidad de nuestra solución, pero actualmente estamos más interesados en extender nuestro trabajo en [otra dirección más factible]. Por supuesto, si está interesado en esto, estaría muy feliz de discutir posibles colaboraciones sobre [bebida caliente de su elección]".
(una variación de su primera sugerencia, pero un poco más formal y respetuosa, al mismo tiempo que deja muy claro que en realidad no va a hacer lo que se le ha pedido)
Creo que el problema de fondo es que las personas con las que trabajas no valoran lo mismo que tú . En sus comentarios, está hablando de que su código sea 'robusto' y 'maduro', lo cual es excelente si está desarrollando un producto comercial, pero es posible que no reciba mucho crédito en un entorno académico.
Mire este hilo por las muchas razones por las que es así: ¿ Por qué tantos científicos talentosos escriben software horrible?
En cuanto al 'código abierto', comienza a valorarse cada vez más porque la gente entiende los argumentos de la reproducibilidad y la necesidad de un mayor escrutinio en la evaluación de los métodos. Pero es solo una buena característica adicional, no un criterio necesario.
Puedes buscar formas de hacerlos cambiar de opinión, pero podría ser una lucha inútil. Su situación es frecuente con personas que realizan mucha programación en laboratorios de ingeniería o biología. Otras personas no necesariamente valoran la cantidad de trabajo invertido en la programación, están felices cuando funciona, pero preferirían comprar una solución comercial si pudieran.
Lo que valoran es cuando su trabajo responde preguntas fundamentales en el campo , ese podría ser el caso incluso cuando su código está mal estructurado, es subóptimo, está mal documentado, es lento, tiene variables nombradas aaaaay requiere que los usuarios copien y peguen las rutas de las carpetas con frecuencia.
Es posible que desee considerar dirigir sus esfuerzos hacia algo menos codificado. Porque, en última instancia, deberá satisfacer a su comité de tesis, no a sus compañeros githubbers.
He descubierto que la mejor manera de lidiar con tales preguntas es saber de qué estás hablando, preferiblemente mucho mejor que quien sea que te esté preguntando.
Como investigador junior, puede (no será) un experto en todo en su campo, pero aun así debe conocer muy bien su proyecto en particular.
Si conoce su proyecto, probablemente ya haya pensado en la mayoría de estas preguntas. Por lo tanto, puede dar una razón real por la cual algo es una mala idea o no funcionará. Por ejemplo, cuando se le pregunte: "¿Por qué no utilizó el método X, que se sabe que es más estable?", podría responder: "Si bien el método X es más estable, desafortunadamente en este caso produce un resultado incorrecto debido a Y. "
Por sus respuestas particulares:
"Gracias por tu sugerencia. He estado pensando en esto, pero requiere demasiado trabajo y eso está fuera del alcance de mi proyecto. Además, no contribuiría significativamente al valor del trabajo”.
Creo que estas son dos respuestas separadas y deberían ser "He estado pensando en hacer esto pero aún no lo he hecho/no tengo suficiente tiempo/necesito más dinero". o su "No, eso no sería útil ya que no es relevante/no funcionaría/generalmente una idea estúpida (sin embargo, dé una razón adecuada).
“Me lo he planteado, pero no me parece de interés, así que he decidido no hacerlo. Si te interesa este tema, te invito a colaborar.”
Personalmente, no diría que algo no es interesante, ya que eso implica que es aburrido, pero diría que no es mi prioridad en este momento o similar. Alternativamente, puede decir por qué cree que su trabajo es más interesante/importante. Por ejemplo, "Punto interesante, pero creo que es importante terminar mi trabajo en X, ya que tendrá implicaciones Y para su sugerencia".
“Ese parece ser un punto interesante. Podemos discutir esto en el descanso con más detalles”.
Mantendría esta respuesta para cuando alguien realmente haya hecho un punto interesante del que no está seguro o cree que es válido y le gustaría discutir más a fondo.
Puntos finales: hagas lo que hagas mantenlo civilizado y no descartes las opiniones de la gente. Eso solo hará que parezca que no sabes de lo que estás hablando, y de vez en cuando alguien puede decir algo de valor real.
Buena respuesta, en los comentarios de la pregunta, gracias. Iba a responder con un comentario, pero esto se está haciendo demasiado largo.
Creo que el problema que mencionas es común a cualquier trabajo que no se pueda cuantificar simplemente. Las pruebas formales e incluso los documentos también son ejemplos de esto y estoy seguro de que la gente encontrará muchos otros ejemplos. En resumen, hacer una crítica destructiva es fácil, especialmente si ignora o pasa por alto por completo aspectos cruciales del trabajo. Para las personas que no tienen algún conocimiento para tener su propio criterio u opinión, esta crítica puede parecer legítima, y hay muy poco que hacer contra eso porque explicar por qué no es legítimo puede requerir educar a estas personas sobre algo que no saben. No me importa lo suficiente ser educado y lo van a percibir como malas excusas.
¿Entonces lo que hay que hacer?
En primer lugar, la respuesta de @xLeitix está perfectamente bien. Tengo otra respuesta para reemplazar las tres que ambos comentan (es una plantilla variable para que pueda cambiarla):
Gracias por [su sugerencia|señalar eso|ese lindo recordatorio], en realidad [consideramos|evaluamos|pensamos en] esa [propuesta|enfoque|opción|alternativa] y es [ciertamente|definitivamente|bastante|bastante] [interesante |relevante|prometedor], sin embargo, nos hemos [centrado en|priorizado|abordado primero] el trabajo presentado y lo consideraremos para líneas futuras.
Lo considerarás y lo descartarás, porque es estúpido, pero no necesitas decírselo en la cara. Esa es una respuesta general que puede ser útil para muchas personas. Si quieres (específicamente) darles una bofetada, tengo una propuesta diferente.
Infiero que tiene una buena experiencia en hacer preguntas, probar teorías y programar, parece estar en el camino correcto para la ciencia de datos, aplique esa palabra de moda a todo y responda a cualquier crítica con algo como:
"Recibo sus críticas sobre la trivialidad del trabajo actual y, por supuesto, eso es algo que se puede percibir cuando el trabajo se considera superficialmente. Tras una inspección más cercana, puede notar que ser riguroso desde el punto de vista científico y de ingeniería y garantizar la calidad de el proceso y los resultados requiere un trabajo que no es para nada trivial, por lo que podemos preguntarnos cuál es el valor de las conclusiones no triviales a las que se llega a través de procesos no fiables".
(por favor, cambie lo no trivial y no confiable con las palabras adecuadas, se me está haciendo tarde)
También puedes abofetearlos físicamente o escupirlos en la cara, pero no esperes hacer muchos amigos de esa manera, úsalo solo con absolutos idiotas cuando estés absolutamente seguro de que todos los demás están pensando lo mismo pero guardando la lengua por cortesía. . Con esto quiero decir: nunca, porque la certeza absoluta nunca está disponible.
Respuesta tardía...
P: "¿Por qué no implementó la función XYZ?"
R: "Bueno... en cualquier proyecto de esta naturaleza, podemos ver fácilmente que hay muchos puntos de extensión donde las características y/o funcionalidades adicionales parecen plausibles e incluso deseables. En el alcance de este proyecto, decidimos que probar una línea de base la implementación del concepto central era el límite en el que nos mantendríamos dados nuestros recursos y plazos, aunque sin duda es valioso tener en cuenta que las extensiones, por ejemplo, la que identificó rápidamente, son territorio maduro para un estudio adicional".
P: "¿Por qué no usó el lenguaje/herramienta/biblioteca/sistema XYZ para esto en lugar de lo que usó?"
R: "En primer lugar, el lenguaje XYZ, aunque generalmente conocido dentro de la disciplina de CS, no disfruta de un apoyo comercial generalizado. Si es o no una herramienta ideal para este trabajo es ciertamente un tema válido para la discusión, pero el objetivo para los investigadores era resolver el problema en cuestión, no aprender y volverse fluido en un idioma entonces desconocido. Estoy seguro de que surgirá una implementación más eficiente, si este proyecto se comercializa".
Alejandro
ff524
aeismail
Puñal
usuario22668
Bacalao
Pruebas
usuario22668
Ajasja
Bacalao
usuario22668
usuario22668
Brújula