Ask HN: How fast do you code?

Believe me, once you're out in the real world, you will find out if you took a shortcut you shouldn't have. Experience is a tough but quick teacher. Just make sure you're not "learning" the same lessons over and over again.

I work in 2 modes: (A) At the computer and (B) Away from the computer.

When I'm in Mode A at the computer, I'm cranking out lines of code, testing, revising, testing, revising, etc. This process must be very fast. Several hundred lines of code (or whatever) in less than an hour. A complete cycle in less than a couple of hours. My guideline is that if I'm not working that fast, then I must not be prepared to work that fast, so I don't deserve to be at the computer. I should be in mode (B).

Mode B is generally much slower. Reviewing code, specs, or notes. Refactoring code. Laying things out with pen and paper. When I have enough work clearly laid out, I know it's time to get back to the computer and return to Mode A.

The most important thing for me in Mode A is to see results, any results, quickly and often. It doesn't matter how correct anything is, just as long as it's progress (or sometimes, reverse progress). I like to think of programming as making incremental progress in micro jumps, evaluate where I'm at, and go for the next micro jump.

Some of the best advice I ever got was from a prolific artist friend of mine who claimed, "I paint every day." So I started coding every day. But that wasn't enough. Now I make progress every day.

There are many definitions of progress. Sometimes I copy a few hundred lines of code, make a few changes, spit out a new app, and then start applying micro changes. Other times I decide that I need to see <x> today and find a way to get there. Things don't always work out as planned, but that's OK. As long as tomorrow's starting point is beyond today's, I'm satisfied.

That's my definition of fast. Not sure that was what you were asking, but I hope that paints you an accurate picture.

Am I writing new code, or adding to old code? If I am adding to old code, is it my code which I already understand fully, or someone else's code which I have never seen before? Is it a 10 file project, or a 10 project solution?

Is the task clearly defined? Am I trying to satisfy a previously written set of unit tests or am I incrementally changing my impression of what the final product should be as I am writing the code?

Do I already know everything I need to know to write the code? Do I have to track people down to get explanations of how other system components work?

How delicate and mission critical is the code, and how careful do I have to be? Is what I am writing going to be interacting with a production environment where failure means hundred thousand dollar losses, or do I want to analyze some data files on my machine?

How easy to debug is the type of program I am writing? Are we talking about an application where I can step through the code locally and see the null pointer errors for myself, or are we talking about something that involves hard to trace floating point math and linear algebra?

And of course, how complex is the actual coding? Are we talking about parsing a few log files and throwing them in a database, or are we talking about a custom file system using never before implemented data compression and retrieval techniques?

Unless it's something simple, then I can just open vim or textmate and go to town. If it's something that I know the development scope is fairly small I may even dive in and figure things out along the way. It really depends on the project.

I can crank out a few hundred lines of code per hour but that's totally subjective. 10 lines of code in node.js do a lot more than 10 lines of code in C.

There's also the revision stage if it's a project you know you'll come back to. I generally do spend more time refactoring than the initial prototype. I would hope a lot of developers are like that.

For example, I wrote a Meebo libpurple connector in glib in about 3 hours, but I spent 2 days refining it before I could consider it useful because I had done things that were silly and not the normal way of using glib.

The process of thinking about how to grow the program can take a very long time, depending on how trivial the program isn't. It might involve writing some test programs to convince myself my ideas are sound. It might involve writing some ideas down on paper. It might involve playing a game while my subconscious simmers the problem on a back-burner.

Once the thinking is done, the coding itself usually goes pretty fast.

If I were to say something like "I'll wrap this up in an evening" or "I'll write that during lunch", it probably means I've spent sufficient time thinking about what needs to be done that all I need to do now is press keys on the keyboard to turn my thoughts into code. That's generally the easy part of programming.

I guess the answer is 'it depends.' It depends on whether you're doing anything 'new' or if everything that is comprised by the code you're writing is well-known to you.

If I had an occasion to build a client for this web service before, I probably wouldn't be having this problem (not least because I'd have working code sitting somewhere on my hard drive).

I build iPhone and Rails apps for a living. If someone asked me to whip up a simple blog platform in Rails for them (along the lines of the 15 minute blog screencast), it would probably take me 15 or 20 minutes to write it.

In contrast, if someone asked me to whip up a Django app that does the same thing, it would probably take me a day to install Django, figure out how everything works, write a really terrible version, throw it away and then write a more-tolerable version.

Then again it depends on whether you're told "make X work", or "here's a complete spec including all needed diagrams, schemas, descriptions of data flow, etc. - implement it precisely". The former takes much much more time - you do your own research and experimentation. The latter is like playing with mad libs - you don't even have to stop to think.

In my opinion, it's depends a lot on the task you face to answer this question. You can create a hundred of trivial things a day, or solve one complicated issue. Try comparing with people around you doing similar work. Random person on the internet doing something "in one evening" is not someone you should be comparing to - s/he might've used a very similar app s/he made years ago as a template and only changed some texts, or s/he might've spent weeks on the idea and... lied.

I think the speed of coding is basically a mystery which no one understands, once you look at a high enough level (above incompetents who don't really know what they're doing). Some people are much faster than others, but in rare bursts, and end up being less productive. Some people are much faster than others all the time, and nobody really knows why, including themselves. They probably feel they have a "system", but it's difficult to decide whether or not it's justification after the fact. Others might try to use the same system and fail; the productive coder might well be just as productive if they tried a different "system".

