One of my favorite sayings about programming is that it is easier to write code than it is to read it.  I've generally found this principle to be behind a number of common problems in game (well, generally software) development.  The most straightforward impact is that it causes a lot of code to be rewritten rather than refactored.  There are literally books and books on this subject out there, but I tend to fall into the "refactor whenever possible" camp.  While rewriting may in fact be justified on some occasions, it is in my experience more often used as a crutch -- because understanding the existing code at a deep level is an awful, lot of painstaking and complex work.  Even though the net time invested is much higher, rewriting a system from scratch (and then debugging it over months and years) is "fun" work while tediously poring over thousands of lines of cryptic code is not.  Certainly job satisfaction is an important aspect of this sort of technical decision, but it's always important to not put personal motivations ahead of the right decisions for the project.

Another problem is that it can lead to "not invented here" syndrome.  Understanding the pros and cons of an externally provided piece of software is virtually nothing but reading code.  You typically can't ask the person who wrote it for help in any meaningful fashion, but instead must go the full "archaeological" route, divining secrets by poring over the papyrus scrolls that contain the source.  Even if you're lucky enough to have good documentation, it is only occasionally relevant to helping you correct errors that are inevitable in using such code.   

Ironically, I actually spend a lot of my time reading code as part of my day to day work.  Fortunately reading changes in a codebase one is intimately familiar with is much, much easier than deciphering code "cold".  As the lead programmer I feel it's my responsibility to be up to speed on everything happening in the codebase, and doing a quick scan through every change that gets checked in is a very useful tool towards that end.  It is no substitute for good communication, of course, but it is a great jumping off point to recognize a particularly clever solution being built or identify architectural conflicts before they become wide spread. 

Some days, like today, it's all I can do to keep up with code being checked in -- our team has really been on fire the past few days and has been cranking out some great stuff.  Combine that with a day full of meetings for me and it becomes a race between the Perforce changelist and my Outlook inbox as to which will overflow first.  I'm not complaining though, as that level of activity indicates a whole lot of good game development going on which is really the point of the exercise.