LOC is probably one of the most abused metrics, and as a result is probably one of the more useless measures of code quality, and an even more useless measurement of programming effort.
Yes, that's a bold statement for me to make, and no, I can't point you to studies proving my point. However, I can state with hard earned experience that when you start worrying about how much code you've written, you're probably worrying about the wrong problems.
You first need to ask yourself what it is you are trying to measure or prove, and whether this proof is merely out of interest, or to support a wider quality improvement and where you need to use this information to get buy-in from your team/management to do something about it.
One of the things that I tend to use LOC for is a bit of a sanity check. If I find myself writing a lot of code, I become more interested in LOC per method, or LOC per class, rather than LOC over all. These measurements might be indicators that you have further refactoring to do if you're feeling a little OCD about how well factored your code should be. Very large classes might need to be refactored into a few smaller classes, and long multi-line methods might need to be broken down into several methods, other classes, or may even indicate some repetition that could be removed. Notice I used the word "might" several times there.
The reality is that LOC provides only a possible indicator, and no real guarantee that your code may need to change. The real question to ask is whether the code behaves as required and as expected. If so, then your next question is whether or not you will be able to maintain the code easily, and whether you will have the time either now or in the future to make changes to working code to reduce your maintenance overheads in the future.
Often, lots of code means that you will have more to maintain later, but sometimes even well-factored code can stretch out to hundreds of lines of code, and yes, you can sometimes find yourself writing hundreds of lines of code in a day. Experience however tells me that if I am sustaining an output of hundreds of lines of new code each day, that often there is a risk that much of the code has been inappropriately cut and paste from somewhere else, and that in itself may indicate problems with duplication and maintenance, but again that is no guarantee, so I tend to rely on what my experience and instincts tell me based on how the tasks at hand were completed.
The best way to avoid the dilemma posed in your question IMHO is to forget about LOC, and refactor ALL of the time. Write your code test first, implement to fail, refactor to pass, then see what may be refactored there and then to improve the code. You'll leave the task knowing that you've double-checked your work already, and you won't be so concerned about second-guessing yourself in the future. Realistically speaking, if you use a test-first approach as I've described, any LOC/day measurement on your completed code will really mean you've written 3-5 times the measured amount, with that effort hidden successfully by your ongoing refactoring efforts.
