Ask HN: Coding Quickly; How?

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

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.

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.

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.

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.

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.

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?

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

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.

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.

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

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.

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)

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.

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.

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

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.

Google is your best weapon.

Always wear your balaclava while coding.

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