

Ask HN: How fast do you code? - mitjak

I sometimes read reports of people "wrapping this in an evening" or "writing that during lunch". I don't consider myself a fast coder by any means, but it makes me wonder, as a student, whether there are certain expects of how fast (and how sloppily) things should be  written by competent developers.
======
leif
Rather than tell you how fast I code, I'll hopefully provide some insight in
to how to become someone who codes quickly:

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".

------
anatoly
You read these reports because these are unusual results, and people consider
them achievements to be mentioned. If it were normal for competent developers
to crank out completed projects in an evening or during lunch, you wouldn't
see the fact mentioned in their blog posts.

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.

------
Dilpil
Hard to say, depends on many factors:

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?

------
aaronbrethorst
I'm taking a break from writing an iPhone app right now. I was on track to
bang out this app in 2-3 days. It's a client for the API stack from one of my
favorite web services. Things were going great until I hit a serious snag with
some poorly documented API calls. Oops.

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.

~~~
Periodic
It all depends on your familiarity.

I recently started a job working with a Java + JBoss + Struts application,
having written about 1000 lines of Java total in my life. I can easily waste
an hours figuring out how to get a local application server running properly
or rewriting the build file to suit my needs, and yes I've done both.

Think of every time you have to "figure something out" and then think about
how much faster your code would be if you already knew the answer. That is
what experience gives you.

------
mcs
I spend more time thinking about program architecture and design than actual
coding.

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.

------
dkersten
That depends. Sometimes I write significant amounts of code in vvery very
short spces of time, other times it takes much much longer. When I was
studying CS, I often did my assignments literally fifteen minutes before the
deadline. Sometimes I can work extremely well (and fast) under pressure.

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.

~~~
ayb
When I took CS101 (Summer 1993) we actually wrote Pascal code on paper for the
exams :-)

~~~
ramchip
I think it's rather common, even nowadays. I'm in computer engineering and not
CS, but I've had many exams where I had to write C, C++, Java or Matlab on
paper (introductory classes, system programming, OOP...). I've seen this
posted before as well.

Now, the Pascal bit is probably becoming rarer :)

------
edw519
Very fast. Let me explain.

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.

~~~
invertedlambda
'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.'

Agree. While he's not everyone's favorite, I enjoy Stephen King's books very
much. His recipe for success?

King's formula for learning to write well is: "Read and write four to six
hours a day. If you cannot find the time for that, you can't expect to become
a good writer." He sets out each day with a quota of 2000 words and will not
stop writing until it is met. He also has a simple definition for talent in
writing: "If you wrote something for which someone sent you a check, if you
cashed the check and it didn't bounce, and if you then paid the light bill
with the money, I consider you talented."
(<http://en.wikipedia.org/wiki/Stephen_King#Writing_style>)

Notice how he says both reading and writing are keys to success. :)

~~~
mishmash
Love that quote and this one too, from your link:

"He is also often asked why he writes such terrifying stories and he answers
with another question "Why do you assume I have a choice?""

Many of us probably feel the same way about programming. :)

------
grandalf
My latest habit is to think very carefully about code before I write it (maybe
over several days), and then just type it out. The typing can take exceedingly
little time in those cases.

------
dieterrams
Coding speed depends heavily on how familiar you are with the problem domain,
language, libraries, and code base, and the quality of documentation for
things you are not familiar with. It depends on the complexity of the task,
and whether you have a sufficiently high-level roadmap that separates your
task into meaningful, independent chunks. (The appropriate level can be
something as high as MVC, or as low as various parts within a function.)
Creating a roadmap of chunks is extremely helpful for any relatively complex
task, because when you start working on one, you know exactly what you need to
focus on and what not to. The alternative is fumbling your way through vaguely
defined requirements, your brain lost in a haze of concerns that may not be
relevant, with the likely result being poorly written and organized code.

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.

------
tetha
Well, I code as fast as possible. There are various limits to this speed.

Am I showing a framework to someone? Am I explaining this architecture to
someone? Then I program slower, because I need to explain many things which
are in between the lines. Why do I call it like this, look there is this
naming scheme, there is that caveat.

Am I working on something alone, know exactly what I want to do and how to do
it? Then I code quite fast. I would go as far as saying: I dont program in
this state. I just write the code down, because I know where to go.

Am I exploring possible API designs with some tests, and some prototypes? Then
I go slower, because I am tinkering and thinking about this API. Would this
synonym be better here? Should I use some regular setWidth here, or rather
withWidth to emphasize the immutability? Can I build a fluent interface?

