Density of Meaning in Code

If you're in the tech field, chances are you've heard the statistic that industry programmers average 3 lines of code per day. If you're in school, you don't believe it. But, let me tell you, in school, I had no trouble cracking out a thousand lines of code in one day, like many CS students. Now, I work at Microsoft, and yeah, I probably average 3 lines of code per day. I got to thinking about this a couple of weeks ago, when I spent more than half a day tracking down a bug that I fixed by moving one line of code down 100 lines, into another function. Not only did this work, it was probably the best way to fix the problem (that feature has since been tested and found to have no bugs). I mentioned this to one of my coworkers (who's a great coder), and he said we should be doing more of that kind of fixes, because it usually means you've understood the real problem, rather than just trying stuff until the issue magically goes away, and never knowing why.

This seems to be a property of large systems: the bigger the code base, the more effect you can have with a given number of lines of code. In fact, I'd argue that this is part of the nature of coding: the first time you need to create something (a window, say), you have to create the entire thing (lay out the window, add all the styles, etc). The second time on, you can just make another one of what you already have (you can make arbitrarily many windows with just a for-loop calling the constructor). It's a property of electronic things that once they exist, they're easy to copy. This manifests in code as being able to do more and more, the more code you have. Each line can do more, and thus means more, in the sense of having more semantic/visual/effectuality significance. The density of meaning increases as you have more code.