Maybe that's not such a bad thing? When a big chunk of our world runs on computers, maybe it's not such a bad thing to have standards and take things seriously, like it is done in every single other engineering profession.

The term professional programmer means the programmer is getting paid that's all. You want to put a barrier up? Are you worried about lives being lost? Professional programmers don't decide what to program that comes from the project owner. They translate human requirements to computers.

The people who decide what programmers write are defined by rules governing their project. If it's a health project laws around privacy restrict what the project owner can do.

I believe that programming is a skill, not a profession. You can know how to program without being a professional programmer.

Of course you can. You just… won't be a professional, and won't be held against professional standards (minimum output & quality, that kind of stuff). That's okay. But if you're going to get paid for it, you ought to be better than a random self taught amateur.

Though I suspect we aren't, in fact, much better than the average self taught amateur. That would be an indication that we still have progress to do.

I suspect this is because programming is actually even more rigorous than maths. When you do maths, you can gloss over details, and sometimes delude yourself into thinking false things (that very same thing happened on my last HN submission: I failed to notice a data dependency in EdDSA, and thought an attack were possible, when in fact it wasn't).

Programming uses an external cognitive engine (the computer), that is faithful, exact, and ruthless. Your program has to work. And when it doesn't, you're forced to revisit your assumptions (as I was forced to revisit mine when I actually tried to implement that attack and failed miserably).

So yes, totally with you here.

Whether that follows depends on how much and what kind of proficiency we require. We require programmers to be able to read and write, too, but we don’t require them to be excellent orators or literary writers.

I do think requiring some proficiency is OK. Basic arithmetic, for example, definitely is ‘in’. A bit of ability to think logically, too. That doesn’t mean all programmers have to know what a group or a ODE is.

In any event, I think it's possible to have your cake and eat it too. See http://iconicmath.com/ I think we can make mathematical toys.

Heck Scratch is a mathematical toy, eh?

It is almost cruel to taunt practitioners working around the hard, messy, ugly constraints of reality with the beautiful, elegant, and noble idea of not just conceptual mathematics, but the ability to immanentize it. But, this does little to solve the inherent messiness of the world that the software interacts with, and the messy things that people do which affect what it needs to do.

And sure, the world is messy. But some things aren't worth automating. I've seen a talk about how the guy was writing a program to generate invoices. Turns out invoices are incredibly messy. The previous system was an overly complex brittle pile of code, that didn't quite work. His approach? Solve the common case first, and let human handle the messy bits. He started by something very simple, that could handle 60% of the invoices. Then 90%. Then 95%. Then 99%. The he stopped.

With 99% of the invoices handled, he had a simple, solid system. The messy part was handled by humans, and they had the time to do so because 99% of the grunt work was taken away from them. Plus, they could trust it works because since those invoices were relatively simple, they could be automated reliably. I believe that approach can be generalised. As Mike Acton said: "solve the common case first".

That I believe would work to "solve the inherent messiness of the world". Automate what you can, let humans deal with the rest. Or don't automate at all, just give tools & tricks so humans can work faster.

Alternatively, we could adapt around computers. Before electricity, factories used to have a giant engine that powered everything through mechanical transmission. Wen electricity first came along, we did the same thing. But it turns out electricity is much easier to distribute at a small scale. So factories adapted, and instead of having a big engine at the centre, they started to have lots of small engines everywhere, close to where they were needed. I believe computers are similar: we started using them as glorified paper, but as we understand what they can do, we employ them in more efficient ways. But the interface of a computer (it can do anything!) is much more complex than that of an engine (it can rotate!). I believe we haven't found how to best make use of them just yet.

My point is that this judgment is the messy and valuable part. And to your point around the end, that you believe we haven't found how to best make use of them just yet -- I agree with that too, and that's why I think the work of writing software, or best practices, or sound theory is not fully established. To build good product does fundamentally require a pioneer spirit that can make compromises and negotiations and arrive at that sweet spot that's not quite 100% but high enough to be "good enough".