I did all my first steps with trial & error and reading the manual, too (not something as complex as a compiler, but to be fair – I was 9). I never even so much as touched a book about programming until about 13 years later my current company hired me right after the interview and told me to get familiar with clean code and handed me a book.
I was then put on a project for an international mobile service provider. The software was written in Perl and S-Lang and had to be accessed through a shell (no IDE). And we're talking about 1,000,000+ lines of code here. I had never really used any of those languages or the shell before. Now I know both languages to a fair extent and I love shells, but I never read a book about it – I did use Google a lot, though (which also I think is something people need to learn more; to do research on their own first).
Two weeks ago I was simultaneously put on a second project at the same company. Unlike the first one, this is a project with a lot of stress (28 people in 3 sub-teams) because we got that project to clean up the mess of an Indian outsourcing company. At least this one uses mostly Java, which I also had never used before I worked there. And there it's not just Java – the deployment is a rather complicated process and the system is *huge*.
You grow with your challenges. And you learn by doing things yourself. Which is exactly why I try not to just present the final result to everyone. If it can be googled, I tell them to google. If it can be looked up in the manual, I tell them to look it up in the manual. They may not like it, but on the long run it's the only way for them to not just learn to read code, but to learn to write code.