I have read this essay a few times, and I think that steve is missing an insight into modularity. We should be writing libraries for ourselves, not just piling code on top of other code. As an argument, I first offer a few propositions.<p>Any code upon which your project relies can be considered "part of the code base". As an example from Rails, it has become a somewhat common/accepted practice to notice a deficiency in a gem, fork it on github, fix it for your needs, and use it. This is especially common if your project depends on abandoned gems that you still need to use, for whatever reason. Even if this isn't a problem, I often need to look into internals to figure out where something is breaking.<p>Then, if code that your code depends on is considered part of the project, if steve was correct, then it would be very hard to use anything more advanced.<p>However, practical wisdom shows that higher level such as Ruby are more productive than lower level languages, such as C. Thus, the original premise is shown false.<p>If the original premise is false, then what is it that steve is noticing? I think it is about leaky abstractions. If you write libraries for yourself, with good, clean interfaces, you do not need to "notice" the lines of code from other parts of the project.<p>tl;dr It's about creating abstractions for yourself, not pure LOC count.