

A Tip That Will Help You Learn To Code 10x Faster - bradmilne
http://bradmilne.tumblr.com/post/45829792502/the-one-tip-that-will-help-you-learn-to-code-10x-faster

======
JackMorgan
This advice is good only for people who naturally dive deep into the details
and get lost.

What he suggests is what I do as naturally as a fish in water. Skimming the
details, finding my answer, and racing off is my greatest skill. But, lately,
I have realized _my_ 10x gains come when I bite the bullet and deeply learn a
technology. It is against my nature, and takes real effort, but that is where
my biggest gains are.

If you read this article, snort, and say, "duh", try getting a book on a tech
you use and reading it cover to cover a few times. Try programming without
internet for a few hours. I've been doing this lately, and my normal cycle of
hitting Google every ten seconds to remember (is it length, count, or size...)
has slowed significantly, which keeps me in flow longer. I get pulled out of
flow less and I have learned some really useful features of my stack that I
previously would have never learned.

~~~
Smudge
> Try programming without internet for a few hours.

I've done this a couple times out of necessity (internet goes down, etc). It
made me realize how useful a good IDE can be. Googling the API references is
essentially a poor man's IntelliSense. Or, maybe, IntelliSense is a poor man's
Google, depending on how you look at it.

~~~
JackMorgan
Sure, auto complete tools are great. What I'm talking about is being fast
enough that even auto complete can barely keep up, combined with a depth of
knowledge that allows you to make the wise strategic choices that cut out huge
swaths of time and typing. Like the other day this other developer and I were
trying to reorder columns of data and sort them by multiple groupings of
aggregates in .NET. We were twenty minutes into what would have been hours of
effort before I remembered reading about DataTables, which are in memory
databases in .NET. We had our problem solved in a few minutes. No auto
complete would have told me that, just careful, deliberate study.

------
jstanley
Get better at coding using this one wierd old trick discovered by a $your_town
Mom!

------
DrinkWater
If you want to become a stupid code-hammering monkey then this is EXACTLY how
you should proceed.

Procrastination, the good one, is actually the key to broaden your horizon and
gain knowledge. It may slow down your work, but i would always prefer such
colleagues over the kind described in the article.

------
systematical
Ummmmmm...ASBOLUTELY NO! Terrible advice that will stagnate your development
as a developer. You need to learn faster and better ways of doing things ALL
THE TIME. That is how you become a faster developer. But being a faster
developer shouldn't be your concern, being a better developer should.

Based on this guys advice, why learn a framework. That will take time to
learn. I can just hammer out the code on my own. Very short-term thinking.

------
vph
This is not a tip. The author simply reported his natural learning curve.
Naturally, you learn a lot at the beginning and later on you don't learn as
much. The author went through this process and thought that because he didn't
learn much "other things" at the end, he was doing the right thing, and he had
made mistakes early on by not focusing only "the thing" he was supposed to
learn.

No, he did not make mistakes by digressing into learning things that are
related but might not be directly addressing his problems at hand.

Learning is complicated, as things that you learn help you in ways that you
might not be even aware of.

------
norswap
The money quote:

> The key to being a good developer is to be able to find your answer as
> quickly as possible without learning anything else.

I originally parsed the title as "the one tip that will help you (learn to
code) 10x faster", while this is obviously "the one tip that will help you
learn to (code 10x faster)".

The advice is in fact the exact opposite of what you should do if you want to
learn faster.

~~~
jmorton
At first, that quote made me shake my head. However, it took me a minute to
realize that the advice isn't "Google all the things!"

Certainly, having to search for an answer is inevitable. But it is also orders
of magnitude more slow than recalling something from memory, at least for me.
I think the key here is having the wisdom to know what is important enough to
recall immediately versus referencing as needed.

As an analogy, and acknowledging the differences, being proficient with an
editor isn't about the speed with which you look up how to do something: it's
about what you can do without having to stop and think.

------
alexpopescu
I find the "advice" in the post a bit confusing. Finding an answer on SO or a
forum or a book will help you solve a specific problem (thus making you a
"productive" coder). But I seriously doubt it will make you code faster in
general if this "code snippet copy & paste coding" is not expanded into
understanding so next time the search part is removed from the process.

In the early days, it always took me a lot more time to get from finding an
answer to using that answer in my code. The main reason is that I didn't want
to just copy paste something without understanding it. On the other hand, a
more experienced colleague of mine was sifting through books and forums and
pushing code a lot faster. I talked to him trying to understand what I'm doing
wrong. As I've learned (actually both of us learned), the only difference was
the existing knowledge each of us had about the environment and the app. Over
time I got to be a lot faster at finding an answer and moving along, but that
came only with becoming more familiar with the tools/lang/etc and being able
to understand things faster.

------
Sakes
Most common answer to any CS question in school is... "It depends".. And I
think that applies here.

There are some situations where its better to have a good enough solution
today rather than a perfect solution next week. And when you are in the
earliest stages of product development, I apply this tip often (JFDI). But
eventually there comes a time where your prototype has actually become a
product, and too much hack & slash code begins to work against you rather than
for you.

You have to make the judgement of where this tipping point is yourself, I am
sure it is different for many developers.

Side note: I am currently refactoring a massive amount of my product's code
because I am about to introduce some new and repetitive functionality. I don't
mind hacky code, but to copy and paste it is down right sinful to me. So I
guess I have reached my tipping point.

------
rcirka
Hacking stuff together from stackoverflow might be faster initially, but later
on the product will encounter severe quality issues. Learning the fundamentals
and foundations of a technology, combined with experience and architecture
knowledge will make a programmer 10x faster while still maintaining quality.

