What factors contribute to coding speed?

Question

I haven't done any pair programming nor really watched people code. I was wondering how fast most programmers code. I know there's huge differences in terms of language expressiveness (I've programmed in Lisp), but thought I could still infer something if there are enough replies.

Even for supposedly simple problems (meaning I pretty much have the whole algorithm and important implementation details in my head before I code), I rarely go over 200 lines of C#/Java (including blank lines) in a work day (8 hours). Much of the time is spent looking up documentation, debugging, and testing...and I haven't even learned unit testing yet.

A little background: I'm still in college and the above was based on my internship experience. It was ASP.NET development (in a not exactly complex domain).

Answer 1

Me, i couldnt really say. This is probably one of the most subjective question to be answered. Its like this: If Dave can code 1000 lines per day, but he leaves the testers pulling out their hair because of bugs, but you have steve who codes 100 lines per day, but his code is bug free, who is actually faster?

Answer 2

If you're into Agile, you should be able to graph your velocity after a few iterations. Other than that, I don't think you're gonna get much... it's totally relative.

Answer 3

To paraphrase Weird Al:

Once you see my sweet moves, you're gonna stay amazed.
My fingers movin' so fast I set the place ablaze.
...
When my friends need some code who do they call?
I do HTML for them all.

Well, in all seriousness, I have basically two "coding modes". Quick and panicky, and slow and perfectionist. In perfectionist mode I'd say I write 2-500 carefully coded, debugged, documented lines a day. In panicky mode, I can do several times more, and the code is usually brittle and buggy but gets the job done. I'm normally coding in Python, FWIW, occasionally C.

Answer 4

This depends on way too many factors. Where you are in the development cycle will have a huge impact on how much code you produce. I've had times when I averaged over 100 lines/hour, but I've also had times when I've averaged 0 lines/hour. I hit closer to the high end I'm implementing something I understood really well. I land on the low end when I'm debugging (especially if it's not my code). During refactoring or maintenance, the count can even be negative (and often should be).

You can't really get a useful number for something like this.

Answer 5

lifetime, I have averaged 25 lines of production code per day.

Answer 6

As Derek noted, the answer depends on so many factors, both within a single person's experience and between different people. Not to mention what qualifies as satisfying the verb "coding". Does that mean LOC or functional units? Tested or untested? There are a lot of questions such as these that affect the answer.

For me, I can say that the absolute biggest factor in producing code, either tested or untested, is how familiar I am with the problem space I'm working in at the moment.

For example, if I'm working in SQL, even if I'm not familiar with the tables, I am pretty proud of how fast I can produce a fairly bugless complex query, given a good explanation of the need.

But lately I've been working with .NET WinForms, trying to fit my code into an MVC model, and apply thorough, clean unit testing. These are all areas I have had limited experience with. As a result, I've been utterly humbled by how long it takes me to produce a clean, functional, solid piece of code that I can be confident won't suffer a complete upheaval due to a small change.

It's all relative.

Answer 7

bursts up to 1000 lines or more per day, depending on the language and how helpful the IDE is, and how well-understood the solution is

but it may take days of preparation before the coding burst can happen

when writing code generators, tens of thousands of lines of code per day are not uncommon - but arguably i didn't 'write' them!

measured over a long-running project: average 130 lines per day, but that includes not only weekends and vacation days but also 12- and 18-hour 'crunch time' days

the best advice is don't worry about the numbers, instead find your own flow

Answer 8

One thing I can be sure about coding speed is that refactoring slows it down, producing negative code lines. ;) At least, in the short run.

Answer 9

Work environment plays a huge factor.

Answer 10

What factors contribute to coding speed?

I have noticed in my department, the greatest factor is how close we are to the deadline.

I think you'd be amazed just how much code is written the night before we do the beta build.

Answer 11

This may sound obvious, but typing speed (and accuracy) are a huge factor.

