“Software Engineering”, a field of interest launched in 1968 that aimed to bring product design and construction skills to computer scientists by having very clever computer scientists think about what product design and construction might be like and not ask anybody. – Graham Lee
The idea of certification and licensing for software engineers came up in a Slack I’m on. Of course I accidentally ended up writing a wall of text that really needed to be a blog post, so here we are.
I think those algorithm coding white board tests used by many tech companies to vet potential employees are meant to be some kind of measured standard. However, as an industry it’s been collectively decided (mostly by default rather than intent) that there should be alternate paths to a career, which makes that kind of standardization feel like more like gate-keeping.
Additionally, the vast array of technologies available make it hard to quantify knowledge like that. Are you certifying for front end, backend, general knowledge? Say you’re going to have multiple certificates. If it’s front end, are you standardizing a particular language or even framework? How long would such a thing be valid for?
Setting standards also means being able to take a step back and evaluate the industry as a whole. It would surely slow progress of new technologies, but then I don’t necessarily feel that’s a bad thing, if I’m being honest. Move fast and break things was meant to be an approach to solving problems in new ways (yes, and make money fast and easy) but unfortunately seems to have taken the discipline of writing software along with it.
It’s all something to think about, and standards, if not licensing as other engineering disciplines have, is not the worst idea I’ve ever heard. I even say this as someone who didn’t graduate college. If licensing was put into place, I’d be out of the running and at the same time I feel that so much software is built in a way that’s harmful to users and maintainers alike that something should probably change.