Yawn. I would say the same about the glorious PhD professors that attempted to teach me. Even the best professors, who were actually pretty knowledgeable, would never really code at all, pushing that off to the grad students.

Some people just don't fit into the way academia works, and making silly judgments like yours about them does nothing but entrench the status quo.

I agree, but you still have to read the book. Coding can not be learned by copy and pasting other people's code. All I was trying to say is for every 20 people that say they are self-taught only one of them can write a feature from scratch from a blank slate and explain the trade offs of why they used a hashset vs a list. The other 19 may be able to get something working by copy and pasting another section and spending a week shoehorning it, but the competent person would bang out in a day without looking anywhere else.

> Coding can not be learned by copy and pasting other people's code.

Absolutely it can. I would even argue that is the best way to intro into programming, and even learning in general. You, of course, cannot stop after you have pasted it in. You have to think about why the author made the choices he made, but in doing that you will quickly build an intuition to be able to apply similar choices to entirely new problems. With a little experience, you won't even need to draw on other's code anymore.

The distinction you really seem to be making here is that self-taught programmers are able to enter the job market on day one, without that experience. While graduates have at least four years of experience under their belt before they are reasonably able to enter the job market. Of course the people with more experience are going to perform better. As more time passes, the skills between the groups will start to average out (with amazing and not-so-amazing people found in both groups).

Well, consider me in the 5% then. And though you're probably right about the 1-in-20, I don't think I'd put the proportion much higher for CS grads.

There are two diverging definitions of what it means to be a programmer.

There's one set of them who can write new programs, build systems, and learn technologies they aren't familiar with, but put them on a team of 30 people for a typical enterprise project, chugging along at 10 lines per day of code, and they'll be bored out of their minds.

There's another set that can't function outside of an IDE or design new systems, have no idea how anything actually works, but they can slog through corporate stuff and follow orders well enough to stay employed.

Both are called "programmers" but they're practically different jobs. It's easy for us in the first set to look down on the second, but maybe we should just admit that they're different task categories altogether.

Do you really need a CS degree to make that kind of judgement? Even before I was college-aged I knew (and so did several of my programming friends) about hash tables and how much faster they were than just iterating through something and checking. I didn't know Big-O but I did have a loose understanding that told me iterating through EVERYTHING is slow, and that there are smarter ways to look up values.

This sounds like a case of a programmer using the wrong datatype, realizing it, and then being too lazy to fix it.

I've interviewed plenty of people with a degree or even a master's in CS that, while they can recite the definition of a hashmap, can't actually use one in a program.

Sounds like someone from Stanford.