There's a dirtier secret:

A load of professional programmers are not able to make new programs.

A load of professional programmers are not able to modify existing programs.

And a load of professional programmers are not able to finish programs.

Almost no-one is good at all 3. Most are extremely bad at least one of these.

Lots of people who are "good" at making new programs are actually pretty bad.

It's not a secret when you know how to code but you are an end user. Knowing how to code and knowing how to learn to code makes this widespread incompetence masquerading as competence and even "professionalism" radiate from every bit of software you ever come in contact with, as an end user. Seeing the source code just drives home the message even more. You become a more discerning end user.

> And a load of professional programmers are not able to finish programs.

I'm bad at this. I'm not sure if this is caused by a lack of programming skills or a lack of project management skills.

Does HR know this? I'm afraid not.

If HR is doing something other than providing expertise on managing relationships (particularly, the formal and compliance-related aspects of those relationships) for supervisory/management staff that are the domain experts providing knowledge related to the skill sets needed for the staff which are or will be reporting to them, then the organization has a fundamental (though, to be sure, distressingly common) design flaw.

Random dude who learns basic scripting says he's not good enough to be a software dev -> people chime in disagreement.

But, try to actually take them up on the offer and you'll probably find yourself jumping through programming interviews that will scoff at your basic skills.

Most of us got started writing little scripts. It's definitely a great start. To say that he could work as a professional programmer now is ridiculous. Could he have a career if he put in the time? Maybe. Can he get a job? Maybe. But, it's not the slam dunk these people are suggesting.

Note that I'm not even differentiating getting past interviews vs actually doing the work. I think either would be a stretch from writing a few scripts.

The software development market is giant and highly differentiated now. I have personally gone into client sites with plenty of people whose full-time job is doing nothing but scripting, and they're paid as software developers (for their locale) and their work is appreciated (as long as they have good bedside manners with the stakeholders). Granted, these clients are not hot startups, they're nowhere near the leading edge, it often involves tying together CRUD applications instead of more interesting problems, and often they're found in "flyover country" instead of hot metros, but for some people it's the right fit.

Starting and ending one's programming skills with scripting is not a programming sin. For some businesses, there is a real, constant need fulfilled by someone who glues together data and systems with scripts. Personally not my cup of tea, but I recognize it works for some people and organizations; if those circumstances work for you, then that kind of job is nearly a slam dunk.

'A job' is not necessarily a job at a large software firm. How about supporting your local medical offices (dentist, optometrist) by remote-monitoring their servers, installing updates etc? That's a job. Or updating web order forms for the local shops for the holiday specials?

There is an enormous spectrum of software to be done. And not enough people to do it, currently. So getting a job could be very easy.

Sure.

But, the point is a "professional software development job", not "something to do with computers"

The way it usually works is you get a job doing non-primarily coding stuff at a company that has also has programmers, and then get shifted to a development job when people figure out you can code.

Meh.

I've never seen that work for actual software development, but I guess it depends on where you work/what sort of job you do.

I've seen it work for sdets though so who knows.

Err, SDET _is_ a professional software developer. It's in the title!

Working in a non-development group doesn't somehow make you not a software developer.

They aren't the same job, regardless for how similiar the titles are.

My point was the skills required in architecting a solution vs testing a given specific solution differ. So, while you can more easily fall/move into a automated testing role, it's harder to do so into a core programming job. The bar for moving into the latter, rightly or not, very much higher.

Definitely. Maybe not a senior level dev at Google, but if you can do enough to automate tasks, you can almost certainly do enough to get hired as a junior dev somewhere.