The potential gains of many projects often can't cover the costs associated with them. Before you read the following, please consider that programming is a lot more than simply uninterrupted time spent on typing on the keyboard. Yet, this is what "added value" looks like and this is what people expect from us. But the amount of code written is not a good indicator of the worth of a software project.
We already know that every feature has a cost. Writing more code costs us more time in reading it, understanding it, reorganizing it and editing the infinite world of single letters. When the code size grows linearly, we start to spend exponentially more time on it. The probability for bugs increases as well. This means that the potential gains from such a project must rise at least as fast to compensate for the increased cost. This is especially important with large projects where it becomes increasingly intransparent how, when and where programmers are altering the code base. Trying to visualize this may be helpful, but the main point here is that each line of code has some average worth that we could try to quantify.
Suppose that project A is 10000 lines of code and we get 50$/month from it while project B is 5000 lines of code and we get 25$/month from it. Unfortunately, we don't have enough time (or programmers) to support both, so we need to discontinue one of them to be able to fully concentrate on the other. Which one would be better to keep? If we divide what we get by the number of lines of code, we would come to an average payment per line of code. Is this a useful metric? Possibly, because we want to reduce the amount of code we write for which we aren't getting paid and also how much time we spend on low-value activities. In this case, the result for both projects would be 0.005$/line of code, but we would probably prefer to keep the project with the lower complexity if other factors are equal. In other cases the project that pays more per line of code would be more interesting.
This leads us to an issue: lack of awareness. Even when we can write many lines of code, we have to be constantly aware how valuable they are and discard the ones that aren't. Typing a lot, but doing trivial things is less desirable than typing little and embedding a lot of intellectual work into every single line. The smallest material unit is the single line; many weak lines quickly weaken the overall construction. When we are asked to implement many special cases and we never question this or discuss how this can be avoided, our lines of code quickly grow and the idea of the whole becomes hard to trace. We need to be aware of the lines if we don't want to discard the whole later.
This may seem an overly simplified model, but it can still be useful in determining the types of projects to work on in the future. Sinking into large codebases, where the clients have expressed no concrete interest in the product, is likely connected with low payment per line of code—something which is to be avoided as much as possible.