Programming progression

[quote name='Lain Rivers' timestamp='1357252995' post='5017286']
I would like some core themes to follow as I learn programming.
[/quote]

Write programs. There are many soft skills in the craft of making programs that you can only grasp by making programs and learning from your errors (and successes).

Pick a language that has freely available, official documentation. Read it, then read it again, as much as you can. Don't even peak at tutorials, they all suck. Write code. Write code. Write code.

Can't stress it enough. Most of the questions I've ever fielded on programming have been because the asker never took the time to even try writing some code to see if it would work. Most of the arguments I've gotten into with coworkers at work were because they refused to take 15 minutes to write some piece of code to see if it would work. Just write code, write code, write code.

As said before, many times the problem is that you read some book and think "Oh so this is done this way" and you never actually try the code and experiment with it.

Again, as has been said before, the best way to learn a language is to write programs, then improve those programs, etc. The key thing is to not restrain yourself to simply read tutorials and saying to yourself that you now how to do it.

And as an example imagine C++: you start learning it, write some code, and imagine you encounter a function called "fseek()", and you don't know how it works. Then you go to a website like http://www.cplusplus.com/reference/cstdio/fseek/ look through the reference and you understand the code.

Eventually you'll begin to understand more and more about the language. But don't think that you read it once and you know all about it. If you don't practice, you'll eventually forget about it (it happens more than you might think).

Alos if you want to check tutorials, don't simply copy the code, paste it into your IDE and execute and be happy it works. You should change again and again, always trying new things, etc.

Nevermind, had the wrong idea of what you meant by references. Sorry about getting defensive.

I'm sure I could just go from language books to intermediate and then do whatever I feel like,

If there ever was a "standard path," this was it; you already know what it is. Most of the programmers I know learned to code by reading tutorials or books and coding whatever they felt like coding. The ones that went this route tend to be the better programmers, in my experience.

I tend to get overwhelmed because I have no idea what programming can do or how to do them,

If you don't know if you can do something, try doing it and find out. ;)

I have a hard time understanding how I can go from basic programming to writing my very own program. What exactly are the next steps?

It's really very simple, in principle at any rate (note that steps 2 and 3 are often done concurrently):

1. Have an idea for a program.
2. Design the program.
3. Write (and debug) the program.

Which part are you having trouble with?

All I want is structure, I can't just go look up random shit I want and learn efficiently. It's just not what I'm comfortable with doing. I can do it when I have to, of course, I just don't want my entire learning to be from reference sites.

It sounds like you want to take a programming course, not teach yourself how to program. What are your options in that regard?

In the real world (as in, if you have a job as a coder), a lot of your learning will be done via reference sites, so you will want to get used to that aspect if you want to be a programmer. If for example you're working on the "latest and greatest" proprietary console hardware, quite literally all you will have to learn from is the reference documentation provided by the hardware vendor; there won't be any tutorials online, no classes for you to take, and if it's truly new hardware you may even be the first of your coworkers to program for it! Furthermore, whether you're coding for yourself or somebody else, if you have (or are given) an idea for a program to write that nobody else has written before, there will be nobody to tell you what to do but yourself. I would say that being able to give yourself structure and figure things out for yourself is therefore a highly-prized ability if not outright essential to being a good programmer. My advice is therefore to practice giving yourself structure by deciding what you want to accomplish, then figuring out what is necessary to accomplish that.

Never mind. Wrong references idea, official docs are fine.

I'm in the staircase generation, it's how I've been taught my entire life.

What is the "staircase generation?" And so what? You don't need to let how you've been taught previously constrain you. I'd argue that you're going to have to break out of that mould to be a half-way decent programmer regardless, so why not start now?

The difference being?

In the former case, structure (in the form of a curriculum) is decided and imposed on you by somebody else. In the latter case, structure is generally decided and imposed on you by yourself, based on the things that you want to do. Sure, there may be "curricula" for specific tasks that you want to carry out, but you need to decide what you want to accomplish before you can do that.

What you're telling me is the equivalent to telling someone who is learning basic math to figure out advanced maths by using reference books with no particular order or structure. It doesn't make sense.

That's not a particularly good comparison for the specific aspect of programming I'm speaking of. Learning individual programming languages and computer science theory might be somewhat like that, but the fundamental spirit of programming is just problem solving - in particular, learning to program is really about learning to solve problems using the abstractions you have available by taking something that looks hard and decomposing the problem into a bunch of smaller tasks that are easy to perform using those abstractions you know. Learning to program is not learning facts, it is learning to think about a problem in a particular way. Learning to program is more like learning to prove things with mathematics than learning what (e.g.) an integral is.

Now, you haven't really told us explicitly where you are in this whole thing. The impression you gave me was that you'd already learned the most basic stuff, and just haven't yet figured out how to apply it. Judging by other posts in this thread, it seems like I'm not the only one. Is this not the case? Are we talking about learning to program or learning facts that can be used to program? If the former, write code. If the latter, get a beginner book (any language will do, really) and follow it from cover to cover, doing all of the examples and exercise (if there any) yourself. THEN write code.

Right, I was in the wrong forum to begin with I guess. I'm talking about learning an actual language and theory. I don't have the tools I need, that's why I was so confused why you would tell me to 'just code' when I don't know anything that allows me to 'just code'. I guess the official documents somewhat give me that, though I still think it's a bad way to learn your first language.

Right, I was in the wrong forum to begin with I guess. I'm talking about learning an actual language and theory. I don't have the tools I need, that's why I was so confused why you would tell me to 'just code' when I don't know anything that allows me to 'just code'. I guess the official documents somewhat give me that, though I still think it's a bad way to learn your first language.

Start here

This will give you the basics of one particular language (ruby). Once you've learned the basics of language structure (variables, loops, branching, etc), find a simple problem to solve and then break it down into steps.

For example, let's say you want to calculate compound interest.

First you need some inputs. How much is the principal, how long is the term, what's the interest rate, etc? How does the language you're working with allow the user to supply these inputs?

Next you need to calculate the interest (the programs main logic). What steps do you need to take to work this out? Do you need to repeat these steps?

Finally you need to tell the user the answer. How will you provide this output? Again what does your chosen language provide for this?

This kind of process flow is essentially the basis for almost all programs, from simple calculators to MMOs. Programming is the process of figuring out the steps required. The language you use ultimately doesn't matter (although certain languages are better suited to certain tasks).

There is a saying that the only way to learn is from mistakes. Only geniuses learn from others.

I think this applies in a high degree to programming. That is why it is difficult to read good books that show how it should be done. You have to do the mistakes yourself. And so I agree with what many state above, start writing code immediately. When it doesn't work, or you have problem to find out how to design it, then you go looking for answers in books and Internet.

There is a reason why I didn't recommend a specific language. It doesn't matter. Learn Prolog as your first language. Learn Fortran. Heck, learn Malebolge. Doesn't matter.

What does matter is your incessant worrying about the "right" and "proper" and "correct" way to do things, which is going to do nothing but hurt you in the long run.

Don't forget: tutorials are there to show you _how_. You would need to read a book on the language, and spend a while getting your hands dirty to learn _why_. A common misconception is found among people that flock to tutorials; most people wind up just copying and pasting the code, then looking for a tutorial for the next thing. Tutorials work best when you already understand why it works. It's like reading a book on poetry to learn the English language.

Just adding another reason to not start with tutorials that aren't part of documentation teaching a language from start to finish.