Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How fast do you code?
78 points by mitjak on July 24, 2010 | hide | favorite | 69 comments
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.



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.


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


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


What kind of code / environment do you mean? Are you writing to a spec, or design from scratch? To be honest, I've never seen anyone working this way, meaning - I've never seen anyone able to design something away from keyboard that doesn't change significantly once it's written (unless they have a strict interface to fill, or something similar).

Also, do you actually write out pseudo code on paper (regarding "reviewing code", "Refactoring code")?


I've never seen anyone able to design something away from keyboard that doesn't change significantly once it's written

It does change once it's written.

The idea is to get a clear work plan on a "close enough" design. I estimate that my first cut of anything is maybe 50% or so.

The idea is also to avoid sitting at the computer all day and then being disappointed with how little I accomplished. Activity != accomplishment.

A little more background...

First term freshman year, 90% of science students took Chemistry I. On Mondays and Wednesdays, only 50% of the seats in the dining room were taken for dinner. Chem Lab started at 1:00 p.m. and dinner was at 6:00 p.m. So, most freshman chemistry students took more than 5 hours to complete their lab work.

This never made sense to me. I took Chemistry I second term freshman year. My lab partner and I made a pact to never miss dinner. We did everything we possibility could to expedite lab time. We did all the reading, planning, and reviewing other people's results before we entered the lab. We even wrote our reports in advance, filling in the results as we went. Our longest lab took 2 1/2 hours. Our shortest took 1 1/4 hour. (We also both got A+.)

I still practice that methodology today. My computer is my lab and my bed or sofa is my lab prep. Preparation takes as long as it needs. Labs go fast. If they don't it's because I wasn't prepared enough when I started.


> My computer is my lab and my bed or sofa is my lab prep.

Reminds me of programming in 1972. Think about the problem on your sofa, then buy an hour on the mainframe terminal to test out a solution. Science of all sorts seems to be done most rigorously (and thus successfully) when it's expensive to do the actual experiments.


This, and your earlier comment, are great food for thought! I'm trying to overcome distractions when I get stuck coding, and have been trying to establish a habit switching to paper at that point. The problem is, when I'm at that point, I'm usually frustrated and find it hard to fend off the urge to check out Boing Boing or HN. Having things planned out on paper beforehand could help me avoid reaching that point in the first place.

Also, thanks for posting some highlights of your activity on HN to your blog. I looked at the archives and found more good content there. I certainly think the points you made in this thread are worthy of being featured there.


I do something similar. I actually often spell out code that I want to write while away from a computer. To me it also feels wrong to go through what you call mode A and not have the project working (unless it is in really early stages). So I get the basic structure set up, refactoring 3-10 times in the process, then write a list of features. Each time I get to code I knock put at least one feature and commit to the VC repo. Of course sometimes I add new features so the list gets longer. I know I am wrapping things up when it starts getting shorter (knocking out more features than inventing new ones). It doesn't always work so I end up leaving the code base without the feature completed. If this happens I end up being obsessed with the unfinished feature to the point where I spell out code in my sleep. Good to see that someone else is using this pattern.


What language do you use?


BASIC, php, and javascript


edw is obviously a smart guy and I too have not heard of BASIC used in production or for anything recently for that matter, so I find myself very curious and would love to know more about how you're using it.

I'm a Perl developer btw and many here consider that on a par with BASIC and might ask the same question of me.


woah, where are you using BASIC? excuse the naivety but I’m not sure I’ve heard anyone use that professionaly in... ever.


I don't knw what edw does, but there are a lot of small businesses that need small one-off desktop apps, for which VB is perfect.


Agreed here; I've seen that a lot with in-house stuff. At my wife's former employer, almost all of the internally-developed stuff that she supported was a mashup of VB, Access, PowerShell, and third-party tools that they glued together.


I could understand this, but I've never heard of the all-capital BASIC referring to Visual Basic.


Modern VB is certainly good for that. But calling it BASIC is like calling Common Lisp LISP.


The 'b' still stands for "beginners" whatever you call it.


assuming you're serious.... why that mix? why BASIC today in a world where Python exists, Java, Ruby, Lisps, C, etc.?


This is pretty much the system that I use, but (B) is often at the computer, e.g. open to a text file that contains design notes.


You write several hundred lines of code per hour? Excluding comments, no doubt. What language?


I've done that many times. It's not hard if you're "in the zone": you know exactly what you want to do and how, the language nuances and the application structure/state are all fresh in your mind, no interruptions, etc.


I'm sure it's quite language- and project-dependent though. Considering xmonad weighs 1200 LOCS, at this speed you could write a full-fledged window manager in a few hours.


When you say you also write several hundred lines of code an hour, how many hundreds of lines do you mean by several? 200? 300? 600? 900? Are you including white space? Are you including comments? What language are you coding in?


Try working out the amount of code you write in an average day, or week. If you're writing, say 500 lines per hour, for 4 hours a day. At 5 days a week for 50 weeks, you've written 500,000 lines of code in one year.


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.


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?


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.


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.


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.


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.


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


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


Eh, yeah. The end of semester exams were always on paper. Policy or something. Can't say I much enjoyed drawing UML or writing Java and C++ on paper. The worst was the digital image processing, where we did get to do it in the computer labs (basically, transforming images in matlab, usually fft -> masking, multiplication or some other simple operations -> ifft), but had to sketch the results on paper...

This was only couple of years ago! Ugh.


I've just completed my (non-CS) degree, and for my second year exams (2008!), we had to write C# on paper.


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.


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.


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


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


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.


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.


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.


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.


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.


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.


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


"I'd agree with this general sentiment."

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


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


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.


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.


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.


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


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.


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.


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.


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.


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?


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.


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.


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


Isn't like asking how fast you can drive.


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.


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


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.


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.


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


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.


Some actually try to remove lines of code on purpose. :)


See Bill Atkinson, main developer of the Apple Lisa UI:

http://www.folklore.org/StoryView.py?project=Macintosh&s...


Yeah, or Paul Graham and his quest to make arc as concise as possible.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: