@Code_Dark said:
@tofu said:
So my question is, what should I say as to the size of this project on
my resume?
Well, I could definitely be wrong, but what I'd do is not state the actual size of the project;
I worked as a Quality Lead for a couple of years and we ran into this sort of LOC babble too often for comfort. One of our pet peeves was that Management kept claiming that QA should be finding N bugs per M lines of code.
Several things are wrong with concentrating on LOC:
1) If you tell an engineer something like "we expect N bugs per M lines of code" any competent engineer will comply. If necessary, s/he will insert bugs. Similarly, if you say you expect X lines of code output per day, the developer will figure out how to give you what you expect. The code may not be tight, or tested, but by golly you'll get X LOC/day.
This is not what you want. Stay away from LOC as a metric.
2) Management got that particular bugs per loc "metric" from some research on C code. We were writing C++.
Language matters. One line of Perl, Python, or Ruby may equal many lines of C or hundreds of lines of Assembler.
3) Software engineers and programmers have to do many things: Design, Code, Test, Debug, Document, Redesign. And, many times, you have to Stop and Think — take your hands off the keyboard — think about about design, about algorithms, about the Right Way To Do It. Some days you can churn out code (oh, but that's just a giant case statement). Other days, you write one small, tight, elegant, recursive function.
LOC is a tiny, nearly unimportant, aspect of what you do.
Don't tell me how many LOC you wrote. Tell me what you did.