How to respond to the trivialisation of one’s work and unjustified demands for a considerable extension of the research?

Question

I am a graduate student in engineering whose work includes a lot of programming and implementation of the developed theories. I am not a computer scientist, but I am a fairly skilled programmer, at least when compared to other people in the field.

In the recent months I went to a few conferences and to meetings with partners participating in my research project. In most cases my supervisor attends these events as well. We do not have the same background, and while I get a lot of support from him, there are some gaps where he is not proficient and does not have a good overview, especially about the amount of work required to get something implemented. In such tasks we have a relation that is based on trust that I am doing a correct job, which gets disrupted when other researchers are involved, as described in the continuation.

At such events I have encountered the problem that some people boldly enquire why I did not research or develop a particular (usually irrelevant) feature, and give suggestions for the extension of the work which are far beyond the scope of my project and time. This is especially the case about programming, and it comes from people who have never implemented anything. For some of the suggestions, I would need my own research team and a few years of funding. And sometimes the people asking such questions try to show-off in front of others by trivialising my research. This is annoying. And this situation gets worse when I give a simplified presentation of my work in order to make it more understandable to a wider audience. On conferences I see that other young researchers experience the same problem. Indeed I am a young researcher and it may look like I am overestimating my work, but I have a good overview of the field and I have no issues with suggestions that require an additional but reasonable amount of work. My papers so far all got good reviews, and at my department I am one of the most productive graduate students, which makes me confident that I am on the right path and do more than enough work.

While I tend to ignore such demands, this puts me in a difficult position when it is about a topic where my supervisor does not have expertise. My supervisor gets a wrong impression that I am not doing a right job, and that my work is basic touching only the tip of the iceberg. Other people in the audience instantly get such opinion as well. This escalated today when I have received a very good review of a paper that I have submitted with my supervisor. From the beginning I was very confident about the work, however, when presenting it around, I run into issues described above. So the comment of my supervisor on the review was “I am happy to see that you have improved your work after the initial hiccups and confusion. You did not research what others told you to do, so we have been lucky here.” This was really annoying because my work was never in question, and from day one I have followed the same path and did not encounter any difficulty. So this gives you an idea how much such comments on conference may influence one’s opinion about a work.

Is there a general way how to deal with such situations at conferences and meetings? Luckily I have not encountered this behaviour during peer-reviews, but if I had, it'd be easier because it doesn't require an instant reaction.

I have some generic answers such as:

• “Thanks for your suggestion. I have been thinking about this, but it requires too much work, and that is outside the scope of my project. Further, it would not significantly contribute to the value of the work.”
• “I have considered it, but I don’t find it of interest, so I have decided not to do it. If you are interested in this topic, I invite you to collaborate.”
• “That seems to be an interesting point. We can discuss this at the break in further details.”

but sometimes they do not give the desired outcome because people can be persistent.

Answer 1

It is important to recognize that this is not happening to you because you are a junior researcher. At every point in your career, somebody will feel (and, distressingly often, openly state) that your work is not good enough, goes into the wrong direction, is not "real" science, tackles the wrong problems, uses the wrong tools, or is in some other way flawed. Learning how to react to criticism regarding your work, even and especially if said criticism is coming from more senior researchers, is a crucial skill that every PhD student needs to learn. I feel it is best to stop relying on your advisor to justify your contribution as soon as possible.

In that vein, I think you should see these situations at conferences and meetings as opportunities to learn rather than ugly situations that you need to weasle out of as fast as possible. I do not mean that you should get into nasty fights with the audience during the Q&A part of a presentation, but I am certain you do have good reasons why you did some things and did not do other things. Do not try to evade ("Let's discuss this in the break, ok?"), but try to explain calmly why you did what you did. Yes, maybe that person asking the question will disagree, but so what? The fact that your actual peer reviews are good shows that there are a non-trivial amount of researchers that actually agree with you. The person asking the question is not your supervisor, you don't need to agree with him/her specifically on your research agenda or approaches.

Let me go over your proposed blanket statements one by one:

“Thanks for your suggestion. I have been thinking about this, but it requires too much work, and that is outside the scope of my project. Further, it would not significantly contribute to the value of the work.”

That's ok, but I would leave away the part about "not significantly contributing to the value of the work". That sounds a bit too confrontational to me. Better just leave it at "that's really interesting, but we currently do not have the resources to tackle this complex problem".

“I have considered it, but I don’t find it of interest, so I have decided not to do it. If you are interested in this topic, I invite you to collaborate.”

Stay clear from passive-aggressiveness.

“That seems to be an interesting point. We can discuss this at the break in further details.”

Ok, but can come across as too defensive. I use the "ok, let's discuss this one-on-one" phrase usually only when somebody is asking variations of the same question over and over again, and it seems likely to me that the rest of the audience is already zoomed out of the conversation. However, in that case, a good session chair has already stepped in anyway.

How you could react is the following:

"Thank you for your interesting suggestion. We have indeed discussed a variation of this before, but implementing it in practice would require us to first do [complex thing A] and [complex thing B], which have been shown to be non-trivial efforts in the first place in [optimally you have some reference why this is indeed hard]. This would certainly improve the quality of our solution, but we are currently more looking towards extending our work into [more feasible other direction]. Of course, if you are interested in this, I would be very happy to discuss potential collaborations over [hot beverage of your choice]."

(a variation of your first suggestion, but a bit more formal and respectful while still making it abundantly clear that you are not actually going to do the thing that has been asked for)