Am I in a good flow during refactoring? Are things turning out really nice,
and the refactorings just present themself like proud little animals? Then I
usually work faster again, because it is flowing so nicely and stuff just
grows a lot prettier than before with each step.

However, I am kind of strict about certain limits of speed. Skipping tests
could make me faster in the near future. Sometimes copy-pasteing could make me
faster in the near future. Sometimes not doing a certain mid-sized refactoring
could make me faster in the near future. I am aware of this, however, I force
myself to be not too sloppy. Quite often, turning the copy-paste into an
extract method only takes a minute or two, so I just extract the method. Thus,
I am limiting my speed in the near future, because I know that my average
speed in the long run will be superior.

------
robryan
Had an interesting thought reading through the comments here. It would be
great it this knowledge was pooled in kind of a HN version of coders at work
which could be in blog form.

The value people here would give over coders at work is that most people are
currently working using current technologies, so less talk far back in the
past. Also the fast paced environment of start ups isn't covered to much in
coders at work and the business cofounder role in a startup could be covered.

~~~
mitjak
Agreed. Thanks to everyone responding to the question! The insight is
invaluable.

------
arjosoer
Somedays I can write a weeks worth of code in one day, but than I spent four
days fixing it.

------
viraptor
Depends on what you do... I'm not strictly a programmer, but I have days when
I write a thousand lines of code over 3h, then I have a day when I fix two
lines in a big project over 2 days and consider it a good result (since it
took 1.9 days to find the correct lines and prove it will work).

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.

------
MichaelApproved
Keep in mind that a lot of these "over night" stories are either bogus (digg
story comes to mind), built using an existing framework of their own that took
much longer to write or extremely simple sites.

If you want to improve your development speed here are some tips:

Build a wireframe in advance for each screen so you can step through your app
first. Make sure you have every part that needs to be built planned planned
out ahead of time. You should be able to browse you're entire site using these
frames.

Build your code into a framework. Make as many of the common pages you build
use code that just drops in so you only have to tweak the UI. Then on future
projects you'll have much of it already built.

Code faster by not coding as much. Build a minimal viable product first. Then
focus on features people request after they test. This will have a double
effect. Because you got something out fast you'll feel like you coded faster.
You'll also keep from wasting time on features no one will use.

------
thumper
When I was in high school and college, my measure was to enter programming
contests where competition was on time and following a spec. I did well on
these, and I agree with earlier posters that this boils down to being familiar
with a language and its libraries, as well as the most common algorithms that
show up time and again in these contests.

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.

------
j_baker
I code as fast as I need to. I could probably do something in an evening if it
was an easy project, but trying to make a one-week project fit into one
evening is a bad idea. In short: just let it take as long as it needs to. It's
going to be difficult for you to tell if you're putting the right amount of
thought and effort into things right now because you're probably not going to
be maintaining it very long.

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.

~~~
rhythmAddict
I'd agree with this general sentiment. If I need to finish something quickly,
provided it's not ridiculous, I will. Also, keep in mind that when you've been
writing code professionally, you have access to either code others have
written at your organization, code you've written, or both. At times, this can
help dramatically. There are countless times when I think "I know I've done
this before" and I rip out 10-15 lines of something I worked on 5 months ago
and go ahead and adapt it. There really isn't any reason not to do this,
IMO...

Also, in general, I don't get a requirement/feature/enhancement/etc and start
slamming away in my editor. My personal preference is to think about it,
scratch some ideas down on paper/white board and just stare at my monitor
while I run everything through my head. It's always my first reaction to think
I need to start typing out some code - and [for me] that's usually not the
most efficient approach. Once I have a concept/logical-flow in my head that I
have run through several times, I'll write that in my editor as comments.
After that, it's really just me writing code that adheres to my comments
rather than trying to design the program _while_ coding it.

I'm not at all saying this is the right approach for all, but that's certainly
the case for me.

cheers

~~~
j_baker
"I'd agree with this general sentiment."

Are you saying you don't necessarily agree with the specific sentiment? :-)

------
scg
The faster I get code done, the less I learn.

You can easily crank out code and feel productive using your current
knowledge. For instance, you don't need much experience to code 90% of all the
websites out there. But if you're furiously getting things done, reusing the
same old bag of tricks, when do you start wondering if there's a better way to
do things?

Balance learning with getting things done. Lean to much on either side and
you'll suck.

