My favourite interview question for developers is "How many lines of code have you deleted?" Lots of junior developers boast about KLOC they have written. But the more code, the more bugs. I'm interested in knowing if the developer has lived with code, not just shipped it and moved on to the next project.
I'm both a programmer for and an administrator for network infrastructure at my university. So the code that I deploy I have to live with. A lot of it was written before I got there and I probably really have deleted just about as many lines as I have written. Decade-old Perl code usually needs to be updated. And now with us switching to IPv6, a lot of things need changing.
Think about it. In order to write 300 good lines of code, you probably wrote 1,000 lines of code before refactoring. Same thing, just that someone else put in all the refactorable lines before you got there.
It's a pretty useless metric. How many lines of code did the people who invented quicksort (pick great algo of your choice) write in their first implementation? It's certainly important to have some minimum # so you can say you know what writing software is like, but imho judging by counting lines of code is roughly equivalent to judging mathematicians by # of lines in their proofs... that is to say, totally ridiculous.
I brought this up to show that the I have received 10x the education from the code I have written professionally than from all my formal schooling.
I realize as well as anyone here that the best code usually have less lines. At least mine does. But "years of experience" has less meaning, believe me. So do title, company, number of jobs, number of customers, etc., etc., etc.
Just like in basketball, there is no substitute for height, in programming, there is no substitute for actually having written code.
I realize "Lines of Code" isn't a great metric, but it's probably the best to quickly communicate my point.
I think it's just too difficult a problem to distill down into a single metric. I did CS and Math for my undergrad and I was in the PhD program for CS but left with my MSc. My focus was on design and analysis of algorithms and based on that training, in my 3 years of professional activity (2 at a NASA contractor) I've run into very few problems that compared to the kind of work I did in my thesis. I think lines of code is one metric - but a really high number could actually be a sign of a really bad programmer! So, it's an inherently noisy signal. I think you have to look at successful projects completed and individual roles in those projects and judge that way.
It's not about lines of code it's about the number and type of problems solved. I have spent days looking for a solution when all I needed to do was change a single constant. I have also written hundred of lines of code whole hog, been surprized that it compiled without errors, and shocked that it was bug free. Yet, I have no idea what was more usefull.
Spending a few months working on hard problems without a functional debugger can compleatly change how you aproach programming. But, so does finaly understanding how to use a debugger. Spending a few weeks reading other peoples code to document a working system was also an incredably valuable experence.
PS: The closest thing to a single nuber I can think of is "how many diffrent months of experence do you have?"
