True. I think there may be two camps though. It depends on if you want to learn and be able to master the fundamental theories that ground everything or have a more pragmatic approach where you accomplish things using tools you doesn't fully understand.

My example would be: when was the last time you implemented your own merge sort?

True that my knowledge of algorithms benefits me, but maybe all I need to know is that it sorts an unsorted array.

In the end, the best approach most likely depends on the person. Some people need to understand things fully, at the lowest level before they can build on them. Others need to see something in use and be able to play with it to wrap their minds around it. I know I'm personally a combination of the two.

Regardless of the type of person you are though, I think everyone is advocating that you do something to get the ball rolling.

Speaking only for myself, I "learned to code" six years before I got to college to study CS. CS taught me a bunch about what I was doing right and what I was doing wrong. My first paid programming job, as a senior/first-year master student taught me what all that meant when applied to what a business operation needs from its coders.

Learning to code, means being able to write a o(n^2) sort, not necessarily being able to tell why that algorithm is bad, or what O(n^2) means.