That is pure unadulterated drivel. I'm a developer. I've been a developer since the 60s, at a time when there were NO set-oriented languages out there. I designed set-oriented solutions, message-oriented solutions, list-oriented solutions, functional solutions, and logic-oriented solutions according to what was needed without regard for the language I would have to implement those solutions in - because the right algorithm is the right algorithm whether you are programming in assembly language or in a procedural language or in an object language or in a logic language or in a list-processing language or in a functional language or in anything else. Most of my colleagues over the years had the same attitude. I know very well that a lot of developers are fully capable of thinking in terms of sets.

Distinguishing between a programmer and a developer is a strange game - it's not generally a useful distinction. Maybe you are thinking of someone who takes someone else's detailed design instructions, type specifications, and flow diagrams and turns them into Basic? That's not a programmer, that's a coder - and it's getting on for 50 years since I last came across one of those, because they are a silly idea - they cost money and don't save the someone else any time. There is a useful distinction between scientists and engineers on the one hand and non-scientist non-engineer developers on the other hand, but that distinction is about having acquired formal recognition (which developers who are incapable of thinking like engineers or scientists should in theory never acquire - the practise isn't always in line with the theory)

Most errors, including performance issues, should be eliminated long before development by good unit testing and fixing the problems detected there; most of the rest should be eliminated by good system testing and fixing; most of the small proportion that remain should be caught by final quality validation. If most Errors are found after release the development testing and release people are a bunch of incompetents.

Over the years I've taught a lot of people set-oriented techniques and how to program in a set oriented manner in declarative languages whether process/message oriented, functional, or logic-oriented or non-declarative languages like SQL. I complain about the appallingly bad SQL I see, and often just complaining has produced a remarkable improvement in performance. I complain about University computing courses which teach micky-mouse languages like Pascal or horrendous abominations like C++ and no computing science, no engineering good practise, no functional algebra, no logic calculi, no set-oriented thinking, no list-oriented language, no process-oriented thinking. I complain about people who call themselves developers but haven't a clue how to develop anything and can't be bothered to acquire a clue (haven't had much to do with such, fortunately), those who haven't a clue but think they have and can't be dissuaded are even worse. People who want to be developers and are willing to learn are fine - they are easy to teach.

I've seen dozens of posts in the forums here where developers have said how much they've enjoyed some of Jeff's articles and the ensuing discussions, and how much they have learned from them. Rather obviously those are developers who can do set-oriented thinking, some of them because Jeff's articles have taught them how to think that way. The idea that programmers can't be taught set-oriented thinking is nonsense. Teaching them about schema normalisation and/or three-valued logic and/or real security can be a bit more difficult, though.