On the subject of the Stanford University (iTunes U) iPhone Programming class.
I had a professor at university who walked in the door on the first day, slammed a book on the podium, and in a loud Germanic accent bellowed, “There will be no stupid questions in this class! The only stupid questions are the ones you don’t ask.”
To my young, impressionable 17 year-old mind, it made so much sense that I thought it almost profound.
The problem is, youthful idealism can be rapidly eroded away.
There are stupid questions. The ones that used to particularly annoy me were when a fellow student would ask the professor a question that had just been covered or had just been asked by a different student and answered by the professor.
I remember sitting in class thinking, “Pay attention next time. You’re wasting my time.”
These unpleasant memories all came flooding back to me during the first few videos of the Stanford iPhone class and I really thought I might have to give the whole endeavor a miss. When I was 17, I didn’t have to take blood pressure medicine.
Fortunately, within the first few classes either the offending students were gone, or they’d gotten with the program. Since then, it’s really been invaluable to my study of iPhone programming. Typically, books have never worked well for me hen learning a new programming language/paradigm/whatever.
Hands on is what works for me but even that needs some “seeding” with some information. The iPhone developing environment/community was stifled for some time. Apple’s (some say) draconian non-disclosure agreement for early developers prevented source code and discussions from appearing on the net. It even prevented books on the subject from being printed. Thorough as Apple’s documentation is, it’s better as a reference than as a starting point. There hasn’t been a whole lot out there until recently.
I’ve completed plowing through “Beginning iPhone Development: Exploring the iPhone SDK” (Dave Mark, Jeff LaMarche) and am most of the way through initial development of my first iPhone application – more on that another day – so I’m not coming at this class completely cold. Nonetheless, it has helped me resolve numerous logical problems with my in-development application. This is not because the detail or content of the course is far-reaching, but simply because…
Let me digress for another moment.
Here’s another thing that I learned very quickly at university. Not all professors are created equal. In the Computer Science Department in the College of Engineering they had two kinds of professors. They had staff professors who carried a typical teaching workload and they had professionals who worked at some of the local companies who came in and taught the 7:20AM classes and then nipped off to to their real jobs.
You could guarantee those 7:20 classes were the best. In Computer Science knowledge and theory are essential but there is no substitute for solid, real-world experience. The professors who had both were awesome.
So back to the class. The two lecturers, Alan Cannistraro and Evan Doll, both Apple employees working in iPhone development, really demonstrate their knowledge of the subject. It comes across best when they’re answering some of those (good and/or not-so-good) questions from the class. More than once, when they switch over to do some code on-the-fly or respond to something that’s just askew from their prepared lecture I have those, “A Ha!” moments that get me closer and closer to understanding.
I feel this class is really a good example of what iTunes U can do. While I’m not exactly sure what the incentive for universities are to put things in iTunes U, this has convinced me to check out some other courses.
I read yesterday that the Stanford iPhone class has had over a million downloads. Impressive. Of course, if that represents 1 million viewers, (which I doubt it does, but we’ll just use that number for giggles) that still means that at least 900,000 will do nothing with what they learn. That leaves a 100,000 who will try and 90-95% of the them will probably have to go buy Macs to do Xcode development on. I can see why Apple seems happy to share its employees in this project.