[Signatura]

That’s an interesting comparison... The licensing point highlights how much of the burden in software hiring sits on explanation rather than verification. Without shared baselines, candidates end up narrating their competence instead of pointing to an accepted signal. The expectation gap you describe also explains why requirements feel flexible in practice but rigid on paper. When the real goal is “get someone productive soon,” standards tend to bend quietly rather than evolve explicitly.

Do you think the absence of clear baselines is something the industry could realistically converge on, or is software work too varied for that to work in the way it does for licensed engineering?

[austin-cheney]

Programming is writing logic, which is a universal quality. So the way I would do is to create a fictional programming language, provide some familiarity and training time immediately before a licensing exam (at the testing location), and then having the candidate solve real problems using the fictional language for the licensing exam. It tests for the ability to deliver solutions more than memorizing patterns or reproducing familiar conventions. Too many developers cannot write original logic.

Then there could be additional specialized qualifications above the base qualification, for example: security/certificates/cryptography, experimentation, execution performance, transmission/API management.