Answer 2

I think the underlying problem is that people you work with don't value the same thing as you. In your comments, you are talking about your code to be 'robust' and 'mature', which is a great thing if you're developing a commercial product but might not be given much credit in an academic environment.

Look at this thread for the many reasons why it is so: Why do many talented scientists write horrible software?

As for 'open source' it starts to be valued more and more because people understand the arguments of reproducibility and the need for more scrutiny in the evaluation of methods. But it's only a nice additional feature, not a necessary criterion.

You can look for ways to change their mind, but it might be a useless struggle. Your situation is frequent with people who are doing a lot of programing in engineering or biology labs. Other people don't necessarily value the amount of work put into programming, they are happy when it works but would rather buy a commercial solution if they could.

What they value is when your work answers fundamental questions in the field, that could be the case even when your code is ill-structured, suboptimal, badly-documented, slow, has variables named aaaaa and requires users to copy-paste folder paths frequently.

You might want to consider steering your efforts towards something less code-y. Because ultimately you will need to satisfy your thesis committee, not your fellow githubbers.

Answer 3

I have found that the best way to deal with such questions is to know what you are talking about, preferably much better than whoever is asking you.

As a junior researcher you may (won't) be an expert in everything in your field but should still know your particular project really well.

If you know your project you have probably thought about most of these questions already. Therefore, you can give an actual reason why something is a bad idea/won't work. For example when asked, "Why didn't you use method X, which is known to be more stable?", you could reply, "While method X is more stable, unfortunately in this case it produces an incorrect result because of Y."

For your particular answers:

“Thanks for your suggestion. I have been thinking about this, but it requires too much work, and that is outside the scope of my project. Further, it would not significantly contribute to the value of the work.”

I think these are two separate answers and it should either be "I have been thinking about doing this but haven't got around to it yet/don't have enough time/need more money." or its "No, that wouldn't be useful as its not relevant/wouldn't work/generally a stupid idea (give a proper reason though).

“I have considered it, but I don’t find it of interest, so I have decided not to do it. If you are interested in this topic, I invite you to collaborate.”

Personally, I wouldn't say something is not interesting, as that implies it boring but would say its not my priority right now or similar. Alternatively, you can say why you think your work is more interesting/important to do. For example, "Interesting point, but I think it is important to finish my work on X as it will have Y implications to your suggestion".

“That seems to be an interesting point. We can discuss this at the break in further details.”

I would keep this answer for where someone has actually made an interesting point that you are either not sure about or think is valid and would like to discuss further.

Final points: Whatever you do keep it civil and don't dismiss people opinions out of hand. That will only make it appear you don't know what you are talking about, and every so often someone might say something of real value.

Answer 4

Good answer, in the comments of the question, thank you. I was going to reply with a comment, but this is becoming too long.

I think the problem you mention is common to any work that cannot be simply quantified. Formal proofs and even papers are also examples of this and I'm sure people will find many other examples. In short, making some destructive criticism is easy, specially if it completely ignores or overlooks crucial aspects of the work. For people that don't have some knowledge to have their own criteria or opinion this criticism may seem legit, and there is very little to do wrt to that because explaining why it isn't legit may require educating these people on something they don't care enough about to be educated and they are going to perceive it as poor excuses.

So what to do?

First of all, the answer by @xLeitix is perfectly fine. I have another answer to replace all of the three you both comment (it's a variable template so you can change it):

Thank you for [your suggestion|pointing that out|that nice reminder], we actually [considered|evaluated|thought about] that [proposal|approach|option|alternative] and it is [certainly|definitively|quite|fairly] [interesting|relevant|promising], however we have [focused on|prioritised|addressed first] the presented work and we will consider that for future lines.

You will consider it and discard it, because it's stupid, but you don't need to say that in their face. That is a general answer that can be useful for many people. If you (specifically) want to slap them I have a different proposal.

I infer you have a good expertise in making questions, proving theories and programming, you seem to be in the right track for data science, stick that buzzword to everything and reply to any criticism with something like:

"I get your criticism on the triviality of the current work and of course that is something that can be perceived when the work is considered superficially. Upon closer inspection you may notice that being rigorous from scientific and engineering points of view and ensuring the quality of the process and results requires a work that is not trivial at all, so we may wonder what is the value of non-trivial conclusions that are reached through non-trustworthy processes".

(please change non-trivial and non-trustworthy with proper words, it's getting late for me)

You may as well physically slap them or spit them in their face, but don't expect to make many friends that way, use only with absolute jerks when you are absolutely certain that everybody else is thinking the same thing but keeping their tongue for politeness. With this I mean: never, because absolute certainty is never available.

Answer 5

Late answer...

Q: "why didn't you implement XYZ feature?"

A: "Well...in any project of this nature, we can easily see that there are many extension points where additional features and/or functionality seem plausible and even desirable. In the scope of this project, we decided that proving a baseline implementation of the core concept was the boundary we would stay within given our resources and timeframe, though it's certainly valuable to note that extensions, for example the one you've quickly identified, are ripe territory for further study."

Q: "why didn't you use language/tool/library/system XYZ for this instead of what you did use?"

A: "first of all, language XYZ, though generally known within the CS discipline, doesn't enjoy widespread commercial support. Whether or not it's an ideal tool for this job is certainly a valid topic for discussion, but the goal for the researchers was to solve the problem at hand, not to learn and become fluent in a then-unknown language. I'm sure a more efficient implementation will emerge, should this project become commercialized."