While lines of code are being abused a lot, I disagree with the fact that you should forget about them and not learn about it in college.
The number of pages of a book is actually a pretty decent indication (or at least a relevant factor) when looking at how much time it took to write the book, how much space it will occupy on my shelve and how much it will cost. Of course, these apply as averages - individual books will always stand out. Similarly, lines of code gives a very useful indication (or is a relavant factor) of how long it took to write the system, and how much time/money it will cost to maintain the system, or how much time it would cost to rebuild it. These may not be relevant for day to day programming work, but as an architect or team lead, these do come in handy.
Even if you look at quality, which you single out, it turns out that many software quality metrics correlate strongly with lines of code. On average, a larger system will be more complex, have more code duplication, etc. (relatively speaking, not just absolutely). And that's not just a "crazy, unbelievable theory", but has been tested and observed looking at a large volume of systems. (I used to work at a company investigating this - read this book if you're interested).
There are of course many caveats when using this metric - comparing lines of code in different technologies can be very troublesome if not done well, for example. Such difficulties contribute to the lines of code metric often being abused and, in turn, derided or despised. But then again, that's not really different from any other metric you'll encounter. If those using it don't understand and use them properly, it's pretty much useless. And that's actually a lesson I wish I had learned in college...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While lines of code are being abused a lot, I disagree with the fact that you should forget about them and not learn about it in college.
The number of pages of a book is actually a pretty decent indication (or at least a relevant factor) when looking at how much time it took to write the book, how much space it will occupy on my shelve and how much it will cost. Of course, these apply as averages - individual books will always stand out. Similarly, lines of code gives a very useful indication (or is a relavant factor) of how long it took to write the system, and how much time/money it will cost to maintain the system, or how much time it would cost to rebuild it. These may not be relevant for day to day programming work, but as an architect or team lead, these do come in handy.
Even if you look at quality, which you single out, it turns out that many software quality metrics correlate strongly with lines of code. On average, a larger system will be more complex, have more code duplication, etc. (relatively speaking, not just absolutely). And that's not just a "crazy, unbelievable theory", but has been tested and observed looking at a large volume of systems. (I used to work at a company investigating this - read this book if you're interested).
There are of course many caveats when using this metric - comparing lines of code in different technologies can be very troublesome if not done well, for example. Such difficulties contribute to the lines of code metric often being abused and, in turn, derided or despised. But then again, that's not really different from any other metric you'll encounter. If those using it don't understand and use them properly, it's pretty much useless. And that's actually a lesson I wish I had learned in college...