lines of code?

[Paavo P]

count expressions
count statements
count blocks
count all lines
count commented lines
count files and directories
ignore empty lines

Use Perl ; )

 

[nos]

one value is in planning
if you have an estimate of NCSL
you can map that to class size
which can be mapped to memory size on the target hardware

 

[Harald Hein]

It really isn't
useful for anything.

Well, the original poster has a useful, non-technical application:
Convincing some HR mamager to hire him.

 

[Eric Sosman]

I have two questions about the metric of 'lines of code':

1. How do you actually count this? On a Unix box, I can run 'wc -l'
to get the lines, but of course this includes comments and blank lines.

2. What is a fair number of lines of code in a one-man project that
would show decent proficiency (i.e. for a job interview)?
5000? 10,000? 100,000?

Programmer Number One writes one thousand lines of code:

x[0] = 42;
x[1] = 42;
x[2] = 42;
...
x[999] = 42;

Programmer Number Two writes two lines of code:

for (int i = 0; i < 1000; ++i)
x = 42;

We can easily calculate that PN1 is five hundred times
as productive as PN2, so PN1 is the person we'll hang on to
during the next round of layoffs. Right?

In other words, it's not how many lines you write, it's
*which* lines you write. True story: A programmer working
for me once spent two and a half days chasing a bug that (it
eventually turned out) arose from an unfortunate interaction
between our code and a previously unsuspected race condition
in a vendor's X server. He worked around the X bug by changing
one line in our code -- and I did *not* try to measure his
productivity as "Two lines per week."

 

[Joona I Palaste]

Eric Sosman <[email protected]> scribbled the following

(snip analogy)

In other words, it's not how many lines you write, it's
*which* lines you write. True story: A programmer working
for me once spent two and a half days chasing a bug that (it
eventually turned out) arose from an unfortunate interaction
between our code and a previously unsuspected race condition
in a vendor's X server. He worked around the X bug by changing
one line in our code -- and I did *not* try to measure his
productivity as "Two lines per week."

*I* once fixed a similar bug by changing < into <= or the other way
around. Can't remember which way it was.

 

[Digital Puer]

In other words, it's not how many lines you write, it's
*which* lines you write.

I agree completely, but my original purpose for using this metric
was simply to give a number to the job interviewer to show that
I'm proficient in coding for a particular language. For one
company, they made me fill out a datasheet with how many lines
of code I'd written for a project in C, C++, Java, etc.
I don't particularly like this, but what can I do.

 

[Eric Sosman]

I agree completely, but my original purpose for using this metric
was simply to give a number to the job interviewer to show that
I'm proficient in coding for a particular language. For one
company, they made me fill out a datasheet with how many lines
of code I'd written for a project in C, C++, Java, etc.
I don't particularly like this, but what can I do.

My advice would be to give a number only if pressed.
Try to turn the conversation away from "How many lines"
and toward things like "How many projects" and "What was
hard/interesting/educational about this or that project"
and "What would you do differently if you had it to do
over again."

At least, that's the sort of question I always liked
to discuss when I was hiring programmers. If someone walked
in and said he was the author of umpty-skillion KLOC I could
learn very little about his abilities. But if he could give
an opinion on *why* XYZ Designer Studio was better/worse
than ABC Frame Fabricator, except that ABCFF had this one
neat feature he wished XYZDS had because when he used it
in debugging the following weird problem ... *Then* I knew
I was talking with someone who had actual experience.

 

[Tim Ward]

For one
company, they made me fill out a datasheet with how many lines
of code I'd written for a project in C, C++, Java, etc.
I don't particularly like this, but what can I do.

What you can do is take such daft requests as an indication of what this
potential employer might be like to work for, along with the other things on
your checklist like whether the interviewer offers you a cup of coffee,
whether you see people smoking in the building etc. (I once attended an
interview where the secretary brought the interviewer a cup of coffee and
didn't offer me one. He lost the interview at that point - there was
obviously no way I was ever going to work for him. However I decided to sit
through the rest of the interview rather than walk out at that point because
I was short of cash at the time and needed the travel expenses.)

 

[Joona I Palaste]

Tim Ward <[email protected]> scribbled the following

What you can do is take such daft requests as an indication of what this
potential employer might be like to work for, along with the other things on
your checklist like whether the interviewer offers you a cup of coffee,
whether you see people smoking in the building etc. (I once attended an
interview where the secretary brought the interviewer a cup of coffee and
didn't offer me one. He lost the interview at that point - there was
obviously no way I was ever going to work for him. However I decided to sit
through the rest of the interview rather than walk out at that point because
I was short of cash at the time and needed the travel expenses.)

I would have not made such a fuss about it, but I have to agree that
the secretary and the interviewer were very rude.

 

[Tim Ward]

I would have not made such a fuss about it, but I have to agree that
the secretary and the interviewer were very rude.