------
svnv
Not that fast, but that is mainly because I am a noob, and I take pride in
trying to avoid writing shitty code. Insted of just hammering away at the
keyboard and using whatever just works I spend some time to make my code more
redable and easy to maintain. Also, since we use TDD we end up writing a lot
of tests for each pice of code that goes in to our product.

~~~
ewjordan
If you're really a noob, I'd try to be a little less careful, personally. The
best way to stop writing shitty code is to write a whole lot of it so that you
realize why it's shitty, not to blindly follow best practices from the start.

Of course, if you're writing production code at work or something like that,
it's another matter, and you should obviously try to make sure everything that
gets checked in is good quality. But for me, at least, knowing what not to do
in the abstract never made the same impact as doing horrible things in my code
and then feeling the pain later on - the personally earned lessons are the
ones that I remember the best.

------
ajdecon
I'm a grad student in the sciences, so most of my code is developed to analyze
and visualize experimental data. (mostly various types of 3D image data) Since
I often don't understand what my data is trying to tell me at first glance,
the majority of my "development" time is spent in front of a whiteboard doing
math, or pacing and scribbling on paper while I try to work out a step-by-step
for the analysis I want to perform.

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. :-)

------
moggleface
Depends on what you mean by coding. By the time I actually get to "coding"
something up, as in writing the actual source code to it, I've generally been
screwing around with it on whiteboards and paper until the structure of the
program becomes totally clear. Then I sit down and type it into the computer
in one big rush. So, it looks as if I "code" very quickly, but there's a whole
bunch of offline processing that goes into making that possible.

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.

------
ww520
I code slowly in general but do type very fast when needed to crank out some
functions; however, I "copy and paste" very fast so the end result is fast.
What, copy and paste? Abomination! Most people would say refactor, use class
inheritance/delegation/template, or use library to stride to share codes.
Those work fine for small scope of code and functionality. When the sharing is
the whole app, copy and paste works the best. I have shell apps developed over
the years that I can copy and paste into a new app very fast. Also I have a
large set of util functions/classes in a common library for general common
functionality. Between those two, I can crank out apps very fast.

------
joanou
It depends on the type of work. For safety critical avionics software, it can
be three eLOC per day. For tools, web and others, it can be a few hundred to
two thousand per day.

------
BornInTheUSSR
Good question, but as a developer I would try to analyze more the value your
code provides in a working state than how quickly you can crank it out. You're
competent when you can be depended on to get a job done in a way that doesn't
break anything that is already there and can be picked up by someone else when
you inevitably move on to something different. What is a reasonable amount of
time to do that depends on complexity.

------
kschua
I spend more time thinking about the approach to the problem then churning out
code.

Take this example <http://thedailywtf.com/Articles/Maximum-Pad.aspx>

Either churning out over 300 lines of code or using a "for loop" solves the
problem, but which approach is better? Sitting down to think about the for-
loop or copy-paste-replace the code?

------
diiq
I write most things two or three times. I am not clever enough to hold a whole
system in my head at once --- so doing it wrong the first time gives me
somewhere to hang my ideas.

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.

------
koenigdavidmj
Generally, if I get a request for something, I sort of combine the `coding'
and `engineering' parts. Others do their engineering on whiteboards, paper,
and by talking with people---I prefer to write Python code to express my
intent.

------
code_duck
A lot of people write lousy code. They can do this a lot faster than I write
well-thought out code.

------
known
Isn't like asking how fast you can drive.

~~~
mitjak
Not at all. I wanted to see how people work and what speeds they do it given
their approach to the combination of thinking+coding time.

------
nhnifong
My test, revise cycle averages about 10 seconds, with a long 15 minute cycle
thrown in about once every 30 short cycles.

------
noverloop
I can only assume by 'fast coding' you understand 'reaching a solution fast'.
My speed of reaching solutions is highly dependent on how familiar I am with
the problem at hand and my skill-level in the tools needed to reach the
solution. I spend most of my time learning how to tackle the problem then
actually writing code.

------
Devilboy
The average developer only produces about 500 lines of code per month,
although LOC is such a bad metric that nobody is researching this anymore.

~~~
code_duck
No wonder, since by that metric

    
    
        var r= dice(array,12)
        r=slice(r)
        r=trim(r)
        r=strip(r)
    

is four times as productive as

    
    
        var r=strip(trim(slice(dice(array,12))))

~~~
wlievens
You can compute a more accurate LOC metric based on the language's grammar, so
that the above situations are identically measured. But the issue with using
LOC remains, of course.

