really? It seems very applicable to CS research.

I suppose that depends on what you think of when you say CS research. CS research is very different depending on where you do you work, even the way authors are ordered on papers changes depending on how close to mathematics you work. Parts of this advice seem a better match for the theory side of the field than the systems side, for instance. In the systems side we often find it helpful to tell people to stop trying to overthink things, shut up, and code. (The systems will show you how they work when you're working with them, if you don't understand something: run an experiment.) In the theory side (where the author did his work) it is much more common to tell the students to think more instead.

I agree with that, and also think that it varies in the other direction, as far as emphasis on writing/coding/etc.

In programming languages and parts of AI, it's common for the thesis to mainly be an "analysis" of something, or a long-form "proposal" of a new approach, rather than a "write-up" of a "result". I get the sense that in Blum's corner of CS, and probably also systems, it's the other way around: you get some results, and then you write them up (though what counts as getting results, and how to go about it, differs quite a bit, as you point out). Whereas in the areas I work in, in some sense the thesis is sometimes the result. Sure, there are a bunch of technical results in it too, but they're a supporting cast of characters, included because they bolster the main analysis/argument/proposal.

I suppose the model I'm thinking of is somewhat more humanities-style thesis organization, which makes some sense, since AI has always been a bit coy about whether it's a subfield of CS, of cog sci, of philosophy, of engineering, or of something else. Interestingly, though, it's an even more common thesis approach in engineering. People think of engineering as less humanities-ish, but it's much more open to the idea that deep analysis of a problem/domain/approach is itself a research result.

There's sort of the "Computer Science" vs. "Software Engineering" difference going on there.

No, this is an overblown but common thing for people to say. Both sides do science, just some of us do science on abstract systems where in mind analysis is appropriate and others do science in less abstract systems where it is appropriate to experiment earlier.

Engineering on the other hand, is defined by an exemplary focus on good reliable design a system. Engineers often run tests as part of their work, but don't typically run experiments. (The difference, by the way, is that one can fail a test, whereas with a good experiment you succeed in showing something no matter your results.)

Please refrain from buying into the notion that science must be done only in worlds of abstraction and science done in less abstract systems must be labelled engineering. The use of the scientific method is what distinguishes science from engineering. My research requires me to do both at times.

Engineers often do pure experiments. It was EEs that came up with ROC curves, and good data sheets for electronic devices commonly show histograms and statistics for operating parameters. Hard drive optimization is largely about measuring the data density versus signal-to-noise ratio curve, whatever shape it happens to be, then picking a suitable error correcting code. Chemical process optimization is balls-out experimentation, especially when compounds insist on crystallizing in inconvenient forms. Civil engineers measure degradation to know when bridges need attention.

I think the difference is that engineers must often be satisfied with boring things that must be useful, while scientists aspire to interesting things that may be useless.

Since we have nowhere to go but more pedantic, I argue that engineers are not infrequently called upon to do science, just as many scientists are often called upon to do engineering.

Whether you call yourself an engineer or a scientist I would agree, has a lot to do with whether your goal at the end of the day is to produce something that works or something that fascinates. As someone who has the luxury to have a job doing the latter, I don't stop seeing myself as a scientist even when I happen to be doing some engineering work on one of my experiments.