------
doe88
I think the real secret for coding better, is to know when to apply this
advice (just looking for the answer you need without exploring anything else)
and at other times maybe when you have more times, make some in-depth learning
of broader technologies / API / languages / maths... areas that you've
previously identified and tagged as potentially worth investigating. From my
experience I can tell you this is the second component which make you a better
developer in the long term. But the first component is also essential, it is
the one that makes you start things and complete things without falling into
endless procastrination and second guessing. So both short-term and long-term
strategies are importants.

------
IgorPartola
Another side of this is time estimates. If you have done the exact thing you
are estimating, or something close to it, your estimate is only off by a
factor of 2. If you are estimating something you've never done, the estimate
is off by a factor of 10.

While I really hate the title of the article, I agree with the point
wholeheartedly. It is much faster to deliver something where you know all the
issues and have experience, than to try and research a new subject, making
mistakes along the way.

~~~
dakotasmith
The concept you propose is revealing. If I consistently underestimate the
amount of time a project will take by a factor of 10, improvements in accuracy
of my estimates (boring product management details) can be interpreted as
becoming a "faster" programmer (desired personal development outcome).

------
bulatb

      The key to being a good developer is to be able to find your answer as quickly as possible without learning anything else.
    

That might be the key to short-term productivity, but I think "good" is more
complicated. I'd rather take a small hit to my average output than churn out
lots of hacky code because I didn't bother to explore the options. Sometimes
taking time to really learn something, even if it has dependencies, is an
investment rather than a cost.

------
philmoldavski
Great advice. If I decide to go down a rabbit hole, I typically set a time
limit up front (usually 30-60 min) and try to stick to it.

~~~
PaulHoule
I prefer to be the guy who can come back alive from rabbit holes that eat
lesser programmers.

~~~
jclos
I prefer to be the guy who sets up rabbit holes to trap lesser programmers and
then eat them.

~~~
bulatb
I prefer to eat the rabbit holes.

------
SatvikBeri
I actually find this tip really useful. This is why:

-If I read a programming book, I'm likely to remember a significant portion of what I read. That's because it fits into an overall structure. Even if I can't remember the exact name of a function that does exactly what I want, I know it exists and can find it easily.

-If I read a tip on an article and apply it regularly, I'll remember it, because it gets reinforced.

-If I read something in a blog post or article and don't apply it, I'll forget it almost immediately. Without the structure or repetition it just doesn't stick into my head.

The problem is that it's really easy to get caught in the last category. It
feels like I'm learning a lot when I skip from link to link, but the reality
is that most of it doesn't stick and ends up being wasted time. Separating out
my learning and doing time works much better for me.

------
Someone
_"The key to being a good developer is to be able to find your answer as
quickly as possible without learning anything else."_

I 100% agree. That's why I often spend some extra time to sharpen my 'good
solution for my problem' detection skills.

Even reputable sites such as Stack Overflow have plenty of bad answers, and
that is even ignoring the fact that an answer may be good in general, but not
for my situation.

Site quality also decays because software is changing/improving all the time.
That answer to your question may have 700 upvotes, but if its solution has
made meanwhile it into the standard library, it really helps if you know that.

------
kanja
This is a really good way to stay junior level for your entire career.

------
bradmilne
Lots of good points. For me I know that I can get lost in the weeds. But I
also should have stated that I believe you need to take the time to learn
technologies and skills properly - and there's a time and a place for that.
But if I'm trying to build a project I'm focusing on getting that project
done. If I run into something that might be productive to spend more time on
it later then I'll set aside time later. But otherwise there's just too much
to learn and my project won't get built.

------
isleyaardvark
This seems like a good way to get 1 year's experience ten times.

~~~
jrajav
For anyone who's curious, this oft-repeated expression originates from the
novel Shibumi (<http://goo.gl/gPuyB>, fourth line):

 _Do not fall into the error of the artisan who boasts of twenty years
experience in his craft while in fact he has had only one year of experience —
twenty times._

~~~
greenyoda
Shibumi was published in 2005. I first saw the same expression in a software
development book published in the 1990s. It's probably some ancient proverb
that's as old as craftsmanship itself.

~~~
jrajav
Uh, no, Shibumi was first published in 1979.

~~~
greenyoda
Sorry, I was misled by the date on Google's "about this book" page. 2005 must
be when the digital edition was published.

------
abecedarius
It depends the most on what kind of 'anything else' you avoid: ephemera or
human capital. Getting better at telling them apart is one 'anything else'
worth learning.

------
dgabriel
I try to factor in a decent amount of yak shaving time when I make estimates.
Hitting deadlines is all well and good, but there's nothing like a good yak
shave.

------
jasonswett
The article has a pretty good point. I might add that a potentially better way
to improve your speed/effectiveness is to deliberately take time to regularly
sharpen the saw. [http://www.codinghorror.com/blog/2009/03/sharpening-the-
saw....](http://www.codinghorror.com/blog/2009/03/sharpening-the-saw.html)

------
sbilstein
You don't become full stack by being shitty at lots of things quickly. You
become full stack by going deep in many places, preferably quickly. This guy
possesses some very short term thinking.

------
pipedreambomb
Sad but true. I learnt early and forget daily that you should seek to
understand the problem by working back from any solution you can find. There's
so much to not understand!

------
amirmansour
People should be doing the exact opposite of this "tip". Unless they don't
want to become better programmers.

------
antpicnic
The one tip that will really help you to code 10x faster - know when to ask
for help.

