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.
I'm a Perl developer btw and many here consider that on a par with BASIC and might ask the same question of me.
Also, do you actually write out pseudo code on paper (regarding "reviewing code", "Refactoring code")?
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.
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.
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.
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. :)
"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. :)
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.
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 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.
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.
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.
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.
Now, the Pascal bit is probably becoming rarer :)
This was only couple of years ago! Ugh.
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.
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.
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.
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.
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.
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.
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
Are you saying you don't necessarily agree with the specific sentiment? :-)
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".
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.
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.
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. :-)
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.
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?
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.
var r= dice(array,12)
r=slice(r)
r=trim(r)
r=strip(r)
var r=strip(trim(slice(dice(array,12))))