My Apprenticeship - Friday, August 13, 2004

This summer I'm revisiting my short apprenticeship at Object Mentor. I'll be posting commentary on all my posts from the summer of 2004 exactly 5 years later to the day.

Friday 8-13-04

Last day in Gurnee. The Object Mentors decided that pizza wasn't enough for my birthday, so they took me out to one of those fancy Japanese steakhouses. Ya know, I've never actually been to one of those knife-flying, death-defying, make-it-all-on-a-grill-while-you-watch restaurants. A good time was had by all.

It's been a good summer. I've learned tons about class design principles, patterns, pair programming, test driven design, and a whole bunch of intangibles. Without a doubt the coolest thing about working at OM was being able to lean over and ask David, or Micah, or Paul, or James, or -- Look, everybody sitting next to me had great ideas about programming and, as cool as all their classes are, working with great programmers is a much better way to learn.

Speaking of Object Mentor's classes, I've been meaning offer up my critique -- from a teacher's point of view. What I like, and what most non-teachers usually screw up, is the commitment to lab work. If there's a lot of material to cover you can seem to cover it quicker with more lecture and less lab, but that's a big mistake. Just because you throw a slide up on the screen and yap about it does not mean that anybody had any idea what's going on. In my experience, 40-50% of the class are thinking about something besides what I'm talking about at any given moment. So it's crucial to have the students work out the presented ideas in the lab. First, because it forces them to talk to each other and fill in the gaps where somebody was distracted by thoughts of girls, or candy, or shiny objects. And second, because if a student knows they're probably going to put the presented ideas into action they pay just a bit closer attention. The lab, in this case, is writing some code. Because OM is XP, they do all code writing in pairs. Which is very cool. One person can get stuck, but two can tackle ideas that would confound either individually. So the classes don't bog down when a few people are way behind and others have zoomed ahead. The groups tend to keep everybody moving along at the same pace (well not exactly, but it's much better). Which is probably a good argument for pair programming in the non-classroom: Nobody gets lost. I tell ya, I miss it when I have to work by myself. There's nobody there to keep me from doing something stupid so I waste lots of time running down a blind alley when a pair would look over my shoulder and say 'What the hell are you doing that for?'

Well I gotta pack for XPAU -- next post will be from Canada!

There are many times in life where you can go faster short term but you have to pay more on the back end. Sometimes it's worth it (startups coming to mind), but I worry that once you've compromised your ideals once it's hard to know where to stop.

Comments

Post a Comment

Popular posts from this blog

What's a Good Flog Score?

I've been using Flog to measure the complexity of my Ruby code and I was wondering how others interpret Flog numbers. I'll go first with my opinions: Score of Means 0-10 Awesome 11-20 Good enough 21-40 Might need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children (note: these are scores for an individual method) The 20 - 60 range is interesting to me. Sometimes the complexity of what you're doing will justify the score and other times the method is in desperate need of refactoring. The highest Flog score I've seen in the wild was in the 300's. What's you're personal high and what do you think of my rankings? In other news, I've redesigned the look of my blog so if you only see my post through a reader you might want to stop on by, take a look, and tell me what you think.
Read more

SICP Wasn’t Written for You

The number of software luminaries who sing the praises of “ Structure and Interpretation of Computer Programs ” (referred to as SICP) is such a long list that you might think only a crazy person would take issue with it. However, to ignore SICP’s problems and continue to blindly recommend it seems just as crazy. SICP was the textbook for MIT’s introductory programming class and was a bit of a departure from other into to computer science textbooks at the time.  Wikipedia sums it up nicely:  “Before SICP, the introductory courses were almost always filled with learning the details of some programming language, while SICP focuses on finding general patterns from specific problems and building software tools that embody each pattern.”  Which sounds awesome, but does essentially say that abstract principles will be introduced before the nuts and bolts of a language.  If you think about that for a minute, you may see where the problems will be. When I was training to be a...
Read more

Point Inside a Polygon in Ruby

Recently my team needed to find out if a point was inside a given polygon and, as usual, we found some code on the internet that did what we wanted. And, as usual, there wasn't much explanation as to what it was doing. Here's the code (after we converted it to Ruby): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def contains_point? (point) c = false i = -1 j = self .size - 1 while (i += 1 ) < self .size if (( self [i].y <= point.y && point.y < self [j].y) || ( self [j].y <= point.y && point.y < self [i].y)) if (point.x < ( self [j].x - self [i].x) * (point.y - self [i].y) / ( self [j].y - self [i].y) + self [i].x) c = !c end end j = i end return c end end So, you know, it works and I'm grateful to somebody for posting it but we had no idea how it works. So we wrapped 2 tests around it (one where the point is not in the polygon and another where it is...
Read more