American Programmers are Slackers 584
Amigan sent us a
"Story on the CNN website how that in a world wide
survey of programmers, American programmers are
half as productive - based on Lines of Code generated!"
Allright, I'm lazy, but in Perl thats ok. I find LOC a shoddy
indicator of programmer laziness, but those numbers
seem low- I mean, I probably wrote 15,000 lines of code last year,
ran Slashdot, and was a full time student. I gotta put up
a poll.
Is this IBM and K-Locks all over again? (Score:1)
-AC
US LOC's != non-US LOC's (Score:1)
This was all very true based on the LOC counts that each side tracked.
Finally someone decided to look in to how each side determined what 1 LOC was. Turns out Japan pretty much counted any line in a file, including comments, were as in the US we were using a much stricter definition, closer to counting each ";".
After recalculating it turned out US side had a better bug-to-LOC ratio with slightly less LOC (just means higher performance code as well).
This is plain, simple, and unadulterated bullshit. (Score:1)
LOC is absolutely positively the *WORST* means of evaluating programmer performance. At times, both I and my colleagues have had *NEGATIVE* lines-of-code-per-week values. This stemmed from another department linking LOC to bonuses, encouraging their programmers to use cut-and-paste programming. After all, why call the same routine twice when duplicating that routine will increase your bottom line...
Needless to say, that department's project became, in a matter of months, completely unmanageable and uncompletable. And there was a great deal of celebration in that department when the client canceled their contract without suing us...
Hint: If you see this happening at your company, it means: Circulate your Resume NOW!
Another factor that may have been completely overlooked is what American programmers are doing besides writing code. How much time is being spent in meetings, demos, support, answering the phone, systems administration, debugging third party software, installing/configuring *ANYTHING* made by microsoft, etc. Perhaps more importantly, how much time is being spent in **DESIGN**. Since, with Object-Oriented approaches, the vast majority (more than half) of your time better be spent in design. If not, well, you're in for a lot of pain, suffering, and cost overruns...
Finally, what are working conditions like? Modern offices are *NOT* optimized for writing code! They are optimized for managing underlings!!
There's a test that I like to give managers. I ask them to count backwards from 100 by 3's. Then, after they're down to about 91, I start calling out random numbers between 1 and 100. It's a rare person who can make it to 70.
Then consider the cubicle that I was located in a while back. The partitions were transparent to sound. And the fellow on the other side of my partition was trying, very hard, to switch careers and become a sports agent. On my other cubicle wall was the hall corridor, right where it met the elevators for the floor. Across the hall, about 2 meters away, was the kitchenette. Which contained the coffee machine, where everyone went to socialize. Which was difficult for them to do because the copier was also located in the kitchenette, and they had to talk quite loudly to be heard over it. Just to insure that a quiet moment would never occur, purchasing was located in the next cubicle bay down the corridor...
I find that the same part of my mind that I use to write code is also used to process speech. But speech has a higher priority interrupt. My productivity fell through the floor...
Nowadays I work for a different company. And, do to similar problems, I now telecommute from home, where my productivity is much *much* higher...
Cultural differences account for a lot (Score:1)
In addition, lots of programmers who aren't US nationals work in US software companies. Does their productivity magically decline the instant they hit our shores?
I am biased, as I have worked on many projects with offshore programmers, and have never seen any value gained from the practice. On the contrary, it has always been an expensive process, resulting in the offshore code being thrown away and reimplemented locally at greater expense, partly because the deadline could not move even though our foreign counterparts wasted most of the schedule.
Measure twice, cut once.
You're right! (Score:1)
In general, 100 lines of my code is worth about 300 lines of the CS student's code, which is worth about 1000 lines of a tyro's code. And not surprisingly, the people who write the shortest programs also write the least buggy programs. Brevity demonstrates an understanding of the problem, and understanding the problem means you are unlikely to introduce bugs.
Code is a liability, not an asset. The more source code you write, the more bugs you will encounter, and the more problems you will have to fix later. (e.g. Y2K).
Yeah, but what exactly is a 'line of code'? (Score:2)
There 50 lines of code. I am the king of programmers and will now accept my $300,000 an hour raise.
More important... (Score:2)
I wrote my program in Perl. The hardcore coder of the class wrote his program in 'heavily optimized' C++, but didn't spot any of the algorithmic optimizations. My program operated on the sample input in a fraction of a second. His program required two days to process the sample input.
My program was 60 lines long. His program was well over 2000 lines long.
Needless to say, I consider myself a vastly superior programmer, even though his line count is much higher than mine.
All I want to know is, what organizations consider LOC important? I would like to avoid them.
Write in C (Score:1)
When I find my code in tons of trouble,
Friends and colleagues come to me,
Speaking words of wisdom: "Write in C."
As the deadline fast approaches,
And bugs are all that I can see,
Somewhere, someone whispers
"Write in C."
Write in C, write in C,
Write in C, write in C.
LISP is dead and buried,
Write in C.
I used to write a lot of FORTRAN,
for science it worked flawlessly,
Try using it for graphics!
Write in C.
If you've just spent nearly 30 hours
Debugging some assembly,
Soon you will be glad to
Write in C.
Write in C, write in C,
Write In C, yeah, write in C.
Only wimps use BASIC,
Write in C.
Write in C, write in C,
Write in C, oh, write in C.
Pascal won't quite cut it,
Write in C.
Guitar Solo
Write in C, write in C,
Write in C, yeah, write in C.
Don't even mention COBOL,
Write in C.
And when the screen is fuzzy,
And the editor is bugging me,
I'm sick of ones and zeroes,
Write in C.
A thousand people swear that T.P.
Seven is the one for me.
I hate the word PROCEDURE,
Write in C.
Write in C, write in C,
Write in C, yeah, write in C.
PL1 is 80's,
Write in C.
Write in C, write in C,
Write in C, oh, write in C.
The government loves Ada,
Write in C.
LOC = PHM stupidity (Score:1)
I worked on a COBOL-to-C conversion several years ago, using Microport 286, of all things. There were two of us, the other programmer consistently wrote about five pages of code a day, I usually delivered about 1.5 to 2 pages. After about one week there was a confrontation about the disparity. I replied that my code compiled, ran, and worked as well as could be expected with stubs substituting for missing functionality. I asked the other programmer if she could make the same claims for her code--she couldn't. Did this make any difference? No, I was outta there.
About four years later I learned that one of the best C coders in our part of the world came in right behind me and met the same fate--last I heard, he was working for the Deathstar Company in Jersey--now I don't feel so bad, but at the time I was really pissed.
"Lines Of Code" ignores issues of efficiency, complexity, suitability for purpose, and stability. If LOC were any measure of quality, Windows would be the best code known to man. LOC is a bad metric that should die an excrutiatingly painful death.
Is this IBM and K-Locks all over again? (Score:1)
The only thing worse would be paying them by the number of bugs they fix.
It's a corporate thing (Score:2)
I thought: WOW, I'm going to crush these people. They have no idea. So I got out into the real world and my first job was at Sperry (now Unisys), coding in the OS "kernel" for the series 1100/2200 mainframes -- although it wasn't really a kernel since they had never developed it along the lines of a proper OS.
I quickly learned that "14 lines per day" wasn't because these people were stupid; it was because of all the other crap that had to accompany those lines. In particular, one 500-line modification I added also required 50 pages of (mostly bureaucratic) definition and design documentation and about four months of politics.
Sperry circa 1985 is no longer a good example, but I'm sure that programmer's productivity everywhere is still completely stymied by corporate cultures that require signoffs from 7 different executive vice-presidents just to decide what doughnut selection is available in the breakroom. ("Operations is worried that powdered sugar is getting into the air vents, Personnel is angling for lower fat content to save on insurance premiums, and Steve in marketing wants them all chocolate because HE likes chocolate so therefore the rest of us should too.")
how do you count changed/replaced lines of code? (Score:1)
57 files changed, 8940 insertions, 6816 deletions
So, did I write 8940 lines or (8940-6816) = 2124 ?
Actually, since some lines were rewritten more than once I wrote far more than 10k lines during the year and deleted far more than 7k (plus I workied on side projects too). But, of course, diff thinks a change of 1 character is a change of that line.
Now when I talk about rewritting code I don't just mean getting rid of the bugs. The versions that I check into CVS are already debugged, so (usually) only contain little bugglets. What I'm talking about here is things like the changes needed to incorporate new features or redesign of some internal data structure.
If you consider the 1999 model of a car to be 1% different from the 1998 model do you then say that the engineers were working at a rate that would take them 100 years to design a new car?
--
how do you count changed/replaced lines of code? (Score:1)
57 files changed, 8940 insertions, 6816 deletions
So, did I write 8940 lines or (8940-6816) = 2124 ?
Actually, since some lines were rewritten more than once I wrote far more than 10k lines during the year and deleted far more than 7k (plus I workied on side projects too). But, of course, diff thinks a change of 1 character is a change of that line.
Now when I talk about rewritting code I don't just mean getting rid of the bugs. The versions that I check into CVS are already debugged, so (usually) only contain little bugglets. What I'm talking about here is things like the changes needed to incorporate new features or redesign of some internal data structure.
If you consider the 1999 model of a car to be 1% different from the 1998 model do you then say that the engineers were working at a rate that would take them 100 years to design a new car?
--
Perl! (Score:1)
Ugh! (Score:1)
C and C++ (Score:1)
No clue... (Score:1)
Loopholes (Score:1)
what languages did you code in? (Score:1)
Also, the people at REAL software have openly stated that, given the chance to add compatibility with VB, they won't add compatibility to features that suck
Lastly, I don't count HTML as a language, and at any rate, I wrote a REALbasic program to generate my site from text and some markup, so it's moot. In all seriousness, RB will never be any good for device drivers or calculation engines, but it's at least as good as any scripting language, and by God is it quick to prototype stuff in. Whee! Also it's not really basic, just uses some similar syntax and has the reassuring name- it's quite event-driven, does thread classes, and even has a wizzy sprite engine for fooling around with games
RB? (Score:1)
StaticText1.text="Hello World" ?
I dunno if this is the way VB does it, but it's REALbasic code, and it seems nice and straightforward. You drag the statictext onto the app window and set it up mousishly
//Heh! (Score:1)
Source: 550 lines
Comments: 235 lines
This is because I needed Sitebot to work for _me_, and it calls its own routines recursively and does many strange and arcane things (if I didn't need to auto-link to a separate FX folder that's always at root level the whole thing could have been done by hand but nooooo, genius here had to come up with more complicated things to do to^H^Hwith it)
When coding weird stuff the most bizarre notions are likely to seem obvious, and then be totally inexplicable in a month. I like to be able to stop coding on Sitebot for a month, and then resume without spending hours figuring out what I was thinking....
Error checking (Score:1)
I always try to figure out the most evil things I can do to my programs to make them crash and burn, and if it seems possible I'll do the error checking.
Not if (2+2 = 5)
but if (application is expecting to be able to get parent folderitem for itself as a folder/directory but surprise! It's at root level out of the folder it shipped in. On a Zip Disk. Which is write protected, with one of the sectors damaged >:) )
Get it? If you don't try to kill your program in horrible ways, horrible things will eventually happen anyway, and your program will faw down go boom, probably when someone needs it most. I don't care what Linus says- he can and should make the Linux kernel an intricate perfect diamond dependent only on his own code- but when I'm writing applications I assume nothing.
If your app needs no error checking, you probably aren't letting users run amok enough. Saying 'don't touch anything' isn't okay. They need to get their little paws dirty and feel they can mess with whatever- and if they break your program's dependencies doing so, unless it's truly speed critical and you can't spare the check at all, you need to SAY what they did to break it so they can learn and fix it.
what languages did you code in? (Score:1)
Maybe we're just more efficient. (Score:1)
I would think that generating fewer lines of code would be a mark of excellence in this industry, not laziness. I'd much rather produce an elegant 7700 lines of code than 16,000+ lines of bloatware.
oh well.
I wrote a negative number of LOC (Score:1)
One of the other silly things about counting LOC is that it is often so much more productive to ELIMINATE code than to write new lines.
I probably wrote some small number of thousands of lines of new code last year. But I am quite certain that I simultaneously managed to delete more lines than that from legacy products/projects. Some of that was in Y2K remediation, other parts were just in regular code maintenance, version creation.
Bad programmers, or even just good programmers in too much of a hurry, will write almost the same 50 lines over and over rather than stick them into a generalized function/class; or they may simply not know that someone else in the workteam (who left years earlier) had written that function and stuck it somewhere in a different program. Also, but to a smaller extent, programmers use inefficient expressions of an algorithm that can be expressed non-cryptically (no obfuscated Perl for me) in many fewer lines.
So during my 1998 contract, I probably wound up getting paid a net NEGATIVE $10 per line of code I wrote
Coders (Score:1)
What this article may not be taking into consideration is the language that code is written in. Cobol or Fortran are languages which dictate that coders use more lines to do the same things. In the US C(++) is the dominant language. The objects in C++ and the ability to reuse those objects eliminates the need the re-invent the wheel and type those lines of code again, and again.
I keep all of the code that I've written handy, just in case I want to save 4 hours of work rewriting and redebugging a group of objects.
I'm not currently coding for a living, I do it to learn, and to accomplish simple repetitive tasks. If I had to do it to keep food on my table, I'd probably learn even more tricks to save time and get the job done faster. If these guys could get the same amount of work done while only writing 500 lines of code, I'd say all the better.
LK
American Slackers & Microsoft (Score:1)
Could anybody tell me what percentage of Microsoft programmers are American - this article could explain a few things.
From
A man how writes barely 1000 lines a year
Weird (Score:1)
This is so strange. I was talking about this around 12:30 this morning, one hour before the post. The only exception is that I was refering more to (both corporate & private) windows programmers. I HATE all this visual crap. (Dos rules!) I even run an open source site.
what languages did you code in? (Score:1)
I program in a lot of different languages.
I do mostly C, but I use other languages as needed.
More important... (Score:1)
The difference between O(n) and O(n^2) is in no way 2 days - "a fraction of a second".
duh (Score:1)
of course I don't write many lines of code.
I do however, reuse a great deal of code. I spend more time designing than programming so I don't have to write large amounts of code, re-write, or patch.
I guess this would make me lazy (darn 'Enter' key! (Score:1)
If it's hard to write, it should be hard to read.
You're right! (Score:1)
If you know how many lines of code you've written in the last year, you've got way too much time on your hands. Go be more productive, weenie boys!
Yeah, but what exactly is a 'line of code'? (Score:1)
Hmm. I notice that this code has NOT ONE SINGLE COMMENT. Terrible practicum, well on the way to Write-Only Programs.
Some more salient questions about code: How many _totally_incompatible_except_MicroSoft() function calls did you use? How many global variables changed in every function you ever wrote? How many ridiculous fpszqhPrefixToVariableName did you use? And finally, how many of those lines of code were (gulps back bile) VisualBasic...
Yep, I AM lazy... (Score:2)
...but not unproductive.
Laziness is a VIRTUE in a programmer. "Man, I don't want to keep doing this. I'll write a program to take care of it." "It'll take me forever to write that program; there must be a faster way." Etc.
Lazy overpaid US worker, lets.... (Score:1)
Razy americans
So quit. (Score:1)
All of them, and that is a stupid question (Score:1)
Okay, so I don't know every programing language that mankind has ever invented. But anyone who can get a CS degree should be able to pick up any language needed in just a few days. It will take months to learn all the tricks, but in a few days you can be productive, and a in a week nearly as good as the seasoned veterans (with the same expirence as you).
The important part of programing is algorythims, data structures, and the expirence to know when to apply them. The skills from one language translate to anouther easially.
I have on several occosions sat down with the source code in a language I've never seen before and found the bug in it. EXPIRENCE to know where to look, and the simple structure of all languages allows me to do this.
Learning a programing language isn't like learning a foreign language. Once you know a LISP, a Assembly, and a C like language you can learn them all in no time. Learning a new one is like a Londoner going to the southern US. The langauge is different, but it won't take long to converse with someone there.
To answer the question: I use TCL/TK, C/C++ (C compiled with a c++ compiler, and in c++ function calling. I'm interfacing with hardware so c++ isn't of much use), and a private OOA thing (4gl?) that gets compiled to C++. They all work, and all are the same, even though the OOA doesn't support arrays to my annoyance, I can code arround that.
what languages did you code in? (Score:1)
Mmmmm... perl....
(and occasionally UserTalk, and AppleScript)
Last year... (Score:1)
Guess that puts me in the 20k+ group, heh...
Oh well, now I get to maintain that program, and write cool things in perl, c/c++ and java...
I like my job
Homework => 5000 loc (Score:1)
-Ben
Code to Live, Live to Code (Score:1)
At home (personal projects) approx 15,000 lines
The 50,000 lines were Java, the 15,000 C and C++
I wish the totals were reversed, but unfortunately I have to code what other people want me to code so that I can feed myself and then code what I want to code on my time off
Vindication! (Score:1)
if (...) {
...
}
That's what I use. And I *always* limit my lines to 80 columns, which may inflate my line count a little bit. Also I tend to comment fairly liberally and use whitespace abundantly when it helps to clarify code. Some of my coworkers write lines 160+ characters long (!!!) and they don't comment at all. So my 50+ Kloc is a somewhat inflated compared to them.
However, I feel that neat, readable, well organized, commented code is implicitly more valuable so while my whitespace:line ratio is higher, so is my value:line
Vindication! (Score:1)
if (...)
{
}
any day.
I agree with you on the 80 columns bit though, long lines mean too danged much resizing. And cygwin doesn't like to resize width-wise.
Lies, Damn Lies, and Statistics... Again (Score:1)
Then find another job. It's not you who should be irritated by them, it's they at you for doing what you do for such a piddling wage and bringing the pay average down. It is not immoral or disloyal to leave a place where you are underpaid and overworked.
And if you're young, a certain amount of job-switching is good for you. You'll get a better sense of what work environments there are, you'll find that your best pay raises are when you change jobs, and you'll make useful contacts. Also, once you've left school, work is one of the major places to meet people, both for friends and potential mates. And it can be problematic to get involved with the latter while still working for the same company.
Lines of code isn't just an inaccurate measure... (Score:1)
cat bigprog.cc | indent | wc -l
(or, as an added bonus, probably more like
cat obfuscated.c | grep -v ^# | cc -E - | tr -d '\n' | indent -kr | wc -l
)
I actually needed to strip carriage returns because indent couldn't figure out how to indent ascii-art-c properly... oh well...
Of course lines of code is an inaccurate, stupid, braindead, unreliable measure of productivity. So are bogomips. We still use them... However, they aren't the holy grail of software metrics or benchmarking or anything. That's why this is just a poll topic, instead of something serious.
However, if you think it *is* the holy grail, use gnu-style indenting. More lines-of-code thank k&r, so your code is suddenly better.
Lines of code isn't just an inaccurate measure... (Score:5)
- Encourages cut&paste programming ("Look- I just wrote 2000 lines of working code without touching the keyboard!"). The danger of cut&paste programming was ablely demonstrated with the Y2K problem- simply fixing the problem in one place doesn't fix the problem, you have to find all the places that code was copied to and fix it there as well. What should have been a 30-minute fix turned into a multi-year code spelunking expedition.
- discourages black-box reuse- both of older code and of existing libraries.
- discriminates against maintainance programming-
did Linus write 5K lines of code this year? Not much more, in either case. Is he lazy? Of course not.
- discriminates against testing and debugging. I'm a middlin-decent typist (for a programmer), and I can type in one to two thousand lines of code in a single day. Testing and debugging said code can take days or even weeks- during which my code output is exceeding low to non-existant. Last year there was an entire month of busting my butt where my sum total code output was 2 lines (finding the two lines of code in the device driver to fix was a bitch).
- Discriminates against time spent on design. Especially design which increases code reuse, and decreases code complexity and size.
- Discriminates against writting documentation (that's not code).
In fact, LoC Discrimates against all parts of programming _except_ the typing parts.
Programming is not an assembly line production, no matter how much some managers wish it were. There are no easy measurements of programmer productivity. And I do not beleive the American programmer is "lazy".
H1b/legislative relief Propoganda? (Score:1)
Its amazing how companies dig on supply and demand until we start talking about capital/labor markets. =)
Of course, all metrics have problems, and the L.O.C. thing has been well covered, blah, blah, blah... I just don't like the idea of someone telling me that my 60 hours a week aren't good enough.
oh well...enough whining... I have to get cracking if I'm going to beat my "nonunion mexican equivilent" (to quote the simpsons).
50,000 at least! (Score:1)
{ return depth; }
kinds of functions, inheritance, and templates like hell. And yes, I tend to omit return values.
It just shows how far people will go to make the computer do what they want yet no corporation will ever pay anyone to code it.
Management fails again (Score:1)
This is a key reason why free software results in higher quality software with fewer bugs.
In many companies the behaviour of management actively destroys productivity and quality. Many managers completely fail to understand software development and the people who do it.
Company Management forces software developers to spend time on none productive work. It rewards behaviour that is not aligned with quality work. It measures the wrong things.
People like DeMarco have understood this and documented it for years. Have companies listened? No.
The article in CNN clearly shows a manager who also completely fails to understand how to manage software developers. He needs training urgently.
In my last job before starting my own company I worked as a hacker and then team leader for a software company in the City of London on banking software.
That company was run and managed entirely by sales people. They did not understand AT ALL what motivates programmers/analysts and designers.
These types of managers try to measure software development by number of hours worked and LOC. The results are late, slow and buggy software.
Compare this to free software which is often developed at an amazing speed, has fantastic performance and many less bugs.
Whats the difference? Free software does not have managers!
Do the world a favour - sack a manager today!
Dave
re:uhh (Score:1)
Yeah, but what exactly is a 'line of code'? (Score:2)
How many lines is that?
7? (total lines in program including blank lines)
6? (ignoring blank lines)
4? (is '{' and '}' really a 'line of code'?)
3? (#include is not really code)
hundreds? (stdio.h is huge and includes many other header files)
LOC is for idiots (Score:1)
Software person 1: does it in 20k lines
Software person 2: does it in 10k lines
Which is likely the better program & programmer?
Tom
"I would have wrote it shorter, but I did not have the time" - gist of a famous quote
LOC is for idiots (Score:1)
And then you learn more and realize the compiler figured out the loop was static and unrolled it.
You're right! (Score:1)
Yeah, but what exactly is a 'line of code'? (Score:1)
I guess this would make me lazy (darn 'Enter' key! (Score:1)
More verbose comments, and no unnecessary carriage returns and indention. THAT'S what your source code needs!
what languages did you code in? (Score:1)
uhh (Score:1)
Stock Options.
If the programmers write good code, make good products, sell lots of CDs, make the company successful, they get rich.
Duh.
Is this IBM and K-Locks all over again? (Score:1)
Is this becouse of development packages? (Score:1)
Is this becouse of development packages? (Score:1)
Not to mention things like MFC.. Heck, one function call can actually serve what 500 lines would do..
It's a corporate thing (Score:1)
heaven forbid! (Score:1)
We shall have to double their workload.. They obviously have time..
Warm squishy feeling, a poll about US! (Score:1)
LOC is for idiots (Score:1)
If there's one thing I've learned, studies are the most effective way of lying.
It really depends... (Score:1)
Leave the BS out and debug instead.
Lines of code == productivity? sweet! (Score:1)
What a stupid report... (Score:1)
Flawed research (Score:1)
When linux kernel changes languages, only then... (Score:1)
Scary, but... (Score:1)
Is this IBM and K-Locks all over again? (Score:1)
Lines of *what* code? (Score:1)
AFTER ADVANCING ONE PAGE.
"In true sound..." -Agents of Good Root
Warm squishy feeling, a poll about US! (Score:1)
20k++ aww yeah...
--
Les informaticiens Français (Score:1)
I would like to say that my collegues are as competent as those of any other nationality that I have encountered. I would also like to point out that the French education system prides itself on producing very qualified (note - not competent!) "ingenieurs" - this is a word that does not completely translate into engineer as it can only be applied to university educated professionals.
At least our friend is programming in his native language (I presume) - the keywords are not translated, nor are any of the library functions. What is even worse is that if one uses "MS Dev Studio" - the help, nor the program has been internationalised!
One could therefore suggest that a Frenchman who can do what our friend does is actually MORE competent, as he is working in a foreign language!
10k+ (Score:1)
Most my code was in PERL... the Programming language of the gods...
ChiefArcher
what languages did you code in? (Score:1)
It depends a lot on what you do, but possibly even more on who you work for. A lot of orgs have "pet languages".
If you work for DOD, you'll probably use Ada. If you don't, you probably won't. Some places do everything in Smalltalk, or LISP/Scheme, or Python.
I work at a consulting company now, and we use Java, C++, Perl, and VB for pretty much everything. I personally do Java almost exclusively for work, though I know plenty of other langugages.
But I have to say that it's useful to get a broad exposure to languages, even if you rarely use some of them. At school I learned a variety of AI-oriented languages (most dialects of LISP/Scheme) and I'm much better for it, even though I never use them in RL. For one thing, it helps me "think outside the box" (to use a cliche), but it also pads the resume...more important than you expect! :-)
Low numbers??? (Score:1)
This makes me wonder how they define "programmer." Perhaps "programmer" is just someone who happens to write some code in his or her job.
I'm just a college freshman now, and on a good day, I'll write 500 lines (a line being defined by wc -l) in a single day. Multiply that by ~250 work days comes out to 125,000 lines in a year...
Lies, Damn Lies, and Bad Spelling.... (Score:1)
Read my lips:
PERFORM PERFORM PERFORM
DECENT DECENT DECENT
If you went to a descent school you'd be going DOWN! Maybe you're making $25K because you CAN'T FREAKING SPELL! EVER THINK OF THAT?! SPELLING FREAKING COUNTS, PEOPLE! Maybe the consultants just don't look like an IDIOT in written communications!
Arrrrrggggggghhhh!!!!
Hey, improve your productivity... (Score:1)
I estimate that when I'm finished with the project, I'll have roughtly 1 order of magnitude less than that. I.E. 1,400 lines, give or take a thousand or two.
What's more important is (Score:1)
Does 15,000 lines/year sound a bit small? (Score:1)
Your code is probably fine. Looking at your web page, it looks like a lot of the programs you've written were things you wanted to write, and that they are pretty small. What this means is that you don't have to spend as much time defining requirements (they're in your head, so you know them as well as anybody else,) meeting with clients (you're the client,) and trying to coordinate with larger teams (small project, one programmer.) These are absolutely necessary if one is to deliver large-scale software to others, but they don't produce a single line of code.
For example, the current web project that I'm on has been going on for two months, and is scheduled to go on for a third. We just finished requirements definition and design, which means no code. I'm not worried, though -- the time spent in defining the problem means that we will waste less time in coding, and probably actually write less code as a result.
Again, lines of code is not a good measure of productivity, because it doesn't distinguish between code that needed to be written, and code that didn't. It also neglects the important front-end processes that ultimately (unless taken to ridiculous extremes) compress schedules and make each line of code more efficient.
what languages did you code in? (Score:1)
i prefer programming in c for recreational stuff as well. i have also had jobs that required c programming. almost everything for my current job is pl/sql based (a pretty horrid crossbreed between ada and sql)
definitely you should be comfortable with c. not necessarily good, but at least competent. also learn perl. while i have never done much commercial work with it, it is an invaluable tool for quick fixes, and fast development
LOC is for idiots (Score:1)
LOC is a metric that is meaningless, the only folks that use it are the idiots in management that don't understand SFA about code.
Which is better code?
main( int argc, char **argv )
{
int i, x;
for( i = 0 ; i x = ( 80 - strlen( argv[i] ) ) / 2;
printf( "%*.*s%s\n", x, x, "", argv[i] );
}
}
main(
int argc,
char **argv[]
)
{
int i;
int x;
int n;
for( ; ; ;
i = 0
i i = i + 1
)
{
x = strlen( argv[i] );
x = 80 - x;
x = x / 2;
for(
n = 0
n &nt; x
n = n + 1
)
{
printf( " " );
}
printf( "%s", argv[i] );
}
}
More lines of code does not make better code. I can crank out a more lines of code just by screwing with whitespace and the formatting as I did in the above example.
what languages did you code in? (Score:1)
gads that language sucks roadkill
what languages did you code in? (Score:1)
Think object-oriented! (Score:1)
How come almost nobody here seems to be using Objective-C?
Does HTML count? (Score:1)
----------------
"Great spirits have always encountered violent opposition from mediocre minds." - Albert Einstein
Does 15,000 lines/year sound a bit small? (Score:1)
Admittedly, it takes longer to debug everything, but those numbers above have to be bogus. If Rob can write 15K, slashdot, study and party, then it's not programmers that are the bottleneck, but the managers.
KLOC...KLOC...KLOC....KLOC....KLOC...... (Score:1)
it aint about the amount of lines of code u generate. programming is more akin to writing hiku(sp) than say telephone books, so those in the high KLOC's are either very fast programmers writing very big systems or telephone book coders featuring up their next release software...sound familiar?
Quality vs. Quantity (Score:2)
At my prior job, an Indian company was outsourced to re-write the company software for a migration off a Wang system onto an AS/400 with client/server support for PC systems. I had a few problems trying to make revisions to the code that definitely lowered my productivity:
I suspect another issue is that American companies in general have been computerized longer than companies in other countries. This would imply that more work in the USA would be done on maintenance than on developing new code. Maintenance work tends to produce fewer lines of code due to the time spent analyzing the program before changes can be written and applied.
Lines of code isn't just an inaccurate measure... (Score:2)
And my lazyness is one of the reasons I'm a great programmer, both in implementation, and in GUI design. I hate (absolutely abhor) to do anything twice. Three times is my max. When I have done something, codewise, 3 times (with small variations), I immediately yank it out and make a new method or class or (C++ Template).
"Europeans tend to have a more disciplined, engineered approach to software development. I think we can carry some of that philosophy over to the U.S. without making people feel like they're being boxed-in"
Software "Engineering" is still something of a misnomer. Software in many respects is still a craft, and discipline is efficiency of design before it is efficiency of effort. If your mind is disciplined, you analyze the problem completely before you code, and your code will be more efficient because of the design (in theory).
"lean more on using packaged software than we do in the U.S...."
I take it this means that they count code generated by code-generators in common GUI building IDE's as "developed code"? Also a major falicy as we all know.
Proud to be a slacker...
"You lack slack, Jack!"
I'll include "War and Peace" in all my programs... (Score:2)
Laziness is the mother of invention... (Score:3)
I cannot even vote for how many lines of code I have written. Probably 100 different projects between 10 and 1000 lines of code, but most of them really involve cutting and pasting. Hell, if I wasn't so lazy I would probably be using more modular code than I already do and thus write even FEWER lines of code.
I expect on the otherhand that they didn't actually ask any of the Microsoft OS developers. From what I understand they write kajillions of lines of code, as they have to rewrite the OS over again everytime they make a revision.
Wheras with Linux generally you take someone elses code and rewrite the important differences.
So is OpenSource's real value the way it supports laziness? I mean there are all sorts of projects I have done where I have looked for appropriate open sourced code before hand coding. Is this wrong? I would say that a real measurement of productivity would be how much a single programer could accomplish with the fewest number of lines but since the majority of the lines of code written by US programmers are actual productivity wasters like games it is somewhat ironic...
Productivity is measured by how much work an individual can accomplish in a consistent amount of time. The notion that writing more lines of code as getting MORE done in less time is far fetched.
Lazy=good or we would still be hunter gatherers.
DLG
How often do you have sex? (Score:2)
Sex: As often as possible. Once a year. Both true.
LOC: 1000. Also true.
Oh, wait. I guess that first question didn't actually say "...with someone else?" If we count Unitarian worship, 500 to 1000 per year.
Pretty pathetic, huh?
Despite all prior comments, I KNOW you're all laughing at my smaller LOC.
Bastards.
Lies, Damn Lies, and Statistics... Again (Score:2)
Didn't we just go through this kind of idiotic misreporting and skewing of data with the NT/Linux benchmarks?
As some of the above posters have mentioned, number of LOC is an extremely foolish way to track programmer productivity. The fewer lines of code used to preform a task the better the end product will preform (generally). I mean if they really wanted just mass LOC why not have everyone slapping programs together with Delphi and we'll all have 6MB executables for our terminal emulators.
Besides, if you go to a descent school for CompSci, you should have the idea of less is more drilled into your skull. I dunno it just irrtates me that someone who manages 3-4 Access DB's (little one's with maybe 3 users and a couple thousand pieces of data) gets paid $60K-$120K a year while I'm building a PHP/MySQL backend for 20-30 different DB's in my spare time between trouble shooting the main IS dept's networking f*ckups AND dealing with all the user issues, for a whopping $25K per year. It's this same unbalanced kind of crap that can cause sloppy coders (who generate more LOC) to be promoted/given raises over the more effiecient ones. Heck that's one of the reasons that we're losing the only good people in our main IS dept. The MIS higher ups are making idiotic Dilbert-esque demands on the IS folks and the talented ones are getting so frustrated that they're leaving. Which means that the IS dept is gutted and people such as myself (in another dept.'s IS) wind up having to pickup the slack and double/triple our workload. Meanwhile management hires consultants at $130-$300/hour to do crap like setup new PC's. And the crowning jewel? The consultants screwup constantly and I wind up having to drop everything and go do it right.
*rant* *rant*
nothing wrong with LOC if used correctly (Score:2)
I agree completely that evaluating someone based on how many lines of code they have typed is really stupid. But I have trouble believing that many functioning companies use LOC in this manner. The correct use of metrics, such as size (indicated by lines of code or function points or whatever), is in generating estimates and tracking actual progress to those estimates, so that the project manager can tell if the project is on schedule. In this sort of application, LOC are generally counted based on the code affected by changes - that could include new code, modified code, or even deleted code. This number is then cross-referenced to historical data / estimated data (depending on use) to allow analysis.
using lines of code, or any other metric, to evaluate an individual is strictly forbidden by my organization, and hopefully most others. Once you start evaluating individuals based on metrics you can throw out all hope of gathering useful information, because everyone will be covering their asses.
Only about 8,000 -- but... (Score:2)
Feel free to multiply by 5
You're right! (Score:2)