I don't agree with most of these points, nor do I find the tone of the author to be particularly productive, as they are effectively swinging bladed weapons around while blindfolded.
They propose a number of personal beliefs about what constitutes competency, whereas I will contend that there is no "silver bullet" by which a non-programmer (or XYZ profession) may assess the competency of the potential hire.
I could write a different article on programmers who seek to undermine existing code in order to get a green field project out of it.
While I can completely comprehend what may lie behind a total rewrite (and have plowed through some rather thick ones) I would be wary of hiring such a rigidly ideological person who suggested "throwing it all away and doing it over" as this person is likely somewhat obtuse in their own way.
Hey, appreciate you reading the article and taking time to write this.
Unsure how I am, as you say, "swinging bladed weapons around while blindfolded." Very colorful terminology, but I'm a little confused by what you mean.
The "silver bullet" term you're using I'm guessing is borrowed from Mythical Man Month, where Brooks suggests that no single advance in tech within a decade provides an order of magnitude improvement in productivity. I don't think that necessarily applies to helping non-technical people vet out programmers. I think I'm more giving these people a lamp in complete darkness.
I don't think brownfield projects created by great programmers are a bad thing. In fact, I've learned a lot working in brownfield projects. I do think though, a newbie programmer that, in a microcosm, creates a their own unique masterpiece loosely inspired by MVC, gets crushed by complexity and bugs, and then quits for supposed personal reasons, is a very real potential disaster for tech projects.
Why not just take some code and ask the applicant if he can read it and describe its function? Sure that won't tell you everything... but just saying you read "mechanics and thermodynamics of propulsion" doesn't make you a rocket scientist.
They propose a number of personal beliefs about what constitutes competency, whereas I will contend that there is no "silver bullet" by which a non-programmer (or XYZ profession) may assess the competency of the potential hire.
I could write a different article on programmers who seek to undermine existing code in order to get a green field project out of it. While I can completely comprehend what may lie behind a total rewrite (and have plowed through some rather thick ones) I would be wary of hiring such a rigidly ideological person who suggested "throwing it all away and doing it over" as this person is likely somewhat obtuse in their own way.
Human factors also matter.