Don't worry too much about people who claim to have made an app in 30 hours or something. Chances are they (a) used something familiar to them and (b) most of the code came from existing libraries, APIs, etc. For what it's worth, I flag everything with some sort of development time in the title because I find it to be both arrogant and largely irrelevant (you made a URL shortener in 5 hours?! Do you want a cookie?!).

If you want to write code faster, write more code. You will get faster. That's about it.

Need to do something with Sockets? Type "sock"+SHIFT+CTRL+SPACE and a list pops up with everything you can do with Sockets, even if it's stuck way at the bottom of some obscure namespace you never would have found (let alone thought to import). All the classes have descriptions and constructor info. All of it is hooked into the docs and examples with F1.

I've done Django in Eclipse recently, and I'm currently doing a bit of PHP consulting, also in Eclipse. Even with all the right plugins, I still find myself on Google constantly, just like you describe. It's frustrating being expected to memorize things, especially when you know that you wouldn't need to if only you had better tools.

That's almost always true, but perhaps that's the lesson right there. People (other than development snobs) don't care what you used to build it or whether you had prior experience in the field, but they do care that you can get something to them quickly that satisfies their needs. So maybe the takeaway is a.) learn some useful libraries, and learn them well and b.) use what's familiar to you.

In my opinion the "X in Y hours" articles can be useful. If they can make a fully functional service in a short time due to libraries, those APIs and libraries might be of use for others.

If someone made an article called "Copy of Google Reader in X hours" that used a good JS and feed parser library, it would be interesting to many that would otherwise not know about these libraries

Code less.

That isn't being flippant. Code you don't write is code you don't have to debug. It is code you don't have to integrate with your other functions. It is code you don't have to refactor. It is code that requires no maintenance.

I got the first version of my application up, running, and out the door in 8 days at a "normal work week" rate. I'm not a particularly good programmer, I just cut the feature set for 1.0 to the bone. Since then it has been three years now of iterations on the existing codebase that typically add a just a few hundred lines at a time.

I also rely -- heavily -- on libraries and frameworks that do stuff better than I could, and on Google for code references whenever I'm doing something which is new to me. (It took me probably 3 years until I could write Swing apps without a browser open. By that standard you'd think I'd be able to do it for Rails by now... but not quite, unless it is a pretty basic app.)

I find this philosophy depressing in the long run. If the first concern that pops to mind whenever you need to add a feature or change something is "how can I do this in the least amount of code", you'll be depressed when comes the time to code something that simply inherently takes a huge amount of code to tackle. You'll be less likely to make that big refactoring that would greatly enhance the consistency of your codebase and facilitate further developments.

As it is, my codebase is a place I spend most of my life in, so I like to keep the place tidy and know where everything is. I want to feel at home in my home.

Once you have your "problem" pared down to the minimum needed, if you can decompose your system into lots of small parts that you can analyze easily and make darn sure are correct, then you can code without having to backtrack and do costly debugging. You'll also find that writing the code also goes more quickly once you do this. "Knowing where to start" also becomes much easier if you do this.

    Code less.

Start out with a plan, and spend as little time as you can in the prototype/experiment stage. Write down what you need to do to create a "minimum viable product".

A minimum viable product model is what all "coded in X hours" web-apps create. Quite literally, just launch as soon as physically possible; if you expect not-required-but-cool-feature-1 to take an extra 2 hours to create, and you really think would add quality to the product without adding unnecessary bulk, then just add it to the 'post-launch to-do list'. You have a massive advantage creating a web-app — the ability to instantly add features after 'launch'. Don't waste it!

And to help with creating a minimum viable product, always do Test Driven Development. While this actually adds to the amount of code you have to write, generally you will get the app finished quicker, or at the very least, it'll help you stay on track.

My issue is not so much remembering syntax and common algorithms but "brain drain" and typically take breaks all too frequently. Hacker News does not help with this.

We have the noprocast feature.

If by php.net you mean the language manual, then yes. You will consult the language manual less and less, but you will always have new libraries to pick up, not to mention platform documentation.

Eventually you will know so many different things that you will seek to learn how a given system differs from another system you already know. You will end up getting a book on a new technology you have never used and jump straight to chapter 5, for example, or flip to the appendices, or read the dense 50 page spec over a cup of coffee. Sometimes, specially for protocol wrappers, you might skip the whole manual and retain the help of a disassembler of a packet sniffer. Sometimes you will start attacking a given implementation from its weak entry points: first the test cases, to see how something is used; then the header files, etc. You can skip on a whole new fangled thing by reading the BUGS and TODO files, if they exist (be weary of their absence more than their presence.) You will get an eye for the brittle by skimming the source and see how the developers implemented a few standard things. I have dumped way too many weak C system applications by just looking at how the developers implemented command-line parsing, for example. This will help you narrow down what you actually need to use, and from there you can choose the easiest one to learn of the few good remaining options (at some point you will learn to isolate library use-points by wrapping calls to other people's code in functions/modules, so you can replace them in one tidy place.)

At some point, also, you will end up googling for error messages more than actual tutorial help. This is specially true if you're interfacing with infrastructure software like an RDBMS or system libraries.

It always takes long to write the first solution, but as you write many different kinds of software, you will develop a portfolio of useful solutions you can apply in other works. Projects that are written fast are also the ones that don't teach you anything; it's not flattering to have churned out something quickly, it just means you're not pushing yourself (which shouldn't be a goal in and of itself, btw.)