And the discipline to make your programming environment more productive... Shortcuts, hotkeys, code snippets, anything that removes the need to fumble for the mouse (I've found old-school guys who program in vi are the "fastest" programmers), using multiple monitors, automating repetitive tasks, avoiding distractions, etc.

There is a great book out by Neal Ford called "The Productive Programmer" that guides you in becoming more productive in your everyday coding. I viewed it as a sort of Lifehacker tailored specifically for programmers.

As other people have pointed out, coding "speed" pales in comparison to coding "productivity".

Answer 12

There is one single factor that directly addresses coding speed.

The coder knowing what they are doing.

I'm not talking about "good coders" vs "bad coders", I'm talking about a coder who knows exactly what they want to do, and the only thing between now and having it done is the act of coding.

If you're guessing, "figuring something out", "not sure", etc., all of those slow your programming down to a screeching halt as you're always doing false starts and testing and retesting.

Now, you can "know what you're doing" and still have bugs. First, you could be dead wrong on your code. Second, you may have simply missed something, a simple typo, or whatever.

If it's the first, and you're just completely wrong, then that can bring your coding to a smashing halt, as you may have to throw it all away and rethink it and approach again. But if it's just simple routine bugs that are the nature of transcription, then those don't derail the process.

The farther you can look ahead of the problem and keep "on course", the faster you can code.

Many folks simply do not code this way. Rather, they use the code and tools as a canvas to "try things out", or get a "feel" for the system, or whatever.

These people do not "know" what they're doing.

It's kind of like shopping vs buying.

When you have your shopping list, going to the grocery store can be quick and efficient. You go in, follow your list, check 'em off, and out the door. That's "buying".

But if you're wandering up and down each isle, deciding what you want to eat that week, "Oh look! Cap'n Crunch is on sale" etc., then the process slows down. This is "shopping".

Everyone shops, everyone looks around. All coders must go through this "shopping" process to figure out what they're going to do. The classic "write it once, throw it away, write again" is a shopping process.

"I don't know what's wrong with what I'm going to do until I do it." When every line of code is a potential minefield, you tread lightly and slowly.

But once you've been down the path, when the mines are marked, you can code very quickly.

Some people can arrive at "knowing what they're doing" faster than others. Some folks may complain about some programmer using unsophisticated techniques, but even with "less efficient" paradigms, the programmer can get code out faster than others. His palette may be smaller, so he "knows what he's doing" faster.

Everything else is simply noise in the process. You can have the best working environment, with the comfiest chair, and whatever, but still be a slow coder if you have difficulty arriving at what you want to do.

In the end, speed does not necessarily make someone a better programmer than another. It just makes them faster. For limited domains, this is effective, but it's not a universal truth. Experience tends to give the programmer more foundation upon which they can make these decisions, they can use experience to throw out a lot of "bad ideas". This can make them faster.

On the other hand, there's some value of watching novices charge off in to the light, blindly missing all of the caveats, bumps, and other things the experience folk think may be lurking around each corner. The "what abouts" that plague all of our decisions and turn a simple CRUD screen in to some over engineered horror "just in case".

Answer 13

Experience and type of project .. if you keep coding projects of similar nature using the same language and tools, you'll be coding very fast, on the other hand if you come across something new or have to use a different language or tools you'll have to slow down a bit and do some research ...

Hope this helps ...

Answer 14

Here are some factors that affect coding speed:

1. Familiarity with the language - As you noted, if you spend a lot of time looking things up this will slow you down.
2. Familiarity with the editor - Most programmers that have a favorite editor have learned how to use the editor in a way that reduces the likelihood of syntax errors, as well as good ways to speed up the edit/compile/debug cycle.
3. Use of a high-level language - Using a high-level language such as Python can speed up coding simply because the instructions have a simple syntax resembling pseudocode.
4. Use of an appropriate framework - Using a framework that is suited for the problem you are trying to solve can also increase coding speed as you can use already built functions to shorten your code.
5. Pair programming - If you have a good partner, pair-programming can definitely speed up things because your partner will help catch syntax errors and you and your partner can discuss how to solve some tricky part of the problem.
6. Use of version control software - Using version control software can speed up the overall coding process because you don't hesitate in trying out some new approach to solving the problem (because you can always revert). In addition, if you do mess something up, being able to go back to an earlier version will allow you to pick up at the point the program was last working.

Answer 15

In a word, Patterns.

Fast, effective developers match requirements with patterns as a way of life. But this just reinforces Will's post.

Answer 16

The same thing that affects professionals in almost every field:

1. Familiarity with tools
2. Familiarity with concepts (patterns, syntax, larger systems)
3. DECISIVENESS and readiness to move forward
4. Confidence in their judgment
5. Experience

If you've got a framework you like, learn it backwards and forwards.

Study design patterns.

STUDY your language. Learn it's eccentricities and the little things that make it a great language.

Make sure you've got a good IDE and that your equipment is comfortable and good to work with. The DELL Cheap-o keyboard is by far my favorite, but I have dual 24-inch flat panels and a Logitech G5 mouse (loooove it). I can code 115 wpm on the DELL keyboard but I have to look at my hands on any ergonomic. It's weird.

And beyond that, put some mileage under your belt.

Answer 17

It depends if you are coding an algorithm or just simple data shuffling procedures. For algorithms, if you have a detailed pseudo-code implementation in paper or on a white board you can 'code it up' really fast: 80-100 lines per hour is probably normal. However if your include the time to lay down the pseudo-code or figure it out yourself as you program it can take a lot longer: 40-50 lines per hour average is probably normal. In the other hand if you are doing some data intensive application like a web app, where you might be using lots of preprogrammed routines or libaries to do most of the coding then you can produce lots and lots of lines in really short period of time. Under those conditions I tend to copy and paste a lot just because many things are very similar and is just easier to update than write them from scratch. This I estimate can yield speeds of 180 lines per hour easily.