How to Criticize Computer Scientists (2001)

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.

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."

Does CS have a problem with that in general?

This made me chuckle, and then I read this:

> systems researchers will light up when telling you that they have constructed a system that is twice as fast, half the size, and more powerful than its predecessor

and thought "Oh God, that is me"! (I'm not in research) I almost don't want to read the rest.

On a (possibly) less personal topic, I've found that non-computer science researchers who program will dismiss all help with "it doesn't need to be run by anyone else", (which is kind of scary considering the problems with reproducibility) or, if they are open to help but they don't understand what you've suggested/written/submitted etc, will try hard to drop it quietly. I think it's so they don't have to admit any lack of understanding, which is weird - I can barely understand code I wrote 6 months ago and I've written plenty of Perl in the past, too. The idea that code should be so easily understood that to ask a question would make one seem inadequate strikes me as a fanciful dream.

Edit: don't want to mislead, I'm not a researcher, it just sounds like me :/ :)

I read that, chuckled and felt offended because IT ME.

> systems researchers will light up when telling you that they have constructed a system that is twice as fast, half the size, and more powerful than its predecessor

Then I read this and I _also_ thought IT ME.

I am not sure whether this means I have the skills of both sides or the foibles.