4 ms·

There's no test - all you have to do to be a software developer is declare yourself to be one. There's no overarching professional organization or boards, there

by bmj 13y ago

There's no test - all you have to do to be a software developer is declare yourself to be one. There's no overarching professional organization or boards, therefore incompetents aren't de-certified and national lobbying isn't coherent. And how does testing work? Do you do language-specific tests? Or general CS knowledge tests? And how do CS-knowledge tests apply to HTML/CSS slingers? Or are they not "programmers?" And if you certify by language, what does a company do when it wants to use a different, perhaps more applicable language for a product? Must all their devs be certified first? And what would this do for language development? Would anyone adopt new languages (or even variants) knowing that there are now institutional barriers?

potatolicious 13y ago
None of the above. If you look at professional self-regulation in traditional engineering, the focus isn't on competence. There is usually a very mild verification of basic fundamentals. In our world that'd probably translate into "what is an array"? The bulk of accreditation/certification in this context is not a guarantee of your competence, but a guarantee of your professionalism, and to set you up in a system where unprofessional conduct can be punished, and integrity enforced. The intent of this sort of regulation isn't to make sure everyone is an amazing programmer, but rather that they will operate above-board, be reliable and trustworthy, and recognize the limitations of their own abilities. The market, via salaries and benefits, will sort out people by ability. The intent here is instead to establish safeties for the demand-side such that they can hire with relative peace of mind, knowing that even if the person sucks at programming, they won't abscond with your codebase, engage in conflicts of interest, etc. And if they do, that there is a strong enough enforcement arm that provides both deterrence and retribution. It is also intended to protect practitioners by guaranteeing that the people investigating and hearing claims of malfeasance are actually skilled enough in the craft to fairly evaluate the claims.

by bmj 13y ago

potatolicious 13y ago

None of the above. If you look at professional self-regulation in traditional engineering, the focus isn't on competence. There is usually a very mild verification of basic fundamentals. In our world that'd probably translate into "what is an array"? The bulk of accreditation/certification in this context is not a guarantee of your competence, but a guarantee of your professionalism, and to set you up in a system where unprofessional conduct can be punished, and integrity enforced. The intent of this sort of regulation isn't to make sure everyone is an amazing programmer, but rather that they will operate above-board, be reliable and trustworthy, and recognize the limitations of their own abilities. The market, via salaries and benefits, will sort out people by ability. The intent here is instead to establish safeties for the demand-side such that they can hire with relative peace of mind, knowing that even if the person sucks at programming, they won't abscond with your codebase, engage in conflicts of interest, etc. And if they do, that there is a strong enough enforcement arm that provides both deterrence and retribution. It is also intended to protect practitioners by guaranteeing that the people investigating and hearing claims of malfeasance are actually skilled enough in the craft to fairly evaluate the claims.