The trouble with learning principles and techniques from a pre-scripted screencast (or book, or blog post) is that the teacher gets to “set the stage”, so to speak. Everything looks very cut-and-dried when addressing a canned problem with a pre-written solution.
As you know, the real business of programming is a much messier affair. There are spurious errors, blind alleys, and brain farts. There are frustrating initial setup periods, slow tests, and missing contexts. There are ambiguous requirements, and long periods spent staring at the code wondering what’s the best thing to work on next.
That’s why, when creating this course, I decided I wanted to provide more than just a series of lessons. I wanted something more “real”. I wanted to show the day-by-day practice of programming with an eye towards OO design.
What you’re about to watch are recordings of a series of remote pair-programming sessions between veteran Rails consultant Betsy Haibel and myself. They are only lightly edited: breaks and long pauses have been removed, and some coding segments have been sped up. But all the discussions, digressions, indecision, confusion, and whoopsies of a normal pair-programming session have been left in.
Note that you won’t see all, or even the majority, of the techniques from the course lessons demonstrated in these sessions. If we had artificially set up coding scenarios in order to give us excuses to talk about the lesson topics, it would have ruined the reality of the sessions and turned it into just another canned example.
We approached these recordings the same way we approach any of our daily coding tasks: we started with a real application, selected a ticket that sounded small but interesting, and got to work. Betsy had some basic familiarity with the application being worked on; I was completely new to it. The only thing unrealistic about the work was the lack of a deadline.
[visitor course_id=”581″]