Don't worry about the speed of development and just try to write small, fun programs that solve your immediate needs (if no need is apparent, then brag points; nothing motivates like the kudos of your peers. Ok, maybe cash, a red Ferrari and a night at the Vegas strip ;-)

At some point, also try to broaden your horizons. PHP is not exactly a fun thing to work with.

Plus, your memory tends to improve since you'll actually be able to figure stuff out on your own than googling every little thing.

I have the documentation on my laptop as well as the framework source code, so whenever I need to look someting up it's there. Having to make an effort to look stuff up means that my brain has more of an incentive to memorise it.

And practise, practise, practise. These things come over time.

Of course, there is an element of experience and practice. To mitigate this, select good tools and learn them well. You should not need to consult php.net because you should have an editor that provides inline help. You should not frequently need Google because you should have a smattering of algorithms and idioms that can be re-applied. (For example, a large class of text validation and processing problems can be solved trivially with regular expressions.) "Recipe" style books can assist in developing go-to approaches for common classes of problems. Knowing the important bits of the standard library will help you avoid writing unnecessary code.

Last, but not least, avoid writing code that you don't need right now. This can be big stuff like features you haven't thought through very well. Or it can be small stuff. For example, there's an unfortunate tendency for people trying to do object-oriented programming to define getters and setters for everything. There's no reason to do this (in fact, there are plenty of reasons to not do this, but that's for another discussion) and these little wastes of time start to add up fast.

The other point that I haven't seen brought up here is to have a clear goal in mind. Know what you're building, because you can't build it otherwise. Unfortunately, this is often kinda tough if you're developing a new product, because your initial ideas for what makes a good product are almost always wrong, and you tend to discover that as you start implementing. So I've found it helps to think of your code as temporary: I know what I'm building this iteration, and I'll just go code it up and see how it works, but it's assumed that I'll have to throw it away anyway and build something better next iteration.

(1) the first version worked, but it was the minimal feature set you could imagine. That's one way to code fast.

(2) The 2 hours doesn't include thinking about it, designing it and using other tools in the same area. So I really just typed it in 2 hours. The lack of bugs just showed that I understood the problem, and that the design of the code was simple enough to be trivial to debug (and having minimal features). This is another way to code fast.

I use google, docs, etc for sample code. I use it in two ways: (1) to help me understand; and (2) if it's not at the core of what I'm doing, I'll imitate how others do that part (e.g. how to use an API). The idea is to carefully apportion my time and energy - it's easy to waste heaps of time understanding something incidental to my task, when that time and effort is needed for understanding the important things.

Understanding is the difficult part. That's what programming is really about for me - not the looking up docs/typing/debugging.

Developing works pretty much the same way -- they key to quickness when you need it is to have most of the grunt work done beforehand. That comes partly free with language features and libraries, but you'll find that, over time, you will have amassed a lot of code that pretty much does what you need. If you've done that properly, you'll find that you have essentially "added features" to the language you're working in -- and after a while you will find yourself writing code not in PHP, but in your own dialect of PHP (or whatever the core language is). That class (or function) that took you all day to write and debug? It takes 5 seconds to include it the next time you use it. That coupla annoying lines you seem to type every time you open your IDE/editor? Save them as a snippet or make them part of your default boilerplate -- it's quicker to select them and delete than it is to retype the damned thing when you need it. That part of it does take time to accumulate.

Even when the problem is a new one, it's often faster to extend the language in the ways you need it to be extended before you tackle the big picture. Some languages are a little easier to program bottom-up like that (PG gives excellent illustrations of that in the essays "Programming Bottom-Up" and "Beating the Averages"), but you can do something very like that in almost any language, and there's no better time to start than now. But do remember to add your greatest hits to your personal language library -- it'll save you loads of work if you ever need it again.

But, please, don't code for speed, code for quality. I can't tell you how many cesspools I've seen as a result of "rapid development". Namely, Lighthouse and github are some of the buggiest and unstable applications I've ever used.

They're still great applications, but dammit, when every new ticket goes to a milestone that expired years ago (Lighthouse) and I currently have "-1" unread messages (github), I can't help but be annoyed. Lighthouse more than github.

Yes, shit happens, but there's a pretty strong correlation between agile development and bugginess, whether it's the mentality it encourages or some other factor.

Thanks for the comment.

Unrelated to that is the domain-specific knowledge, which has a different effect - you don't get faster, you learn what code to write, and more importantly, what code not to write. In the long run, it probably has more effect on productivity than being comfortable with a language. How long this takes really depends on the domain.

My experience with 10x programmers (I don't count myself in that group) is that it's the second area where the big productivity gains lie.

Learning an API is the hardest part of any new technology because of all the rote work.

Contrast this with something like python/django or ruby/rails - sure there's a lot to learn in the frameworks, but the language themselves are fairly small.

This means glue code is really quick to write, and you only really have to look at the framework documentation.

"Practice, practice, practice."

One thing, though: "Fast programmers" are not monolithic. Yes, you will be faster in an environment where you are not constantly looking up API functions. The world's fastest Perl developer that has never encountered Erlang is not going to turn into a fast Erlang developer overnight. He'll learn Erlang better than a novice will given the same amount of time, but it will still take time.

But if coding, anything new (anything meaning - anything outside the domain(or even the current library) can put me off. When this happens,I feel like i have no control over the language, then I look it up and find more features, better ways to implement it, get depressed about my ignorance. The better of us here learn to implement it anyway and get better.

I should also add - I've been coding well over 5 years and the looking up web resources has deferred my learning any language via implementation. There is always some code online that I can refer to and refactor to my needs. Now, I find it hard when I want to code the same logic by myself. (Wonder how many have the same feel..I know many of you are true hackers, but how about the few of us?) AND when I try to implement without looking up, it really strains me and takes a lot of time(which i don't get in my enterprise world!) and plus the fake ego of having x years of x language and not able to write a working program.

Anyone?

I have 10 years worth of C# and Javascript libraries that I've written to handle just about any situation I can come across, as well as a home-built data framework that's more powerful than Rails, and an automated build & deploy setup that can get a new project up in minutes. These are the reasons why I can crank out a new database driven site in a matter of hours. No matter what it is, it's mostly already built.

So my advice would be to simply do your job and put in the time. Pay attention to the things that slow you down and write libraries that speed those things back up. Build yourself a set of tools and constantly improve them.

Five years from now, you can crank out a one-day clone of whatever flavor-of-the-month billion dollar site is popular at the time, and everybody will thing you're a genius.

1. I have written over 10,000 programs, but I have started about 5 of them from scratch. I just grab the closest thing and proceed to change it. I realize that doesn't help you much right now, but it tells you the same thing you'd hear in any endeavor: start building now.

2. When you start building now, build "building blocks", pieces of code you can use over and over again. A good program that's 300 lines of code could have as many as 100 calls to other functions or subroutines. Isaac Newton achieved greatness by "standing on the shoulders of giants". You should do the same thing, even standing on your own shoulders once in a while.

Think of it like giving a speech. Write the speech, revise it, and then go over it in your head (The "practicing in front of a mirror" part doesn't really apply here.) Then, finally, give the speech. You might stumble over a few words, or have to consult your cue cards occasionally, but there's nothing wrong with that. You'll do it less as you give more speeches.

Your question is about your "internal toolkit" and your speed when coding. As your experience becomes richer and more varied, your feel (or dare I say, taste) will improve and you'll be quicker because of it. A problem will tickle some part of your brain and you'll have a much more intuitive understanding of how to use your external tools (php/kohana) to best solve it. For that you do need some strong understanding of what's available in your development language of choice - memorization isn't the answer, but you should be able to remember off-hand that library X solves problem Y and might apply here . . .

It has been valuable to me to expand my knowledge of development styles and languages, so try to work in some tasks that use some very different stacks than php and kohana. If you can find a good mentor or peer group, I think that can be valuable in your growth as a programmer.

There's a bit of the gunslinger mentality floating around right now re: coding speed. Stuff like the Yale programming class where data exists on the time it took students to correctly solve a programming assignment (http://www.joelonsoftware.com/printerFriendly/articles/HighN...). The conclusion made there is "(t)he quality of the work and the amount of time spent are simply uncorrelated." So right now, hackers seem to be making sure people know how much faster they are than everybody else. Ignore a bunch of this fluff.

There are arguments that if you're not one of the "rock-stars" you'll never create software as beautiful as one of the 1-in-100 hackers. I think this is a little true (innate talent is something that exists) but we as hackers should think more about our work as craft. Maybe most people can't be wonderful artists, but craftsmen (and women) have built some beautiful things over the years.

So work on your code as a craftsman. Care about it. Read what others do. Ask for feedback. Develop a habit of deliberate coding. Be patient, and be your own worst critic and best supporter.

And good luck - what we do is quite a bit of fun.

And at expert levels it is what separates the truly good programmer from the novice, and even the "talented" young. Realizing this, as long as you keep learning, no fear. The only price is continual practice: effort and time.

That also means be constantly self-aware. If things are going too smoothly, it means it's time to pick up something new.

After some time you will have enough experience not to think how to implement this or that - this is most important.

Follow http://gettingreal.37signals.com

PS. Don't give up PHP

Keep it simple. Most php you need to do can be done with a few commands (function, str_replace, mysql_query, while(mysql_fetch_array), includes and logic statements)

Now if it's a quick script and not production code, then I'm usually pretty quick.

I'm voting it back up.

Not all language flames are useless.

Coding in some languages can be 10x or more productive than coding in other languages.

Picking the right language to give you that 10x speedup is far more important than lots of other hints that give you 5% speed ups.

http://www.paulgraham.com/avg.html

Google is your best weapon.

Always wear your balaclava while coding.

http://www.thermalshop.co.uk/balaclava-season-pi-135.html