he's saying that the various processes, methods, and tools we espouse should follow from a fundamental theory of software development. Right now, the nicest thing that can be said for the various things we espouse is that they are "laws" based on empirical observation.
But we don't have an underlying theory explaining which programming languages are more productive than others, or which processes will work and which will fail. It's a lot like chemistry before the periodical table and especially before quantum mechanics. In orther words, it's alchemy.
I don't know which statement you mean, and it's a bit unnerving to be defending HN's gold medalist of curmudgeonry twice in one day, but I was going to comment on this anyway:
90 percent of programming is more "typing" than programming because the work is straightforward.
This may be exaggerated, but it has more than a grain of truth. If you take it to mean 90% of programming as actually practiced, as opposed to 90% intrinsically, it's not even that much of an exaggeration.
Working on harder problems in higher-level languages than I used to, I felt less productive for a very long time. In some ways I still do. I eventually figured out that this was because I was spending much more time thinking and much less time typing. Typing feels like good-old-fashioned-work in a way that thinking doesn't. That's why people feel satisfied after cranking out thousands of lines of code, when in reality they may well have made an unmaintainable mess (and thus destroyed value rather than created it).
