I kind of agree, and the overall thrust is right. But a degree is a useful shortcut in many cases. Or maybe I've just not worked with any non-degreed experts yet.
The trouble is that when those points aren't true they can be disasters. It's all very well saying "you don't need to know big O", but then you do need "good coding practices"... which are not fixed formulas, you need to know why you do them, and that comes back to stuff like Big O. Grit and learning likewise... but without a base of knowledge people can easily learn the wrong things and apply them with great diligence.
I have worked with a web developer who had on his desk a wee plaque saying that he had a non-university diploma and had failed both the software design courses in it. I don't think it was coincidence that he also regularly needed help to understand why his designs were not great, and often had to be pulled up before he committed horrors (he escaped once and produced a roughly O(N^40) treeview. Sounds ridiculous but the underlying antipattern was linear searches of the underlying array to produce every node in the tree. Just adding parent, first-child and next-sibling links to each node gave a dramatic improvement).
We also had a hard coded root credential issue because it was easier to do that than dig through the proper channels. Again "good coding practices" balance getting the job done vs not creating horrible security issues, but someone who doesn't understand why the security guidelines exist isn't capable of making good decisions consistently.
Having to do that level of constant supervision was tedious, because even though 80% of their work was fine you always have to check to make sure. Not being able to let that person supervise anyone was annoying. Pair programming is all very well, but when "finish coding this" can turn into tomorrows "let's review... ok, let's throw that away and start again"... it wears you out after a while.
It brings to mind "some people have ten years experience. Others have one years experience ten times".
In Australia and Aotearoa there seems to be a solid correlation. I've worked with a few mediocre degree holders and possibly one competent non-degree holder. But I've experienced the opposite as a matter of course (not that I assume up front, but that's the way it works out).
(edit) I work in smaller companies, and used to consult into companies who were having performance and especially server threading issues. That biases who I work with.
Conversely, I have a CS degree, and I remember Knuth’s books and big O notation, etc....
But I’m not a developer. You could ask me those questions and I would have a decent chance of being able to tell you the right algorithmic answer, but then fail to be able to do anything at all useful in Java.
I agree with the qualities of a senior engineer that he listed. Unfortunately these are all really difficult qualities to detect in an interview. Much harder than testing whether someone knows the big O of a hash table vs a sorted list lookup.
The trouble is that when those points aren't true they can be disasters. It's all very well saying "you don't need to know big O", but then you do need "good coding practices"... which are not fixed formulas, you need to know why you do them, and that comes back to stuff like Big O. Grit and learning likewise... but without a base of knowledge people can easily learn the wrong things and apply them with great diligence.
I have worked with a web developer who had on his desk a wee plaque saying that he had a non-university diploma and had failed both the software design courses in it. I don't think it was coincidence that he also regularly needed help to understand why his designs were not great, and often had to be pulled up before he committed horrors (he escaped once and produced a roughly O(N^40) treeview. Sounds ridiculous but the underlying antipattern was linear searches of the underlying array to produce every node in the tree. Just adding parent, first-child and next-sibling links to each node gave a dramatic improvement).
We also had a hard coded root credential issue because it was easier to do that than dig through the proper channels. Again "good coding practices" balance getting the job done vs not creating horrible security issues, but someone who doesn't understand why the security guidelines exist isn't capable of making good decisions consistently.
Having to do that level of constant supervision was tedious, because even though 80% of their work was fine you always have to check to make sure. Not being able to let that person supervise anyone was annoying. Pair programming is all very well, but when "finish coding this" can turn into tomorrows "let's review... ok, let's throw that away and start again"... it wears you out after a while.
It brings to mind "some people have ten years experience. Others have one years experience ten times".