It is technically impossible to be a good 'CS People' and simultaneously be a 'horrible programmer'. It seems that what you are referring to are people who know basic CS concepts and even know the basic features of a language or two but do not have a 'Hacker' mindset. This does not make them a 'horrible programmer' -- just as a hacker who comes up with 'tricks', without actually understanding that the things he 'created' were already discovered in some 70s CS paper, is not a 'horrible Computer Scientist'. It's not a sufficient method to describe a person's strengths and weaknesses.
Sorry I wasn't clear: by 'CS people' I meant to refer to CS academics in graduate school (professors, post-docs, grad students), not CS professionals in industry --admittedly a sign of insularity, I recognize.
And what I meant is that, anecdotally, academics working on CS theory (eg theory of computation, computational learning theory) are more likely than not to unmistakeably be what I think everyone on HN would agree to call point-blank "horrible programmers": no use of version control, no tests, little concern for organization/modularity/maintainability, etc. And in part it makes sense since they don't have to hack nearly as much as systems-type CS academics --in many ways their work is closer to pure mathematics than engineering/applied math. That's all.
In all just a silly anecdote, although with a kernel of truth. See for instance Scott Aaronson's joke comments about his programming abilities [1]:
On the spectrum of computer science, I'm about as theoretical as you can get. One way to put it is that I got through CS grad school at Berkeley without really learning any programming language other than QBASIC (!).
This wouldn't be at all surprising if people realized that the job of academic computer scientists is not to program (just like the job of an academic mathematician is not to perform basic arithmetic.)
First -- I don't think it's wise or useful to judge Ph.D.'s by the same standards as industrial developers. Or vice versa. Consider the corresponding criticism of industry: "have you meet some of these jokers in industry? Most of them couldn't pass the qualifiers even after like 5 years doing CS full time. WTH?! It's almost like like haven't learned much new theory or math since graduating from undergrad or something...")
Second -- and this is purely based upon my personal experience (perhaps we have worked with people in radically different departments or research areas) -- what you say is simply not true in most cases.
I've worked with a lot of theory people, and did not encounter any really bad programmers.
Your specific criticisms:
1. version control. Everyone uses it for everything. Even and especially paper writing. If your experience is that theory phds don't use version control, then I would say your department is/was abnormal (or else we've observed people in very different parts of theory, I suppose).
But also, in many cases, using VCS is more religious than practical. Academic projects are often <10kloc single dev projects. It's more of a useful additional backup mechanism than actually necessary.
2. Testing. If the paper contains a full spec and correctness proof for the implementation (e.g. inference rules, automata, algorithm in terms of some mathematical object) then the point of the implementation is really just transliteration. The space for potential bugs is still there, but the bugs are very different from typical bugs (which, imho, are most often due to poor/vague or even completely absent specification). You simply need fewer unit tests when you know that precisely the thing you are implementing is correct, and just want to make sure you copied things down correctly.
3. The code is often well-written. When it is not, two problems are most common:
a. no comments! Okay, but of course there is a 20 page paper explaining the core idea. And also it's a protoype.
b. Bad structure/poor abstractions. Again, most prototypes don't need to be maintainable. If the core idea gets big and important, it probably makes sense to reimplement as part of a new research agenda anyways (e.g. for performance reasons, or because of unforeseen extensions due to scientific advances, etc). Also, in some cases, the correct way to organize a piece of academic software is highly non-obvious. Organizing your code is much easier when it's a completely solved technical problem in search for new social applications (yet another web app) than when it's a completely new technical idea.
How can your comment completely disregard the entirety of my actual conclusion?
>It's not a sufficient method to describe a person's strengths and weaknesses.
So, there should be if your classifications are correct. You are assuming that 'CS Professor' is equatable to 'good CS People'. But, my classification may not be so rigid.
EDIT: You also still have not defined what it means to be a 'Good Programmer' vs. a 'Horrible' one.
