Well, I'm certainly no veteran but I can help you out with that. Yes, there will always be times when you're thinking "Now why the hell won't this work?", but if you keep it for a little while you'll always find a solution. I've been programming quite a little while now, still come across problems. But like I just said, I always fix 'em and keep going. I still immensely enjoy programming, too. ;)


-Aternus

Bruce Lee became a martial arts expert by constantly getting into fights. He undoubtedly got his ass kicked over and over many times in the beginning. This is just the price for mastering a skill. The only reprieve is that you get to control how fast and frequently the ass kickings happen.

I'd say the most important thing is to never stop learning. Do not be satisfied with what you know.

There are many programming styles and techniques. You'll find that many of the bugs (and many lines of unclear or inelegant code) you have now just dissappear if you tackle your problems in more appropriate ways. This means you should not be satisfied with your first solution to a problem.

Concentrate on learning concepts; languages are not that important. A corollary to this is: don't be afraid of learning several languages at once. Syntax is easy to learn; how to turn problems into programs is not.

Learn a functional language, like Haskell or Scheme. Python is very powerful and supports a functional style, but it's likely that you only write imperative-style code. Functional languages teach you to use state only when necessary, which helps keep your code clean and bug-free.

Check out Structure and Interpretation of Computer Programs:

http://mitpress.mit.edu/sicp/

It's online in its entirety. I've been programming in various languages since I was 12, and I would have killed for this book at any age. Eight years of teaching myself (in this order) basic, assembly, pascal and C++ taught me less about programming than 3 months of reading SICP and writing Scheme.

So don't worry about those precocious learners; you can catch up if you're willing to tackle the hard questions instead of just sticking to the first few programming tricks you learn.

In any case, you can't be far off track if you're reading Norvig already. :)

You will have to live with it cuz u'll be making mistakes all the time, that's in fact how human beings learn, by making mistakes.

The most important thing is that you like to program. I knew I wanted to program before I even touched a computer or knew how to program.

Quote:Original post by Splinter of Chaos
I've started on Python for my first language (and am slowly developing a list) and I asked my mom whether she'd ever been so fustrated on trying to figure out how to make it (programming) work, she'd wanted to scream the loudest and powerful of obscenities. She said "welcom to programming."

So does this mean that I'll just have to stare at my code until one day it works - every time I write a new program? I was hoping my confusion would simply be a noobish quirl, and that this might happen when ever I learn something new, but I'm just trying to make a simple text adventure game. Is programing really the arguous juorny it's shaping out to be?

I'm not saying I'll ever give of, I mean I'll be going to college for this stuff in two years (and yes I know I should have maybe started code sooner), but I was just wondering what the vet's opinions on this were, and maybe how other beginers felt.

Something they teach you (usually in your first programming class) -- "Divide and Conquer" -- you break large problems into many smaller ones. This goes for debugging as well as design of a program.

Find out what parts of your program do work.
Trace its execution first in large blocks (use print statements to log the programs progress) and then in smaller blocks as you figure out what part of the
program is failing.
If logic isnt doing what you expected print out the variables and the results of your calculations and check that it is really doing what you designed.

If you cant trace your logic, then write it again in a different way and spread it out so that you can follow it easily.

Make sure you check for error cases and have appropriate error messages in your code. Once you can see what is going wrong, it usually takes alot less time to fix it.

After you have fixed the problems, you can comment out the trace (print) code (so it can be quickly reactivated if needed) and later you can remove it.


Over time you will expand your programming skills (and your debugging skills)
and the more ordinary things will become almost automatic. Even after 25 years as a programmer, I still have to look new things up in the manuals. There are so many programming areas that I havent touched in all that time and new projects usually require new learning (I only started looking at Python a few weeks ago for use in a friend's project and I learned the basics in a few days, but still saw alot of things that are done differently than the other dozen languages Ive used over the years).