

Ask HN: The right way to learn how to program - cb33

I've been programming on and off for the past 5 years or so. Online tutorials, physical books and looking at existing code have been my main ways of taking in information. While I do feel that I've learned a lot, I can't help but think that there's a better way to go about understanding programming languages and concepts. I feel like I'm stuck in some sort of limbo between being a complete beginner and having a solid grasp on whatever I'm trying to learn.<p>I'm familiar with the advice that goes something like this: "Try to solve a problem that's compelling to you and you'll learn fast", but I guess I just don't feel like I can even get to the point of being able to even attack whatever problem I think up.<p>Basically, I guess what I'm asking is: What's the most effective method for learning a programming language?
======
RiderOfGiraffes
Stock answer: It depends.

There are loads of different people, loads of different learning styles, loads
of different methods, and we know nothing about you. You question presupposes
there's a single good answer.

There isn't.

Some people pick up programming easily by reading some code, and then
modifying it to do something slightly different. Lather, Rinse, Repeat.

Other people read through a textbook and do all the exercises.

Still others have a specific task in mind, then Google, read, pester various
on-line groups, and gradually acquire knowledge.

You might actually be a guru and not know it. You might be a complete putz and
not know it.

Perhaps the best way to assess where you really are and get a grip on the gaps
is to find someone to partner with - even just remotely - and write some code
together.

Here are a few random question:

\+ How fast can you write FizzBuzz?

\+ Did you have to look up what the question meant?

\+ Did you actually write it?

\+ What language did you use?

\+ How would you make it faster?

\+ How would you reduce the number of of division/modulus operations?

\+ How would you count the number of words in a file?

\+ Find another way.

\+ And another.

If you're brave enough to answer those question absolutely honestly here,
people will give you their opinion.

~~~
cb33
Thanks for your advice. I had to look up FizzBuzz, so that's one good
direction to go in. I'm not looking for the be-all, end-all solution to
learning programming, I want to read everyone's methods and possibly come upon
the method that will deliver me to programming heaven.

------
10ren
Just on that advice: 1. try to find less ambitious tasks that still have some
excitement for you - that is, the right level of challenge for you; and 2. try
to learn how to break down tasks.

1\. I always find it exciting to see something happen because of my code. It's
very basic, like a child playing with blocks. Graphics code is especially good
for this; and there's also javascript that creates a webpage; or simply
printing something on the screen (terminal/console). Combine a few steps
together, and you can have something cool, even though it's simple.

2\. breaking tasks down is how you "get to the point of being able to attack
something". This "divide-and-conquer" is crucial - absolutely crucial -
throughout all computer science (and every other complex activity). This is
not a skill you should expect to automatically have perfectly mastered, but
it's one you already have the beginnings of and that you can practice to
improve it. For a start, you could look at any task (of any kind), and ask
yourself how it could be broken down into simpler steps - often, it will be
obvious to you. Now, break down one of those subtasks again, and keep going
until you have a task that you are 100% sure you can do. Then focus on that
one task to the exclusion of the rest of it. This is difficult. Try to pretend
that the original task and all the other subtasks and sub-subtasks etc don't
exist; and when you have solved this one task, observe that you've made
progress and congratulate yourself. Only after this little celebration of real
progress should you go on to the next step.

    
    
        If you want to hit a bird on the wing, you must have all your will in
        focus, you must not be thinking about yourself, and equally, you
        must not be thinking about your neighbor: you must be living in your
        eye on that bird. Every achievement is a bird on the wing.
    

This might not suit your temperament, but it's _the_ way to accomplish things
that are too complex/overwhelming for you. Once you're encountered one kind of
problem a few times (or maybe even once), it can become intuitively obvious to
you, and so you won't have to break it down so far next time. You have grown!

But be warned: there _always_ be things that are too complex for you, and that
you'll have to break them down. The skill of breaking things down is
essential.

------
auxbuss
Can you clarify the question a bit more, please.

For me, at least, learning a language and solving a problem with it are two
different things. For example, I can solve problems in quite a few languages
that I would never claim to know.

Many languages share similar syntax and basic properties, so it's not
particularly hard to "get things done" in them, provided you know one.

By breaking down a large problem into its components -- which will happen
automatically if you follow a tdd-like process -- you can tackle each smaller
problem in isolation, which might simply be googling for it and copy & pasting
the code. (I'm not advocating this as the "right way", just a method to get
things going.)

But, as I said, is it the language or the problem solving that you feel is the
block?

------
wturner
I'm not a programmer, but.....

I would gather if you pick something you find interesting, you could work
backwards a bit and get ideas.

So for example, I like sound "stuff"

So what I would do first is just see if I can code something that plays an
audio file when you click a button - easy enough.

then go from there.

If you don't have a tangible ideal to work backwards from then you will always
be lost.

An analogy a friend of mine said was:

If you never opened an apple you would never know there was a seed inside. So
working backwards seems to be embedded in the DNA of what people do when we
learn.

------
wccrawford
Just start using it. With the approach you're taking, you will continue to
just read tutorials and never code. If you think you can't code, you can't.

Pick a problem. Something easy. And just code it. Yes, it's going to be hard.
Yes, you'll have to look up a ton of things. Do it. Stick to it.

Here's another hint: Tutorials are not for reading. They're for doing. Reading
tutorials is just about useless, even for experienced programmers. If you
don't actually follow the steps, you won't learn anything.

