As an engineer supporting researchers I ran into a peculiar problem. If I suggested an idea they often HAD to ignore it, because they couldn't claim it as their own. Especially the grad students who were trying to get a PhD by coming up with a unique idea of their own, but also the profs because it would be an admission that they "the experts" didn't understand what they were doing. So I had to lead them to come round to a perspective so they could think it was their own idea and hence be comfortable adopting it. A lot of time was wasted and ideas thrown away before I figured this out.
Also, if you are ever involved in academic research and you hear the words "that's just engineering" be very wary. It's a strong indicator that 1) the idea is not practical 2) they don't understand what they are doing. 3) you are going to have to make it work, often as an unacknowledged side project "that should only take a few days". I often spent years figuring out these "that's just engineering" side projects. Even worse, we'd build a "proof of concept" that ignored all the engineering, and then try to get other researchers or companies interested in the system as though it was complete.
Yet another thing I discovered is that for engineers one of the most important words they use in discussions is "no". Listen to two engineers discuss a problem and almost every other sentence will start with "no", "no that won't work because..." It's an important part of how they figure out how to make things work, by figuring out what does not work. CS researchers take it as an insult however, as in "no, you're an idiot and here's why". Perhaps because lead researchers are treated as infallible by their grad students they get the idea they can't be wrong, so they are not used to being contradicted. It's a huge problem in getting anything done. It can take months or years and a lot of wasted work to lead them around the circular path back to the original bad decision and try to get them to reconsider it (they are often very proud of it which makes it even more difficult). Saying "no" is somewhat like the mindset that is necessary for computer security work, you have to be able to attack systems or ideas from a ferocious point of view, seeking any weakness, without feeling that attacks on ideas are attacks on you. It's one of the most productive parts of discussion and is not taught directly, only by example and many CS researchers are so intent on building their reputations they will not tolerate it and are highly insulted by it and will defend their ideas to the point of absurdity. Framing a contradiction as a question helps here somewhat, though you still have to be careful in framing the question so it only leads to the contradiction rather than stating it outright.
I really think this misses the mark. Grad students don't treat their prof as infallible - at least good labs. In most labs, the grad students are the ones actually doing the work and research. The prof is just the marketing man. And a good prof in CS will understand they're the clueless marketing man. It's not really feasible for them to keep up with writing code and the whole grant writing (and networking with companies like you...) game.
Also I'm surprised that you had academics shopping "products" to you. I've definitely shopped ideas to companies before, but always with the explicit understanding that I'm doing "research" - i.e. you're spending a bunch of money on something that may go nowhere, and you're not going to get a product out of it.
That misunderstanding often makes the conversations end right there.
As a counter, I've found that many engineers will shut down ideas before you can even get started working on them because "no that won't work". It can be very frustrating, as the technical arguments they offer are stiff as a board. And not always as technical as they think.
Granted I work with GPU hardware research, so it could just be a lack of products in this area. Maybe viz? ML especially probably? I get the impression ML profs are a load of shit tbh.
> Even worse, we'd build a "proof of concept" that ignored all the engineering, and then try to get other researchers or companies interested in the system as though it was complete.
Career science / academia has these problems in general. But probably also industry as well. (Like who takes credit for what, if it's someone else's idea, it must be axed etc., if it comes from the boss' favorite then it must not be questioned etc)
Regarding the feeling offended to hearing "no", I think this has little to do with researchers/academics and more to do with managers and people who have to do it.
Generally, I would argue most researchers are very similar to what you attribute to engineers, e.g. they often answer "no" first (I have heard that commented on by outside observers multiple times). In fact researchers (academic or otherwise) are trained to find flaws in systems quickly, which typically involves saying "no that doesn't work because ...".
The flip side of the coin is that managers (and Professors or group leaders are essentially managers) don't like to be told that something can't be done. Especially if it was their idea. This is the same in many industry settings. So they really dislike to be told "no".
The irony is that at some point in the transition from researcher in the trenches (PhD, postdoc ...) to Professor/group leader many start to think that the PhD students/postdocs say know because they don't want to do the work. It's really weird, because pretty much everyone who is in academia is strongly self-motivated as they should know from their own experience.
> "the experts" didn't understand what they were doing. So I had to lead them to come round to a perspective so they could think it was their own idea and hence be comfortable adopting it.
This also applies to industry. This is basically managing up 101 for engineers. If the boss thinks it's their idea, it'll get approved and supported. If they think it's someone else's idea, depending on environment, it'll get blocked or sabotaged.
My degree course is split across my university’s Computer Science and Engineering departments, so I often get to hear both of the discussions you described. I would say that CS supervisors talking to their students are more direct in saying that the ideas that they come with won’t work or that their mathematics is incorrect, whereas engineering professors seemed to be a bit more subtle and guiding where their students falter, as though they perhaps had the exact same ideas when they were younger and want to gently discourage the same mistakes.
That’s not to say Engineering professors wouldn’t tell you you’re wrong, it just feels that the knowledge gap between the experienced and inexperienced engineer is larger than that for the computer scientist, and so there is more room for small errors to grow into bigger problems if ignored.
> whereas engineering professors seemed to be a bit more subtle and guiding where their students falter, as though they perhaps had the exact same ideas when they were younger and want to gently discourage the same mistakes.
It's because once something fails, in engineering the work doesn't stop. You have to root cause it and understand the failure. That's a valuable exercise in itself.
> Yet another thing I discovered is that for engineers one of the most important words they use in discussions is "no"...
This paragraph is a great insight - knowing how someone else is going to receive your (as you perceive it) constructive criticism cuts down miles to the destination of achieving the common goal. Speaking so your listeners will be able to "hear" you without perceiving an attack is critical in cross-discipline groups.
> if you are ever involved in academic research and you hear the words "that's just engineering" be very wary
An eminent computer scientist (Jeff Mogul I think) once pointed out that computer systems research is basically engineering.
I concur with this assessment and suggest that it's something that systems researchers should be proud of. After all, engineering means you're actually designing and building something that could potentially work.
> If I suggested an idea they often HAD to ignore it, because they couldn't claim it as their own. Especially the grad students who were trying to get a PhD by coming up with a unique idea of their own, but also the profs because it would be an admission that they "the experts" didn't understand what they were doing.
That's what authorship is for. What's the point in supporting academia if you can't get authorship?
I got authorship. The problem is that if I came up with the idea I'd have to be listed as the lead author, and that didn't seem to go over well. If I just contributed to their ideas they were fine with that. It varied per prof, some were happy to work on ideas from anyone because they saw the development of an idea as the important part, some were very strict about not accepting primary concepts that they or their grad students didn't come up with. Some listed a lead author, some put authors in alphabetical order. In one case I discovered the cause, we'd been brainstorming about new ideas for a while and I suggested a combination of several of those ideas that seemed interesting. They all got flustered and pushed the idea aside. I learned quite a while later (after we'd actually built that system) they had filed a patent a few days before for almost the identical idea and decided to leave me out of it. It made building the system awkward because they were continually coming up with alternate explanations for why this wasn't the same as the idea I had presented (and they had already also had and patented). I didn't work with them much longer.
> you have to be able to attack systems or ideas from a ferocious point of view, seeking any weakness, without feeling that attacks on ideas are attacks on you
This is how you should work in science anyways: "we tried to refute a theory, failed at that and are now forced to assume that it is valid to some degree."
Also, if you are ever involved in academic research and you hear the words "that's just engineering" be very wary. It's a strong indicator that 1) the idea is not practical 2) they don't understand what they are doing. 3) you are going to have to make it work, often as an unacknowledged side project "that should only take a few days". I often spent years figuring out these "that's just engineering" side projects. Even worse, we'd build a "proof of concept" that ignored all the engineering, and then try to get other researchers or companies interested in the system as though it was complete.
Yet another thing I discovered is that for engineers one of the most important words they use in discussions is "no". Listen to two engineers discuss a problem and almost every other sentence will start with "no", "no that won't work because..." It's an important part of how they figure out how to make things work, by figuring out what does not work. CS researchers take it as an insult however, as in "no, you're an idiot and here's why". Perhaps because lead researchers are treated as infallible by their grad students they get the idea they can't be wrong, so they are not used to being contradicted. It's a huge problem in getting anything done. It can take months or years and a lot of wasted work to lead them around the circular path back to the original bad decision and try to get them to reconsider it (they are often very proud of it which makes it even more difficult). Saying "no" is somewhat like the mindset that is necessary for computer security work, you have to be able to attack systems or ideas from a ferocious point of view, seeking any weakness, without feeling that attacks on ideas are attacks on you. It's one of the most productive parts of discussion and is not taught directly, only by example and many CS researchers are so intent on building their reputations they will not tolerate it and are highly insulted by it and will defend their ideas to the point of absurdity. Framing a contradiction as a question helps here somewhat, though you still have to be careful in framing the question so it only leads to the contradiction rather than stating it outright.