Programming is a trade of great skill and requires enormous amounts of knowledge. Whereas one has to be self-taught it doesn't mean one is alone. It is something I found out when I got my first job.
I joined a small team at a startup. Those guys did their best to make me produce quality code as soon as possible. They were reviewing my code several times a day, and teaching me what to do to, to make it efficent, easy to understand and well designed. Early on they even made me read the "Clean code" and I am eternally grateful for this.
Now I think part of being self-taught is actually having to find teachers on your own. Software Engineering is always about knowledge - whenever you code, you're probably solving a problem, which hasn't been solved before. Otherwise you'd just use some library to do the trick. It means that programming is about inventing new stuff, and so when you tell someone about your code, you're actually teaching them about it. Whenever you join a new project, someone has to teach you how to work with their system. If you're independent contractor building software for your client, you have to learn their ways of doing business.
High tech jobs are all about knowledge transfer, this way or another.
During my college I didn't learn that much from my professors, when it comes to software engineering in the trenches. I did learn a lot during college though. It was a time of meeting other people who were passionate for technology. We could exchange our insights, and do college projects our way. We would give each other feedback on our work, and so we were actually teaching each other.
I think above applies to meetup groups, code retreats and similiar initiatives. Programmers gather together to learn. Software engineering is all about knowledge transfer, and you have to want to learn, but it doesn't mean there's nobody to teach you. You just have to find your teachers on your own.
This is my feeling, too. I never took any serious CS course during my studies, not more than maybe an hour a week at best on Mathlab, Caml, Prolog or Pascal, a tiny bit of assembler or LOGO, and these courses were almost always tied to other scientific disciplines, using the computer as a tool in the exact same way as we would use a ruler, an erlenmeyer or a LED.
I learned programming at work. I was working in a startup that I joined shortly after the internet bubble burst, in 2002, as their first employee. I was taught, beyond syntax and flow, to find my own "Way of the Programming Fist", as I like to name it, and more importantly to keep an open mind for other ways of programming. The key, and possibly the only lesson that is still relevant today:
"When in doubt, remember that your Way of Programming is complete, which means you can eventually build anything with it, anything. Whether you want to display a barchart from a static printer spool log or light up a bulb with a handclap, your Way of Programming can eventually do it. For every goal, there are probably faster, stronger or easier Ways, but these are never 100% better: there's always a tradeoff. For that reason you don't need to learn the other Ways - but make sure you acknowledge their existence, learn and remember these pros & cons your whole life."
You're talking about "Quality Code" - I didn't get it through people looking at my code, but through me looking at other people's code. My brains designed some abstract "compiler" of sorts, used in my very mind to parse an alien piece of source. For me, "Quality" in that domain is the amount of work I need to do to be understand the "Way of the Programming Fist" of the coder, and use it in turn for my own programs. It has a lot to do with conventions, design patterns, formatting, naming and of course the programming language's "family", whether it's procedural, functional, object-oriented or whatever.
A decade later, it feels like it's still only the beginning, but I'm now proficient enough to understand the pros and the cons of some of the various conventions, design patterns, algorithms or programming languages I've met along the way, the way they fit with various goals and requirements, I'm mature enough to make my own choices, and I actually have my own programming business.
I would absolutely describe myself as a self-taught programmer, but like the above poster said, I would have gone absolutely nowhere on my own. Programming is all about knowledge transfer - "Here's what I use to do this, and here are the benefits, here are the tradeoffs" should be every programmer's favourite sentence.
I joined a small team at a startup. Those guys did their best to make me produce quality code as soon as possible. They were reviewing my code several times a day, and teaching me what to do to, to make it efficent, easy to understand and well designed. Early on they even made me read the "Clean code" and I am eternally grateful for this.
Now I think part of being self-taught is actually having to find teachers on your own. Software Engineering is always about knowledge - whenever you code, you're probably solving a problem, which hasn't been solved before. Otherwise you'd just use some library to do the trick. It means that programming is about inventing new stuff, and so when you tell someone about your code, you're actually teaching them about it. Whenever you join a new project, someone has to teach you how to work with their system. If you're independent contractor building software for your client, you have to learn their ways of doing business.
High tech jobs are all about knowledge transfer, this way or another.
During my college I didn't learn that much from my professors, when it comes to software engineering in the trenches. I did learn a lot during college though. It was a time of meeting other people who were passionate for technology. We could exchange our insights, and do college projects our way. We would give each other feedback on our work, and so we were actually teaching each other.
I think above applies to meetup groups, code retreats and similiar initiatives. Programmers gather together to learn. Software engineering is all about knowledge transfer, and you have to want to learn, but it doesn't mean there's nobody to teach you. You just have to find your teachers on your own.
You are self-taught, but never alone!