Point was, if that was how they treated interviewees, whom they were trying
to impress and to whom they were trying to sell the idea that this was going
to be a good place to work, how the **** were they going to treat their
employees when they're no longer trying to sell to them?? No thanks!

Certainly I learnt from that, when I became a manager and interviewer, to be
very careful how interviewees were looked after. And to emphasise during the
interview process how well the staff were looked after. So I did actually
get something useful from that experience.

 

[Michael Hurst]

If I was in an interview and someone asked me how many lines of code I
had written, I would have ask them why they would want to know
something so insignificant. I would tell them that mabe they should
be asking me how many projects I have worked on. They should ask me
problem solving questions to see how my mind works. If two people
write identical programs and one takes 15 lines of code and the second
takes 150 lines of code, which is the more effective programmer? So
when I read that people have written programs that take 10,000 lines
of code and try validating their abilities as a programmer I say the
number of lines of code that one writes has no bearing on skill. It
is the quality of the project, the runtime speed, and the efficiency
of the code and the language that is used that will dictacte skill.
You can't judge that from how many lines of code someone writes. You
can only judge whether someone is good or not by digging in their
code. If I had been in that interview, I would have suggested to the
interviewer that they had no business interviewing someone for a
technical position. A compentant interviewer would have never asked
an interviewee to write down how many physical lines of code they have
written. They would have said, show me some of the programs you have
written. Tell me about some of the problems you have solved. More
than likely the position would have gone to someone who would have
politely answered the question. I am guessing the interviewer must
have gotten their position through the good ol boys network of knowing
someone who could get them their job regardless of the lacking
appropriate credentials. Just a guess though.

 

[Richard Harter]

If I was in an interview and someone asked me how many lines of code I
had written, I would have ask them why they would want to know
something so insignificant. I would tell them that mabe they should
be asking me how many projects I have worked on. They should ask me
problem solving questions to see how my mind works. If two people
write identical programs and one takes 15 lines of code and the second
takes 150 lines of code, which is the more effective programmer? So
when I read that people have written programs that take 10,000 lines
of code and try validating their abilities as a programmer I say the
number of lines of code that one writes has no bearing on skill. It
is the quality of the project, the runtime speed, and the efficiency
of the code and the language that is used that will dictacte skill.
You can't judge that from how many lines of code someone writes. You
can only judge whether someone is good or not by digging in their
code. If I had been in that interview, I would have suggested to the
interviewer that they had no business interviewing someone for a
technical position. A compentant interviewer would have never asked
an interviewee to write down how many physical lines of code they have
written. They would have said, show me some of the programs you have
written. Tell me about some of the problems you have solved. More
than likely the position would have gone to someone who would have
politely answered the question. I am guessing the interviewer must
have gotten their position through the good ol boys network of knowing
someone who could get them their job regardless of the lacking
appropriate credentials. Just a guess though.

[snip]

And if I were the interviewer and you had answered like that I would
have checked you off as a twit with an attitude problem.


Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
A man with money is always charming - pomposity is just
an eccentricity, forgivable in the rich.

 

[Joona I Palaste]

Richard Harter <[email protected]> scribbled the following

If I was in an interview and someone asked me how many lines of code I
had written, I would have ask them why they would want to know
something so insignificant. I would tell them that mabe they should
be asking me how many projects I have worked on. They should ask me
problem solving questions to see how my mind works. If two people
write identical programs and one takes 15 lines of code and the second
takes 150 lines of code, which is the more effective programmer? So
when I read that people have written programs that take 10,000 lines
of code and try validating their abilities as a programmer I say the
number of lines of code that one writes has no bearing on skill. It
is the quality of the project, the runtime speed, and the efficiency
of the code and the language that is used that will dictacte skill.
You can't judge that from how many lines of code someone writes. You
can only judge whether someone is good or not by digging in their
code. If I had been in that interview, I would have suggested to the
interviewer that they had no business interviewing someone for a
technical position. A compentant interviewer would have never asked
an interviewee to write down how many physical lines of code they have
written. They would have said, show me some of the programs you have
written. Tell me about some of the problems you have solved. More
than likely the position would have gone to someone who would have
politely answered the question. I am guessing the interviewer must
have gotten their position through the good ol boys network of knowing
someone who could get them their job regardless of the lacking
appropriate credentials. Just a guess though. [snip]

And if I were the interviewer and you had answered like that I would
have checked you off as a twit with an attitude problem.

Employee does not want to work in the company, because he thinks
employer doesn't understand software engineering - employer does not
want to hire employee because he thinks he has an attitude problem -
just don't sign any contracts and we're all happy!

 

[nos]

if you give a number that is too big you loose your credibility
kind of like saying you built a log cabin by yourself in two weeks

 

[nos]

a secretary should never fetch coffee for his boss

 

[Tim]

