Ask HN: The right way to learn how to program | Hacker News Reader

Ask HN: The right way to learn how to program

5 pointscb336 comments

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.

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.

Basically, I guess what I'm asking is: What's the most effective method for learning a programming language?

View on HN

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.

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.

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.

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?

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.

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.

Reply on news.ycombinator.com