Re: Great for this Engineer
"For one thing, there is very little actual core information about software"
I did a second year paper on software engineering. There is quite a bit written about it, and much is useful and applicable. It's much more about speccing* and designing a system, knowing what sort of patterns to use, what you should and shouldn't re-use, etc.
It's the only course other than computer security which did much work on designing for security. Along with various other things that if you're not taking in to account throughout the whole process of design and implementation will cause your software to have fatal flaws.
Plus there was a whole section on correctly documenting all the parts of the process. It was one of the harder non-medical papers, partially because the two hour labs required us to produce actual work at the end of each session, with a hard deadline.
It's run by one of the department hard-arses, which is a good thing. He's a "proper" engineer (mechanical then robotics) and extremely demanding.
"descriptions of programming languages and some discussion of algorithms"
That should all be in first year papers. CS1, CS2, algos and optimization, should cover some OOL language, python and some flavour of C. Most of the more specialized languages get taught as part of the relevant courses (prolog and R). If you're doing a CS or programming degree I'd expect to have some grounding in assembly too.
"For another, few software practitioners have actually read many, or even any, of the core documents documents that do exist -- Hamming, Knuth, etc."
I'd add the mythical man hour to that list. While we weren't expected to read them, they have all been pointed out to us in the "if you want greater depth, go here" part of the lectures.
So while I'm not a software engineer (or programmer for that matter) I can tell the difference. In the same way there is a massive difference between a mechanic and a mechanical engineer, the engineer might not be able to fix your car, but they should know how a mechanic works, and design things to make their life easier.
It's the micro/macro split. The engineer should have a macro view, and ensure all parts work together. The micro view is when given a defined part of the problem to solve, the programmer builds that part. Engineer != programmer :D
"I can't say that I've ever been overly impressed with academic credentials per se, or, in many cases, with people who tout them."
I'm not either, but you should be able to ask someone what they actually did as part of their study. For example a CS graduate should have built a multi-tasking OS from scratch, possibly as part of a group. A knowledge engineer (I fucking hate my department name at times) should be able to build effective (and ideally adaptive) search algos and utilise the assorted ML techniques, and then be able to explain what they can and can't do to a non-technical audience.
So while I have a degree with "Engineer" and "Scientist" in it, I don't consider myself an engineer. Maybe a baby scientist, since I tend to be the main researcher in project groups (ie go read all the papers). Plus my thesis** was suitably abstract, rather than building a robot.
* yes, that's technically requirements engineering.
** Prisoner's dilemma with communication results in a different Nash equilibrium than without communication. Affectionately known around the department as my "Nash was wrong and a bit of a bastard" paper :D