

Ask HN: Coding Quickly; How? - apsurd

We frequently hear about how fast an application is deployed, and of course the golden rule "deploy fast, iterate often" is all about timeliness.<p>I am a novice programmer developing with php/kohana. I measure my production time in days, not hours, so any tips on just how to "code quicker"?<p>Is it normal practice to consult php.net and google like mad when developing? Or do the fast programmers "just know" over time? Memorization?<p>Thanks for any tips, all stacks welcome.
======
tdavis
If you're a novice, of course it is normal to consult outside resources a lot.
With PHP it will require an obscene amount of memorization since there aren't
really any strict naming or parameter conventions within the builtins lib.
Plus, you've got to recall everything about the framework, too. I've been
developing with Django for a couple years now and I still have to look up
stuff I don't use that often. It just isn't efficient to try to memorize every
single detail.

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.

~~~
jasonkester
That's the single best reason to use a good IDE live VS.NET + ReSharper.
There's simply no reason to ever pull up the documentation because it is all
right there.

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.

~~~
Hexstream
In general, having O(1) access to everything you need during development will
greatly increase your productivity (it will help achieve and sustain flow more
often). You might (or rather, _will_ ) have to write some tools to achieve
that. This is where having an easily extensible environment like Emacs comes
in.

------
mahmud
"Is it normal practice to consult php.net and google like mad when
developing?"

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.

~~~
catch23
The fastest way for me to code is to unplug from the internet completely. Get
all your necessary documentation available in offline documents so that when
you code, you don't get distracted by Hacker News :-).

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

~~~
peterbraden
this is _really_ good advice - I find when I'm coding in a coffee shop then I
feel more productive because the internet is a really big distraction.

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.

------
patio11
_I measure my production time in days, not hours, so any tips on just how to
"code quicker"?_

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

~~~
Hexstream
"Code less."

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.

------
quantumhobbit
I think that the more you code in a language the quicker it will come to you.
For example I can usually churn out python, which I've been using for a while.
However I'm just starting Objective-C and I need to consult Apple's reference
library every other line of code. But it's not like riding a bike. I used to
be able to write Fortran code like mad and now I can barely remember any of
the syntax at all(possibly a good thing).

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.

~~~
colins_pride
My understanding is that BillG had to rip the radio out of his car back in the
day. He needed to think, and he couldn't stop himself from listening to music
while he was driving.

We have the noprocast feature.

~~~
quantumhobbit
Noprocast is a good feature, but I use
SelfControl(<http://visitsteve.com/work/selfcontrol/>) to block other sites as
well. Highly recommended.

------
spoondan
Focus on being efficient rather than quick. Charging off in the wrong
direction will slow you down. Paralyzing yourself by over-complicating
decisions will slow you down. _Move forward at a steady rate and you will get
things done faster._

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.

------
10ren
I wrote the first version of my app in 2 hours - but it took a year of
iteration to become a salable product.

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

------
nostrademons
You still consult Google and the language reference, but much less frequently.
Generally, if you want to get feature release time down to hours instead of
days, you'll need to have the "core" of the language in memory. That usually
includes language syntax, string methods, data structures API, whatever basic
IO library you're using (files/database/network), and various other simple
utilities. You'll know when you see them, because you see them repeatedly.

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.

------
stan_rogers
Coding is a lot like cooking. Sure, it's fun to cook from scratch, but if
you're running a restaurant (cooking for a living, in other words), you'd
better learn to get most of the hard work done before the dinner crowd hits.
"Mise en place", they call it.

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.

------
stanleydrew
I've been programming ruby on rails apps for about 9 months now and I can tell
you that things definitely speed up over time. I still have a few browser
windows open with the ruby and rails apis ready, and I still make heavy use of
google to solve problems quickly. I think it's the little steps that
individually don't cost much but on aggregate really slow you down that will
steadily disappear and improve your efficiency.

------
tom_b
I google more before deciding how to code to a specific problem. I want to
understand the problem better, see how it's been approached by others, if
there are standard approaches, etc. This helps me crystallize my thoughts and
get quick prototypes put together.

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...](http://www.joelonsoftware.com/printerFriendly/articles/HighNotes.html)).
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.

------
keefe
Sharpen your tools and remember the problems you are trying to solve. Building
software is just like building anything else and the first effort should be
getting your tools in the proper state - that means having a good IDE, a good
and private workplace, clean directory structures on your (hopefully linux)
PC. Basically, you should learn programming environments (eclipse, emacs) and
PCs (how exactly does this thing work? Coding = telling a computer what to
do). Knowing what problem you are really trying to solve will avoid the
biggest pitfall in programming - premature optimisation. Get your environment
setup, focus in and separate problems into various smaller, isolated sub-
problems. Stay clear on what you are doing and don't get side tracked by
"interesting" problems. Honestly, I would say you should try to get away from
PHP and learn a proper compiled language - Java is my favorite.

------
vito
Consulting php.net isn't an issue. I've been programming PHP for years and the
language is so inconsistent I wouldn't be surprised if even the developers
check their documentation every so often.

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.

~~~
pjhyett
We spent months building GitHub's issue system and had a lengthy beta period.
No one experienced the bug you're referring to until the feature went public.
Shit happens, you fix it and move on.

~~~
vito
Don't get me wrong, I love github, but it seems like every bug on sites I use
exists on a site that was developed with Rails or some other framework that
advertises rapid development. I'm not accusing you of incompetence, but out of
every site I go to it's the one that's most often got some feature disabled
because it was too buggy, unplanned, or what have you. Granted, it's also the
one with the most new features popping up.

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.

------
ojbyrne
It takes about two years to become deeply proficient in any
language/framework. Up until then you'll get faster, look stuff up less, and
churn out code faster.

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.

~~~
nostrademons
Something that Google's first employee said recently stuck with me: "I would
say the single most important thing an engineer can do to be effective is to
pick the right problem to work on." Alas, he had no idea how to do that (or
rather, he obviously had a very good idea how to do it, but was unable to put
it into words), but the quote resonates a lot with my experience. I've wasted
so much time on projects that in retrospect weren't really all that important
- I coded them quickly, and learned quite a bit that came in handy later, but
the problems themselves were basically non-problems.

