I Built His Cage

Announcer: Now for quick hits and commentary on software development topics from around the web, the EIP web-ring brings you the stigmatized spawn of a refactory, MoffDub, and Helltime!

Well well well, it finally happened. Yes, this is a Friday edition of Helltime. You know I spoil you.

• There’s another good post at the Making Good Software blog by Alberto Guitierrez speaking to the constant threat of obseletion hanging over the heads of developers across the industry. It’s a short post, but the gist of it is here:
  

  what makes a great software developer is not only his ability to learn and adapt but also going one step ahead of those who just do the necessary for not becoming obsolete..

  In other words, you have to have a passion for writing code and solving problems. You have to be sick enough to enjoy this stuff. If you’re not, then get out of the way for people who do.

• With all my fluttering over double dispatch, which is a mere generalization of the Visitor pattern, it was a no-brainer to check out an entry by Matej Tymes on the Extended Visitor pattern. The classical Visitor pattern uses no generics and have void return types. The Extended Visitor pattern generalizes the return type and adds an extra parameter to the visit methods.

  I get it, though I don’t see when I’d ever need this pattern, much less the actual Visitor pattern. I have always found the nomenclature of the Visitor pattern very confusing. It is much easier if you get specific and match the terms to your domain: RopeWriter instead of Visitor, RopeNode instead of Element, writeOn instead of accept, and write instead of visit. Even now, I’m not totally sure I have this analogy correct.

• I am intrigued by pair programming, if not a little skeptical, so when Alan Skorkin highlighted effective vs. ineffective pair programming, I had to take a read.

  Skorkin examines four pairing situations driven by the degree of knowledge each person has of the system under development. Personally, I have been in all four situations. Today I was in the situation where the driver (at the keyboard) had little knowledge and the navigator (not at the keyboard) had a lot of knowledge.

  I had to think about the conclusion that the person with the most knowledge should be the navigator. I find this simultaneously enjoyable and difficult. I enjoy it because I like having seniority and experience for a change, but I hate it because sometimes I find myself in situations where I could get the job done in twenty minutes by myself instead of the two hours spent with a rookie.

  I simply need to accept that I’m getting old. I’m an old man, and I need to start handing my knowledge off to the young’uns before my flame dies out at 30.

  Announcer: You’re reading the EIP web-ring.