Individually, everybody ends up with a hunch of what works for them; probably more often than not the hunch is right, but it's also a good idea to try other ways of organizing your work and see if they stick. Collectively, we just don't know.

1. Coding environment. Part of this is the physical space around you, distractions, mental state, etc., but you can probably figure this out best for yourself. The other part is inside the computer. You need a good editor, and you need to be comfortable in it. Vim, emacs, or an IDE. Whatever it is, it needs to really understand the language and libraries you're using (code completion, syntax highlighting, build/run/debug integrated, documentation integrated (emacs has M-x man, vim has K)), and if your language supports it, have a REPL at hand too. The most important thing here is knowing that, no matter what you want to do (move text, change variable names, start a debugger, set a breakpoint, etc.), you don't need to think about it. Your hands and your machine need to become an extension of your thought process, to the point that you think something about the code, and it happens, with as little overhead as possible.

2. Familiarity with language/libraries. If you're spending over 20% of your time looking up documentation for language features or the standard library, you're never going to code as fast as you want to. If you're a C programmer, spend more time with K&R, A Book on C, and sections 2 and 3 of the UNIX manual. If you really invest the time to memorize your language and common libraries, you can cut your development time down substantially. Of course, to do this, the best thing you can really do is just to spend a lot more time coding slowly, so go do that now.

3. Project preparation. Before you sit down to code, you need to know what it is you're coding (unless you're doing exploratory programming, which, while wonderful, requires even more of #1 and #2, and will never be "fast coding" per se). Sit down with a whiteboard or a pad of paper, or just sit and think if you have a good memory, but plan out what you're going to code. Here, YMMV a lot. For some, it's very important to have classes, interfaces, functions, etc. planned out before they code. Others need to plan out the UI to great lengths first. Personally, I think about data flow and constraints and let the function organization emerge (and then stress for a long time about the UI anyway). You should play around with how much preparation you need to do, but you definitely need to do some preparation.

4. Knowing when to stop. Apart from looking up documentation, I think I waste the most time making the code more and more optimized or more and more beautiful (read: unnecessarily clever). If you really want to code fast, you have to let go. When it works, it works, and you can stop for the moment. You can always clean it up later, abstract things away, refactor code, whatever, but you'll be more satisfied if you say "okay, my project works now, I'm going to go have a snack/smoke/nap".

The first time through is very fast --- lots of code written and deleted and commented out and back in again.

The subsequent rewrites are much slower; a day might have negative net code as likely as not.

Since I'm generally working on multiple things at once, and tend to batch the "typing programs in" sections of each project together, large bodies of code for multiple projects can seem to appear from me in a very short amount of time. This is an illusion derived from how my work sequence goes.

Then there's your brain's state, dependent on all sorts of things like your health, wakefulness, nearness of deadlines, etc. Some of this can be easily manipulated, e.g. by listening to good coding music, meditating, drinking coffee, etc. Pair programming can also speed up coding considerably (though at the expense of having two programmers focused on the same thing instead of working simultaneously on different things). Part of this is because when a peer is looking over your shoulder, you approach coding as more of a performance, and thus don't lapse into idleness or reading Hacker News. Another part is that when you run into roadblocks, and need to, say, look up documentation, the two of you can cover more ground faster. There are a lot of other benefits that have been covered well by others, so I won't go into them.

I also find that when I start something new, whether a new project or a new part within a project, I'm usually very, very slow to get into it. I've discovered that this can usually be circumvented by focusing on some minimal first step, which gives you enough of a toehold with which to immerse yourself in the project/problem. Once you've reached that point, the hard part is stopping.

As I've "matured", I feel like my raw speed is slowing down. I think that there are a lot of factors in that, like working on much more challenging problems, and switching back and forth between too many languages (so that I don't know any one quite as well).

Really, I think it's better to worry about working on stuff that you love, rather than how fast you're doing it.

While actually coding: I tend to measure my output in terms of functions which implement the various "steps" of my analysis. On a good day I might write three or five of these, maybe a total of 200-300 lines of code, and debug them using test data.

The next day they typically produce really funky results when run on the real data set, and I realize I actually want to do something completely different. But such is life. :-)

But heres the catch - programming is more than just writing the code. Its about solving problems. Its about architecting abstractions, algorithms and modules. Its about thinking.

Even though I may sometimes write substantial amounts of code in fifteen minutes or half an hour or an hour, an order of magnitude more time has already went into solving the problem in my head. Coding doesn't take much time when all you're doing is copying a solution from your head to the computer.

As an example, I found my first-year CS programming lab exams funny. They forced us to "do it on paper" for the first fifteen minutes, before you were even let touch the computer. Having already been programming for a few years prior, I could have done these assignments in my sleep, so I'd look at the spec for a moment, solve it in my head and sit there dong nothing until we were let use the computers. Then I'd copy'n'paste the solution from my head to the computer and walk out a minute or two later. The problems were easy enough to solve in under fifteen minutes and the "coding" was just dumping text from my head to the editor.

So, yeah, programming is more than typing into an editor. Most of it is done in your head.