I would just say "I've never really taken notice of the number of lines.
Why do you ask?".
If he insists, tell him some of the classes are probably over 100 lines
of code but many are not.

 

[NahtMy ReelName]

What a load of crap from a bunch of whiners.
Most of the replies in this topic are wheedling responses
about how one can manipulate "lines of code" related metrics
and why less is more. You should all be laid off as overpaid
watercooler yakkers. Hell, I bet you're reading this right now on work
time you lazy bastards.

Sure, it can all be manipulated. But in response to the original
posters question:

"wc -l" is a one perfectly valid and useful metric for tracking
both progress on a coding project and for tracking the complexity
of the code. So are some of the other proposals (semicolons, etc)

Having hired literally dozens of people in demanding startup
environments, I've certainly asked people about what sort of volume
of code they've produced on their more complex projects. Why? Because
if they can't crank out at least 1,000 lines of debugged code a month
they're not qualified to do jack shit on some of my projects.
(Though they may be well qualified for other projects)

Obviously project contexts vary. A complicated existing body of code
confronted by a new programmer will have a less productive code curve.
And sure, there are issues of refactoring (which every good programmer
had better be doing). Similarly, the programming language used and
application domain can vary a lot too. Parallel programming has more
complexity than single threaded computations. C++ requires more code to
get a task done than Java. The list is endless.

When evaluating a programmer for capability and experience, if the
developer can't crank out
6-12kloc (with comments) in 6 months then we can start to categorize
the programmer for suitability to particular projects. In this case,
the programmer isn't someone I'd put on a mission critical new coding
project. I'd put them on something with less risk and time demand,
and I'd also pay them less than I'd pay a more qualified candidate.

Being a slower, or less experienced, or a less capable programmer isn't
a sin. It's important to set expectations appropriately. Really good
engineers can product 500-1000 debugged lines of code a DAY on a good
day. And good engineers can also crank out meaningful project
schedules, design documents, unit tests, and other things besides the
basic code.

As an interview candidate, you need to make sure that what you can do is
clearly understood by a prospective employer so that you're not getting
in above your head. It doesn't mean you won't get a job. It means
you'll have a better chance of getting the RIGHT job. And maybe,
with a series of the RIGHT jobs, you'll be one of those 500-1000 loc/day
coders someday too.

And there's a perfectly good market for people who never tweak more
than few lines of code a day as well. Different people bring different
skills to the table. Some people are good at reading existing code
and fixing it, without huge code output. Some people good at writing
lots of new code are BAD at reading existing code. (And some people who
can write a lot of code should NOT, because they write crappy code).

"wc -l" is useful as a progress indicator and rough rule of thumb.
I'll ask a candidate how much code they wrote on a project they're
particularly proud of as an accomplishement. If their net project
contribution
is ~10kloc+ in < 1 year, then I know they've probably crossed a certain
threshold
as a programmer that many programmers will never cross.

If they only produce a few hundred lines here and there, I wouldn't
hire them for new product development in a startup, but that doesn't
mean I wouldn't hire them. It means I'd consider their talents for the
jobs I have open and try to match them accordingly.

And if a programmer spent as much time making excuses as most of the
people in this topic did, the interview would be short. Better that
than hiring and firing someone because of a mismatch in expectations.
That's not good for the employer (late project deliverables), or the
employee (stigma of firing, depression, etc).

Productivity matters. So does quality, complexity, and dozens of other
factors. Asking about "how much code" doesn't make a bad interviewer.
It's just one metric for measuring
a person's skills. If it was the only metric used then the interviewer
wouldn't be good, obviously.

Note to the original poster: showing a 10kloc task is good. But it's
more credible if it finds its way into a revenue producing product or
infrastructure than if it's just something like a 10kloc script or pet
project. Some 10k lines of code are a lot easier to write than others.
Hopefully the interview discusses the nature of the code and context of
the project. How much design was required. What was the level of design
complexity. What safeguards were placed in the code to ensure correct
operation and also correct maintenance down the road. 10kloc is useless
if it isn't maintainable by people other than the original author.

Trolling or valid point of view, you decide

 

[Tim Ward]

Having hired literally dozens of people in demanding startup
environments,

Just to give us a clue, how many of these startups are now running
profitably, and how many failed one way or another?

 

[Joseph Dane]

Trolling or valid point of view, you decide

hmph.

once it becomes known around your shop that you value LOC as a
metric, your developers will play you like a cheap fiddle. this may
not help the clueless interviewee, but it probably doesn't do much
for the quality of the code you produce, either.

 

[Joseph Dionne]

First, you hiring developers or word processors.

if
(
iWereWorking
==
you
)
{
printf(
"%s\n",
"I would use many lines"
);
}

;-)


Since developers are always trying to do more with less code, ya know "I
can write that in 2 lines of code," then perhaps you should be looking
for a more qualitative way to analyze skills.