Learning new technology

A while ago my colleague Olav Maassen asked a question on our company mailing list about the best book to read to learn OSx development. His question made me think not about the best book but about how I learned new programming languages in the past.
My first programming language was 6810 assembly code (OK, that was the second, the first was Commodore 64 Basic, but I’m denying I ever learned that). All I had was a reference manual, a dot matrix line printer (30 characters/second), a far better memory (this is important because IDEs have only recently won the battle against my deteriorating brain cells) and some binary feedback by a magazine on my proposal for an article (‘No thanks’). And lots of time to spare at the age of 13. So I had to learn without any real fine-grained feedback through trial-and-error.
On to the university and Pascal as my main programming language to solve small scale problems in a group of students. Feedback was minimal (‘yes, it compiles’) and in the form of an integer between 0 and 10 inclusive (‘Your grade is a 6’). In this case we learned from each other mostly since books were full of theory about programming for academic problems (what did you expect from a university…) but not (at least so I felt) about creating something that actually works.
My first real job was developing software in Oracle Forms and Reports in small teams. We had a combination of ad hoc peer reviews (‘Jan, this code really sucks, go fix’) and structured code walk troughs with an auditor working for the quality division. SQL was a major but easy to master paradigm shift from procedural Pascal. I remember weeks of training at Oracle headquarters in the Netherlands delivered by enthusiastic trainers. No theory here, just tricks.
The end of the nineties meant Java and web technologies for me. We started with tight deadlines and hardly any feedback (‘Yes, it compiles’ all over again), no tool support other than a clunky version of what later morphed into Eclipse. We learned the craft from a British company who were just a couple of weeks ahead of us on the learning curve.
Only recently I got used to pair programming, test first development and rigorous quality assurance in the form of peer reviews (‘Jan, this code really sucks, go fix’). The complexity of OO systems and the platform they were and are deployed on is far greater than the complexity of a terminal and database based system. This requires better quality measures and slows down the learning curve.
My last attempt to force secondary brain cells into active duty (to compensate for the ones that lost the battle against alcohol and age related wear and tear) is learning Scala and functional programming. Without the rigor of a project team you have to do something to make sure you learn to use the tools the way they are supposed to be used. Xebia provides an excellent environment to avoid laziness and dubious quality standards. I use peer reviews (to discuss design) and pair programming (to discuss code quality, ‘Oh, but there’s a much better way to solve this problem’) again to learn.
I do read books (Martin Odersky’s early book on Scala for example) but I easily get distracted or just too curious so I have to start experimenting. Learning by doing works better for me than reading a book, but if I want to break my old habits I need colleagues who know how to provide feedback. Code reviews and pair programming work best to help me learn quickly.