Printable View
Someone told me that the quality of a programmer is also quantificable by the number of lines of code he's able to write in a year.
Apparently, a professional programmer would write around 15'000 lines of code / year, while an average programmer around 7'000-8'000 /year.
Would you feel to agree with this definition?
No.
TLOC is a measure of keyboard wear and nothing else.
I agree with Merrion for a variety of reasons, such as:
- an experienced programmer will use less code to do exactly the same thing.
- depending on team structure etc, writing code may not be all that a programmer does - many will also design the program, and get requirements etc.
- some code is naturally more complex to write than other code, so will take much longer to write - and the chances are that the more experienced coder will be writing it.
- ...
(oh, and the numbers are out - I have in the past written over 100000 lines of code in a year!)
Quote:
Originally Posted by si_the_geek
After 1 year of progaramming I made a game that had 65000 lines of code in 3-4months. But it could not compare to the FPS game I made in OpenGL a few years later even if it was just 5000 lines of code. So I guess I have to agree with you there.
- ØØ -
Although I do not agree with the original post, I can understand where this logic does make some sense.
From my point of view - after 25+ years of programming - a coder truly knows certain algorithms, constructs and techniques that allow for development of a program to be extremely fast.
Even the silly stuff like how to input and validate a value - a novice programmer will have to think about best practice before putting a couple of dozen lines of code into place. A talented and experienced (I'm not sure I want to debate which is more important!) coder will know that logic intuitively and get it in place with very little time and effort.
That's the most rediculous definition anyone can ever come up with... :rolleyes:Quote:
Originally Posted by Nexus7
You can write something in 10+ lines and only 1 (one), you can write 1 (one) program in the entire year with far less lines of code that would be as complicated as it may get.
If there is any definition at all then a true professional (not only programmer) is someone who is dedicated to his/her profession and shows lot of respect to everyone he/she works with (and for).
Too bad it doesn't go both ways. You can be a good programmer dedicated to the profession but the profession won't be dedicated to you, as evidenced by the many experienced programmers who have been forced to leave the field.
Robert
I am asking this because the guy who told me that is an experienced programmer, and the tendency to classify a programmer by the quantity of code he writes in a certain amount of time seems to be diffused here... at least between the amateurs... the numbers sounded ridicolous to me as it would mean around 50 lines/day, witch is really not much.Quote:
Originally Posted by RhinoBull
I would like to ear more about your personal definition of professional (or skilled) programmer... I know that time is a very important factor for a professionist...
AFAIK LOC was used in legacy days (good old mainframe programs) to measure the productivity of programmers. Since the advent OOP and other tools/technologies it is becoming more and more complex to identify the quantifiable items that can be used to measure the productivity of a programmer.
To me it all depends, a person writing 1000 lines of code in a month with improper design and lack of flexibility is worse than a programmer writing 100 lines of code with proper design and good flexibility.
Ever wondered how difficult it is becoming to estimate the software development projects. Same reasons will apply in identifying the productivity of a programmers too.
The guy who told you that, then, is not an experienced programmer. Just someone with a job.Quote:
Originally Posted by Nexus7
A professional programmer doesn't just code well. She can design and understand design, and knows how the components of a project need to be written to meet requirements. It's not always about lines of code.
A professional works in the profession.
You're still missing a major point: "number of lines" are irrelevant.Quote:
Originally Posted by Nexus7
Someone can be hired to ONLY support some programs that were written before his/her great arrival. Support quite often takes more effort and requires some knowellege in troubleshooting than if you'd required to write a brand new app... Does that make anyone from the support team not being "professional just because they didin't write a single line of code in the past few months" ??? Afraid exactly opposite - your professionalism does not and cannot be measured by any counts.
ps, tell your friend to come by so he will learn something... ;)
... and gets paid for that ... :)Quote:
Originally Posted by penagate
Productivity and professionalism are two completely different things.Quote:
Originally Posted by Shuja Ali
btw, working among many COBOL programmers I've never heard of such "measure". ;)
I have also never seen this type of "measure" in all my mainframe days...Quote:
Originally Posted by RhinoBull
I have always wondered about lines of code. If you are writing in ASM, this has a great deal of concrete meaning. However, if you are working in VB, or even C, there is a question of what to count. Surely you don't count the Next that gets appended when you type a For, nor should you count the {} of C. On the other hand, it would make a certain amount of sense to count comments, because without comments, all but the smallest programs become unsupportable. So how would you even count LOC these days? Depending on what I do and don't count, I could double the LOC of individual programs.
My definition of a professional programmer is sort of like my definition of a professional athlete: They get paid to do the job. However, unlike an amateur athlete, the sole reason amateur programmers write code is not just because of the beer they drink afterwords.
Hi,
In my experience (over 37 years in the business) Lines of Code was used in Software Engineering as a very rough guide to productivity. However, the measure was error free lines of code. It was a very generalised measure and about the only thing that could be measured.
Quoting http://ourworld.compuserve.com/homep...comp/fpfaq.htm
"There are many technical problems with the lines of code measure. Going back, almost every 'shop' was using a mixture of languages. Furthermore, most development projects then used a host of languages. How do you compare a project that delivers a 100,000 line mixture of C++, SQL and Visual Basic to one that delivers 100,000 lines of COBOL?
In addition, there is no standard definition of what a line of code is. Do blank lines count? Do comments count? Are data declarations included? What happens if a statement extends over several lines? Organisations, like the Software Engineering Institute, have published some guidelines in an attempt to standardize counting.
In the late 70's IBM developed Function Point analysis which is a measure of the size of computer applications from a functional point to view. It is independent of the computer language, development methodology, technology or capability of the project team used to develop the application.
Proponents of Function Point Analysis will claim it addresses:
Measure productivity -- Many executives have come to the conclusion that regardless of their core business, they are also in the software business. Calculating several variations on the function points produced per month theme tells them how well they are doing in this regard.
Estimate development and support -- Since the beginning, function points have been used as an estimating technique. Estimating is obviously necessary for the cost benefit analysis that justifies application development. Even for strategic projects that need no quantitative justification, accurate estimation is required for proper staffing.
Monitor outsourcing agreements -- Companies outsourcing significant parts of their IS requirements are concerned that the outsourcing entity deliver the level of support and productivity gains that they promise. Outsourcers, like CSC and IBM Global Services, frequently use function points to demonstrate compliance in these areas.
Drive IS related business decisions -- Companies must analyze their portfolios of applications and projects. The size in function points is an attribute that needs to be tracked for each application and project. Along with other data, this will allow decisions regarding the retaining, retiring and redesign of applications to be made.
Normalize other measures -- To put them in perspective, other measures frequently require the size in function points. For example, 100 delivered defects on a 100 function point system is not good news. The same 100 delivered defects on a 10,000 function point system are much easier to take."
Note that LOC and Function Points have nothing to do with a Programmer's professionality.
LOC From wikipediaQuote:
Originally Posted by szlamany
I realize what LOC is - I've just never seen it used in any shop or project that I've worked on.Quote:
Originally Posted by Shuja Ali
As that link stated, for FORTRAN or ASSEMBLER, LOC might seem appropriate, but as DOOGLE stated when you start mixing T-SQL and 3GL languages of various types, LOC starts meaning less.
Our application is based on a light-weight front-end in VB (not 100,000 lines of code) that displays and manipulates T-SQL STORED PROCEDURE results. With that said we spend most of our time develop T-SQL where you can represent an entire update/loop operation in one ACTION QUERY - using proper SET BASED logic. What used to be a BASIC program where you opened a file, looped through records and conditionally processed them is now a single UPDATE - that's a big problem in the LOC-method of measuring productivity.
Chill.. :)
It was just intended for those who didn't know. And in my post I have mentioned that it was used in Good Old Days. :) Using it now in procedural and OO languages will be a big mistake.
I also disagree with the initial point like other members have posted. As if you are a professional programmer then you get paid to write a program but the bottom line is productivity and just make it work in the sense that your project manager will not care at all how many lines you wrote or didnt write. All they care about is if you complete the job so it runs error free (within reason) and on time so the client is happy and satisified with your program. So if it takes you 50 lines to write a function easily and fast without getting complex to compact the lines of code then that would be considered better by the PM then writting 10 lines of code to do the same thing but took you longer to do it because of the complexity. If your good (which is another point) then you can obtain a balance of ease and complexity which relate to the number of lines of code and do it within time constraints that will make your project profitable and your boss want to keep you hired at least for another project as a professional programmer. Who wants a "professional programmer" that goes over budgets and takes forever to write a program that runs slow and is a be-otch to maintain and support? Rhetorical point being made.
:thumb:Quote:
Originally Posted by RobDog888
That's generally the definition of "professional". An entry-level programmer who does it for a living is a professional programmer; someone who can write a complete GUI OS, but only does it as a hobby, is far and above the entry-level guy, but he's not a professional programmer.Quote:
Originally Posted by RobDog888
Quote:
Originally Posted by Al42
That's all correct, I used the wrong adjective here, sorry... I meant to say "good" programmer.
Maybe one reason why I'm asking is this: so far I wrote less that 10 applications in VB, I am at the very beginning; while I'm getting better in speed and quality, I'm still making huge mistakes in extimating the amount of time needed to produce an application!
I.e. the last app I wrote, I expected to be able to finish it in around 1 month, but finished it in 5 days, while for another one, it's been the opposite... expected to be able to write it quickly but encountered some hurdes witch slowed me down a lot.
If a customer gives you a time limit and you're unable to stay in that limit, i know the consequences can be financially very bad. Is there any method that can help estimate the development time for a certain application or you get better at it trought experience?
You get better at it through experience.
Always always always draw out every corner of everything you need before you write a single line of code. Afterwards, go through each step in that plan and identify the technologies you're going to need. If there's something you're not sure about (as in, you know "of" it but never done it), give yourself some time to research and read through it (not necessarily learn it, but just learn "about it"). It might be simple, it may be more difficult then you expected. This way, you atleast know beforehand.
After all this is done, go back through each step again and give yourself deadlines for each one. The customer/management are willing to listen to you and your expert opinion on what needs to be done and how long it could take. if you get ahead of schedule (finish a step early and it's tested), treat yourself to some time off. Don't burn yourself out on the next step. Some nights you're going to be crunching to meet your deadlines, some are going to go smoother. You really need to enjoy those smooth nights to help you through the "crunchers."
A good programmer? That's someone who can write code that solves the problem or does the job. (Depending on your religious beliefs, that definition may change. :))Quote:
Originally Posted by Nexus7
It should only be that way all the time. :) Even most of the time.Quote:
Originally Posted by sevenhalo
I do it the other way - I try to get it finished early. Then I know I don't have any crunches ahead of me and I can really enjoy the time between "now" and the deadline.Quote:
if you get ahead of schedule (finish a step early and it's tested), treat yourself to some time off. Don't burn yourself out on the next step. Some nights you're going to be crunching to meet your deadlines, some are going to go smoother. You really need to enjoy those smooth nights to help you through the "crunchers."
Well then I'm already a good programmer... didn't know LOLQuote:
Originally Posted by Al42
To each their own. I'm one of those people that as soon as I have a problem in my mind; I can't stop thinking about it until it's solved. If I don't stop myself at specific points, I have that possibility that the next step is going to consume me and keep me up at night (I have a 6'x3' whiteboard in my bedroom for this very reason. Chicks dig it).Quote:
I do it the other way - I try to get it finished early. Then I know I don't have any crunches ahead of me and I can really enjoy the time between "now" and the deadline.