The extent of writting code?

Thread Starter

Mathematics!

Joined Jul 21, 2008
1,036
People can type and think at different rates but lets get an upper bound.

for example using this
Using the Dvorak Simplified Keyboard, she has maintained 150 wpm for 50 minutes, and 170 wpm for shorter periods. She has been clocked at a peak speed of 212 wpm. Blackburn, who failed her QWERTY typing class in high school, first encountered the Dvorak keyboard in 1938, quickly learned to achieve very high speeds, and occasionally toured giving speed-typing demonstrations during her secretarial career
Now its just simple math to work out how much code can be written or in theory words produced. This is are bound on how fast we as a single person can develop. That and factoring in thinking makes it a very slow process to complete a large project.

The only reasonable way of completing major/large programs would be to work in teams efficiently enough to out weigh this single person limit.

The only other ways are computer automation or creating a more higher level
language to do it for us.

Each has its downside/upsides since the higher level language abstracts flow of code and complete understanding so in some since harder to debug in some cases.
But faster to produce more code. The former adding people can be good and bad based on arguments or disagreements as well as usability issues.

So what I say is let the computer do the programming for you.
Some day maybe we can create an AI based computer that we can speak to it in english and it can program the program for us. ;)

So some day codebases are going to become to complex, and other things as well with computers to do in a reasonable amount of time thats when the computer must somehow be programmed by computers.
And that my friends is what I call artificial life.

Of course the computer will never be as smart as us ;) But then again thats not proven yet
 
Last edited:

Thread Starter

Mathematics!

Joined Jul 21, 2008
1,036
The purpose you get out of programming is the ideas and algorithms used to apply them to anything. Or create something new. It is really the knowledge of how something can be done much more then the actual doing off it.

Yes I agree both are important but the latter of actually doing it can be taught to almost any one with enough time. But the former takes talent and a gift in some cases.

A imagine some day we reach a point where are code bases get to big call this
size L then we can only write a finite amount of code under L until we have written everything humanly code-able.

Does that mean creativity stops no just programming in the conventional way does.

But from a customer point of view/marketing point of view it is the doing part. So the other **** is to cram as much bullshit into something or give tons of things that virtually do the same thing. And people suck it up.

I was going to write on the extent of reading code which would in theory be analysis-ed the same way but is hard in that you would have to understand how the brain understands reading words and how fast it can process things.
May find out that when we reach size L we could read and understand in a reasonable amount of time size M > L.
So that would be funny we could read and understand what we had to do more then we could actually accomplish writing it.
 
Last edited:

Thread Starter

Mathematics!

Joined Jul 21, 2008
1,036
My question if you are a project manager or somebody that analysis the creation of code.

1) what is the fastest you have seen somebody develop code in?
This is in terms of time , lines of code,...etc

2) what is the average developing speed of your worst and best programmers?
 

justtrying

Joined Mar 9, 2011
439
I disagree sightly, programming cannot be taught almost anyone. I am actually very good at coming up with high level concepts, but I cannot convert them into code. The way my mind works simply does not allow for it. Code is too structured and inflexible, hence not for me. If I struggle with it for long enough, it will become better, but not good.

p.s. before comparing "smartness" you first must define it :)
 

Thread Starter

Mathematics!

Joined Jul 21, 2008
1,036
well, thats your believe and don't want to argue but everybody can improve
not the question would be improve to watch you say is a "good level"

As well as define what good could is. Some people writing local code may thing good code is the ability to get it to do what you want forgetting maintainability.

But I probably would go by what the average person thought good code was.

Weather somebody could obtained that level is more of how committed he was to doing so in most cases.

Think of how great programmers got great I am sure if everybody worked as hard as they did they would at least obtain respectable status.

And ps I am not defining anything about smartness here other then stateing some personal facts. To put this discussion on a more sound bases then ya you would. I think you would see your at a loss if we go there.

I do however wonder about those 2 questions

And another thing people should set goals based on there abilities just because somebody is given a gift in a particular area doesn't make them any better then another person. In fact they probably lack some other area.
 
Last edited:

justtrying

Joined Mar 9, 2011
439
And another thing people should set goals based on there abilities just because somebody is given a gift in a particular area doesn't make them any better then another person. In fact they probably lack some other area.
And that's precisely why some people are programmers and others are not... it takes a special mindset to "see" how to properly execute a code past the very basic level. Of course most people could learn it at the very basic level as well (by the way, which language are we discussing, some are worse than others). I am working on a project now, and it took three people 2 months to get to a point to which someone could have gotten in two hours, so I am probably not the best person to have this discussion ;)

