There are three issues with this question.
Lines of code is a terrible measure, especially with the assumption that more lines is better than less.
Imagine two students who are asked to solve the same problem.
One starts writing code, and during the entire exercise, writes more and more of it, never reading it. At the end of the exercise, the code base is full of:
- Dead code (code which is not used at any point),
- Code duplication due to Ctrl+C/Ctrl+V abuse (one of the most important issues in software development),
- Plain duplication because of the lack of organization (the method is written from scratch, while the pretty same one exists in an other class),
Stupid comments such as:
// Concatenate the first and the last name.
string displayName = this.firstName + " " + this.lastName;
Pieces of code which should have been inlined, such as:
int age = this.Age;
int threshold = this.Threshold;
int temp = age - threshold;
int limit = 3;
if (temp == limit)
bool tmp = temp > limit;
if (tmp == true)
which should have been as simple as:
int ageWithoutThreshold = this.Age - this.Threshold;
return ageWithoutThreshold >= MIN_AGE_TO_APPLY;
Another one adds new lines of code carefully: more code means more sources of errors. He regularly refactors the code, architectures it properly to be able to find very easily which method should be put in which class, avoids code duplication, and, in general, tries to do what is required to solve a given problem, and nothing more.
Which one should have a better grade?
2. Working program
What is a working program? How to determine whether it works or not?
If a working program is a program which has no bugs, then there are practically no working programs in the world (a few use formal proof to be able to guarantee that the code doesn't have bugs, but I can hardly find an example of such program).
If a working program is a program for which no bugs are known, then the spaghetti code I urgently wrote this morning is a working program. I haven't compiled it yet, so I'm unaware of any bugs, even if I'm pretty sure that such terrible mess would take weeks to correct.
If a working program is a program for which every requirement has a functional test which passes, then what do you do with most code base which is grown organically, often with no written functional and non-functional requirements, and no functional tests?
If a working program is a program that is assumed to work by the author, then the answer to the question is pretty irrelevant. I assume that an app of 5 000 LOC might work. So what?
3. Program ≠ system
Most large systems are assembled from smaller programs, often presented as web services. For example, a CRM may rely on a REST API for authentication of users, or on another API for the management of documents, or on a third API for the upload of the documents.
Those systems are not programs.
For a web developer, for example, it makes no sense to talk about a large program. It would even be alarming to see a web developer being proud of creating a single large program: a set of small services would need much less maintenance.
Using metrics to have an idea of a familiarity of a developer with a language doesn't make sense. I've already explained why LOC measure is wrong. Let's consider a few other measurements.
Years of professional experience
I've spent two days working on a C# project doing work so basic that a monkey could do it. Does it make me more experienced in C# than somebody who haven't spent two days doing the same thing?
Take a young, not very smart coder who have spent five years doing e-commerce websites again and again using Ruby. Now take a talented software developer who, until now, worked only with Assembler, C, C++, Java, Haskell and Python. Two weeks ago, he started to learn Ruby. Who is more valuable for a company looking for a developer for a Ruby project?
Years of professional experience is a meaningless measure; the fact that HR department loves it so much makes it extremely dangerous.
Number of projects
The same arguments apply here. I can spend a year doing e-commerce websites, again and again. Or I can spend a year working on a technically-challenging project where I do learn stuff.
Sadly, this metric is popular among HR people a lot too.
So, how to measure the experience of a developer in a given language? Through a systemic approach, by considering multiple factors, without transforming them into metrics:
- Implication of the person in the community, including contribution to open source projects,
- Projects which were actually sold,
- Open source projects which became popular,
- Writings (publications, blogs, etc.),
- Participation to the conferences,
- Personal motivation,
- Ease of speech when it comes to explaining language quirks and dark sides,
- Awareness of language pitfalls and drawbacks compared to other languages,
- Knowledge of tools related to the language or ecosystem (debugging tools, testing, continuous integration, continuous delivery, etc.),