~~~
ojbyrne
My stats prof used to take about "Type 3 errors." Type 1 and 2 errors are part
of a basic stats course. Type 3 = "solving the wrong problem."

~~~
SapphireSun
My understanding of type III was that it was "Right for the wrong reasons." I
suppose it might not be a standard term ;-)

------
peterbraden
Not to language flame, but I think that php has a longer learning curve in
this respect. Because of the huge number of functions available, there's a lot
to memorise.

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.

------
jerf
"How do I get to Carnegie Hall?"

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

------
justlearning
more practice. reading code also helps.

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?

------
jasonkester
When you hear us talking about how fast we can move, we neglect to point out
the years of moving slow that got us to this point.

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.

------
fortunado
For me, it's all planning. I consider myself a terrible coder, so I have to
lay out everything first. Working from that plan, I get things done fast.

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.

------
whacked_new
"just know" is long-term memory. That's the technical, correct term, and is
exactly what it says.

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.

------
santacruz
Pre requisites: 1\. Type without watching on the keyboard. 2\. Use IDE with
autocomplete (Zend Studio in your case) 3\. Use Zend Framework of CodeIgnite
4\. Read a lot how to do it before you do it.

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

------
likpok
You will eventually memorize the important bits of a language, and that will
make your time decrease. Furthermore, you may learn a new style/language where
the paradigm just "fits" you right. Both of these will make your times
decrease, although a quick time is not necessarily a good thing. Remember that
oopses can happen more easily if you're blazing away on the keyboard.

------
themullet
Development environment. Get auto complete and api lookup in your dev
environment.

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)

------
mronge
I found to do something well, with clean code, documented methods, and tests,
it takes more than a few hours. I operate on days not hours for those sorts of
things.

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

------
joubert
Think, then think again, then code. Visualize. Code structure should morph as
you discover the problem more. If you feel like a contortionist, you're
probably doing it wrong - think Cirque du Soleil acrobat instead.

------
donniefitz2
I can hardly remember what I did 5 minutes ago. No programmer has a mind index
of all of the libraries in PHP. If you have that kind of memory, consider an
extended visit to Vegas.

~~~
enneff
I've been coding PHP for ten years and I still have to look up the argument
order for array_key_exists() and a few others.

------
nazgulnarsil
stop reinventing the wheel. if you run into a problem chances are hundreds of
others have run into the same problem and a reusable chunk of code is
available.

------
jcapote
Switch languages.

~~~
tjic
This was down voted.

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>

------
edw519
My 2 biggest helpers to "coding quickly":

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.

------
TweedHeads
Good coders copy, great coders steal.

Google is your best weapon.

Always wear your balaclava while coding.

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