p.s. On the part of commitment, I am somewhat dyslexic, so the tendency to make syntax errors is huge - not much I can do about it (esp when using assembly)
 

WBahn

Joined Mar 31, 2012
29,976
Before coming to a conclusion regarding whether or not everyone can learn to be respectable coders, I would recommend a few points for consideration:

1) An analogy with athletics can be made. Would it be reasonable for someone to assert that anyone can achieve a respectable level of proficiency at any given athletic endeavor given sufficient drive and determination? I would argue no, that such an assertion is quite unreasonable. The analogy could be made in many other areas as well. Do you think that anyone could become a respectable dancer or poet or painter or composer or sculptor given sufficient drive and determination? I don't.

2) Now consider someone that is mentally handicapped. Is it reasonable to assert that any mentally handicapped person could achieve a respectable level of coding proficiency? Again, I would say no. And you can't then just say, "Well, okay, exclude them, I didn't mean people that have a mental impairment of some kind," because mental handicaps are a continuum and the line between when someone is and is not impaired is fuzzy and ill defined. More to the point, the impact of one person's impairment on what they can and can't do (or how hard they struggle with it) can be totally different than someone else's. My point here is that it IS reasonable to assert that there are likely lots of people that would never be judged by anyone as having a mental impairment unless you happen to make that judgement with respect to their ability to grasp and work with coding concepts, in which case they might be judged severely handicapped (and, of course, the same would be true for just about any other activity, as well).

3) This might be an extension of Point #2. Look into the notion of "field dependent" versus "field independent" thinkers. Most engineers and people drawn to technical fields are highly field independent and such thinkers are generally able to parse problems into smaller problems and focus on the small problems separately and in isolation. People that are strongly field dependent have a very difficult time doing this and in extreme cases it is pretty much impossible for them. However, they tend to have compensating strengths when it comes to activities that involve thinking at higher levels of abstraction and generally make more effective project managers than your typical engineer. A very crude description is that someone that is field independent doesn't see a forest, they see a collection of trees that they agree to call a forest. If they focus on a tree, they see it as a collection of branches and leaves and whatnot that is collectively referred to as a tree. Someone that is field dependent tends to see the forest as a single thing and is only comfortable working with a tree in the context of the forest. If they try to focus on a branch, their tendency is to think of how branches fit into the overall forest.

Most people are somewhere between the two extremes and have traits and capabilities of both to greater and lesser degrees. About 60% of the U.S. population (have never heard a global number) is at least moderately field dependent. Over 90% of engineers are at least pretty strongly field independent. People toward the extremes in either direction simply think differently -- neither is necessarily better, except in the context of specific tasks.

My point here is that people that are strongly field dependent (and I have worked with quite a few) have extreme difficulty understanding basic programming concepts and constructs. I am pretty convinced that they could spend the rest of their lives working on it and never achieve an entry-level programming skill level. That is not an overall assessment of their abilities; I have seen several of those same people demonstrate a level of proficiency with other things that I could only admire and envy, knowing that I struggle mightily (or would, if I ever were tempted to try) to get just tolerable results (and would likely never come close to even that, in many areas).
 

ErnieM

Joined Apr 24, 2011
8,377
How fast the code is produces is really a meaningless parameter.

The error rate is paramount. Fully debugged code is estimated to cost 1 human hour per line.

I can't argue with that number, it seems to follow several real world project's development times I have done.
 

K7GUH

Joined Jan 28, 2011
190
Fully debugged code is estimated to cost 1 human hour per line.

That may be overly optimistic.
Did you know that we put a man on the moon with obsolete, unmaintainable code?

Artificial Intelligence is no match for Natural Stupidity. --- Herb Grotsch, of fond memory.
 

Thread Starter

Mathematics!

Joined Jul 21, 2008
1,036
I don't disagree with what you are saying full.

But here in lies the more important question to determine the extent of a humans program-ability. Because at times you may think that somebody doesn't possess the talent but really they may the just haven't found what works for them. For example there are treatments for dyslexia people.... and Look at oz Osborne he was a great musician... etc But could you tell that from looking at him and talking to him for a few minutes ?

Anyway the point is until there is a guaranteeing way to measure the extent of a humans ability/potential at a particular thing you can never be sure for the most part.

