There is a set of skills and body of experience that applies to working on large bodies of code. In fact, there are different skill sets for working on bodies of bad code and good code.
The language syntax may be the same, but programming approaches might be very different. I've seen parts of a Smalltalk program where it was coded like spaghetti copy-paste Fortran, and it's actually hopeless to try and fully understand the semantics and still meet your deadline. But I was able to use a few tricks to prove that certain modifications wouldn't alter other functionality so I could get my work done. In the same program, there was well factored code with a nice object model, where it would behoove you to understand the part you're working on in a more conventional way.
On reflection, I think you may be right that good code is good code. Size of the system matters most when the code is bad.
