"Reprint" I wish I learned programming, someone taught me these things!

1, before learning programming, want to know what you want to write.

Learning programming is basically learning to build things. If you know exactly what you want to build, your way of programming learning will be enlightened.

If your goal is simply to "learn how to program", and you don't know exactly what program you want to write, or how these programs will make your life better, you're likely to feel frustrated by programming learning.

It was a little embarrassing, and I wanted to learn programming because I wanted to prove that I was smart. And I want to do a job that belongs to the wise. I also like to think about math and theory. So, programming how to look at me very well.

But these ideas are not enough to perpetuate my passion for programming. Until one day, when I finally found out how to connect technology (programming) with my true love---music and literature---, I really fell in love with programming.

So, what do you want to do with programming?

Website? Game? iphone app? A start-up company that makes you wealthy? Interactive art work?

Do you want your boss to be impressed with you, or do you want to write a program that allows the computer to help you with a tedious task so that you can spend more time watching the otter's photos?

Or maybe you just want to be more competitive in the workplace, add a buzzword to your CV (program), or meet your school's graduation requirements.

These are valuable goals. You need to figure out your goals, and then study them in a targeted way.

2, programming is not a mystery, it is not difficult.

There is no essential difference between programming and other skills. Just as there are grammar and words in language learning, as in mathematics there are different steps and different topics, like all skills and crafts, the programming also has the skills, tools, and good habits that have been summed up by predecessors for different tasks.

You are free to use, modify, or discard these things.

One person once concluded that there is a clear distinction between the program Daniel and the world of programmers---the latter often lacks sufficient intelligence to achieve true success in the programming world. In this person's view, this intelligence contains the understanding of pointers (pointers) and recursion (recursion).

I've learned pointers and recursion at school. In the student age, the feeling of being able to understand pointers and recursion is really super cool. This thrill inspired me to embark on the path of computer learning.

But in addition to the classroom practice, I rarely need to touch these two concepts. And, as I was teaching others how to learn programming, I also discovered over and over again that people could write very interesting programs without these two concepts.

So don't be afraid, and don't think about whether you're smart enough. There's no point in thinking about it. Yes, the more complex the programming task, the harder it is to understand, the more skill you need to be able to accomplish.

But which area is not so? Unless you are programmed to live your life, it is unlikely that you will need to understand recursion in programming.

3, no one can fix it at once.

When you first learn to program, you will quickly hit a problem like this. You think you've configured everything, you checked and checked, but your code is there! Ask! Problem! You have no clue as to how to get the wrong line.

The error message (if you have any luck) is likely to tell you---"I'm going". At this time, you are likely to want to give up. You think you'll never be able to handle it, and feel like you're not programmed.

Hey! I had the same sense of frustration when I first tried to write a C + + program that ran and just got the error code like "Segmentation fault".

But this experience is normal for any programmer of any standard. Having this experience does not mean that you have any problems with your IQ, technical perception, or the suitability of your programming.

Whether you are a programming recruit or a program Daniel, you will experience such experiences. The difference between a recruit and a bull is how to deal with such experiences.

One big difference between a recruit and a bull is faith. What faith?

Is convinced that the cause of the error is logical and can be found, convinced that the problem can be resolved, and that there is always a way to achieve their goals. The road from 0 to 1 may not be obvious, but as long as you are patient, you can usually find it.

4, there are always people say you do wrong.

How should curly braces {} be put? Should you not use tab to indent? Should I add a comment to the code?

We have different approaches to these problems. No one has a standard answer. Many programmers are keen to sell their preferences in the sort of way they do, but that doesn't mean there's only one answer.

In fact, it's one of the stressors of my career to go back and forth with people who say I'm wrong and then try to figure out if they're right.

If you write code with other members of a team, there will always be people who disagree with your behavior.

Sometimes they are right, but in fact you are! Right! Is! Wrong! It is always worth your own scrutiny.

Sometimes they are purely unreasonable, you do not ignore them just fine.

5. Someone will always say you are not a real programmer.

Look at these statements!

"HTML is not a real programming language. ”

"If you don't use VI, you're not really a programmer." ”

"The real programmer has to understand the C language. ”

"Some people just don't fit the programming. ”

"Some people just can't learn." ”

"You're not really a programmer at all, I am." ”

I would say that programming has different meanings for different people. Meanwhile, the meaning of programming is changing over time.

Interestingly, those who can make beginners, even programming veterans, faster, easier tools, packages, frameworks and so on will often be labeled "real programmers should not use" such tags.

There is a fear behind this labeling behavior: if anyone can call themselves a programmer, the title will be meaningless. However, I think this kind of inward-thinking behavior is harmful.

Use the tools that make it easy to write programs. If that means you're using stencyl or Gamemaker to write a game, instead of writing a new one from scratch, it's okay, just do it.

If the first time you try programming is from HTML or Excel macro, just go ahead and do it. Which one (programmatically) you can stick to, which one you use.

As your technology continues to improve, you'll find that the convenience tools limit you more than you can help. At that point, you'll be looking for more powerful programming tools.

But most of the time, very few people will look at your code, or ask you what programming tools you use. It's really important that your program is good or bad.

6, insist than method more important.

There are a lot of articles on "correct programming Learning Method" and "Best programming Learning Method". Indeed, there are many ways to learn programming.

You can learn by reading, you can do exercises to learn, you can give other people's programs to catch worms to learn. Of course, there are a number of programming languages you can choose to use as your first language.

A self-paced programming course or lecture series often has a problem: you always learn very well at first, but the difficulty will rise steeply.

The Print command is always simple, but it is often maddening to actually write a utility program. You probably feel like you're not getting along with the tutorial, and then you start complaining about the tutorial's problems.

When you hit this "programming glass top", those tutorials and online resources mean nothing to you, because they default you are already a programmer.

The more difficult factor to make the whole programming learning step is that you don't know what you're missing (you don't know what do you don ' t know). Even figuring out what you need next is a problem.

No matter what the programming lesson, you will have such a "wall period", the only solution is to stick to the end.

This means that you have to constantly try new things, learn new knowledge, and constantly, step by point, to solve problems, to make up the program you want. If you look carefully at your programming beginner's mind, you are more likely to succeed.

Hold on to the end and you will win. This is the value of the beliefs I mentioned earlier. If you really stick to the end, you will really win.

"Reprint" I wish I learned programming, someone taught me these things!