Anyway curious more about how many lines of code you would normally expect a person to write in a given day working on a given project.
Or how you would define bad , good , or exceptional programmers ? And what traits and abilities they would have to have in your terms to qualify for that?

For the lines of code lets do it like this
perl ?
c# ?
asm ?
python ?
c/c++ ?
java ?
visual basic ?
javascript/html/xml ?
sql/plsql ?
bash/make ?
php ?

And that should cover most of the major languages used in business's and in most general use.
 

WBahn

Joined Mar 31, 2012
29,976
Is 50 lines of code more than 10 lines of code?

Even if the 10 lines do what the 50 lines do in a simpler, cleaner, more elegant and more understandable way?

Quality counts, too.

This also brushes up against the Mythical Man Month. I would expect, in general, the number of (pick your metric - so let's just stick with lines of code) per programmer to go down as the number of programmers goes up.
 

Wendy

Joined Mar 24, 2008
23,415
Elegance is overstated. If it works reliably, good enough.

<snip>
I think if I stayed away from AAC I would be more productive!:(
Speaking about me, I agree.

I spent thousands of hours writing code. I lost a lot of it due to unreliable storage media on the TRS80 Model 1, it used a cassette drive. I have very little to show for it.
 

WBahn

Joined Mar 31, 2012
29,976
couldn't one also condense the code so much that it becomes illegible and difficult to maintain?
Sure, which is why I was careful to include "in a simpler, cleaner, more elegant and more understandable way".

Code can easily be written so that it is virtually impossible to maintain -- and it doesn't have to be condensed to make that happen, though the process of condensing code is more likely to move it in that direction. With today's hardware, it is seldom justifiable to optimize the code performance to the point that it becomes hard to understand; but there will always be times when doing so is justified and, when that is the case, the commenting should be very liberal and thorough. I try to write code so that it is largely self-documenting and there are usually a handful of places where I'll have dozens of lines of comments for three or four lines of code since it's one thing to read code and figure out what it is doing and an entirely different thing to be able to figure out why it is doing it.

But the opposite can be true, too. Frequently code written by someone that is either a lousy coder or has a lousy understanding of the problem they are trying to solve or the solution they are trying to implement will end up with code that is little more than "a happening" that meaders along and does things in very convoluted and inefficient ways. I once saw more than two dozen of lines of code devoted to doing something that literally only required that a single addition operation be changed to subtraction.
 

Thread Starter

Mathematics!

Joined Jul 21, 2008
1,036
I would expect, in general, the number of (pick your metric - so let's just stick with lines of code) per programmer to go down as the number of programmers goes up.
True until the code becomes unreadable or can't be deciphered very easily.
Code can only grow so much until it becomes unmaintainable or needs to be rewritten. ( or at least it gets to the point very few can understand it maybe not even the writters them self it it is very old)

And I was more after how much a programmer typically types in a given day.
As opposes to reading or other non-typing tasks?

But I am think this is to general.

Question 2)
If you where hiring a software developer what factors would you most like him to possess.
And what factors would you fire a developer for i.e what would be the most common reasons in your eyes to fire a developer.
 
Last edited:

WBahn

Joined Mar 31, 2012
29,976
True until the code becomes unreadable or can't be deciphered very easily.
I'm at a loss to understand how this applies to what I said.

Be that as it may.

Question 2)
If you where hiring a software developer what factors would you most like him to possess.
And what factors would you fire a developer for i.e what would be the most common reasons in your eyes to fire a developer.
As with any question like this, the answer depends very much on the specific situation. In general, though, for a software developer I want someone that can take a problem and produce an algorithm that solves it. Notice that I have said nothing about what language or what platform. If needed, they can learn that. I also want someone that has attention to detail and that demonstrates that they consider bounding and unusual cases, not just the expected case.

Furthermore, I want someone with solid written communication skills who can write coherently about technical subjects, ranging from comments in their code to e-mails with coworkers to documentation for customers. This is becoming increasingly harder to come by.

As for firing a developer, there are, of course, the usual litany of things that will get anyone fired, including demonstrated inability to do their job. With regard to software developers specifically, one of the things that would get them fired quickly is trying to write their code so that only they understand how it works; efforts to make yourself seem indepensible will quickly result in your services getting dispensed with.

I'm sure there are others on both sides that I'm not thinking of off the top of my head and that others will probably offer up.
 
Top