It varies on project to project. Personally I deal with many smaller modules that are simple to comprehend at the source file level. Unfortunately I have usually worked on projects where everything was stuffed into a single monolithic file which I get lost in really quickly. Others are better at remembering details...not me...I prefer abstractions and tying everything togather at a higher level in my head. I like charts and graphs not endless lines of source code to step through. What any manager has to understand is that when first entering a codebase (without extensive documentation) you are essentially re-writing it without the concern of debugging or testing for errors. So if 1000 lines takes you a 2 days to hammer out bug free and testing/debugging account for 2/3 than reading and absorbing 1000 lines should take you roughly around 10 hours to understand 1000 lines. Assuming those 1000 lines are all you need to concern yourself with, your good to go. Unfortunately most programs are not "designed" they are "developed" from scratch using ad hoc methods that result in hard to read code, coupled with zero or minimum documentation (API documentation does little for learning a system and they are frequently outdated) this makes comprehending a codebase more than 100 lines (yes I said 100) anything BUT trivial. Clients, project managers, hot shot developers, all need to stop thinking this is a reality...code cannot just be learned and changed, especially if you expect quality work to be done.
I'm finding the only constant in software development is change it self.
