Self-study is better than learning skill% programming __ Programming

One day, a friend of mine who was learning to program asked me: "I want to quickly learn programming, do you have any good recommendations?" I taught myself to program when I was in college, and after all these years, I realized that I was probably in the hardest way to learn and understand programming. I could have learned at a faster pace. So, after reviewing the past, I wrote about some of the things I've learned over the years about how to learn programming.

"Fast"

In fact, I really don't know what "fast" is about "how to learn programming quickly". I feel that by following the recommendations below, you will soon learn to program (at least your growth/progress will be faster). But you really should not be in the eye only "fast". Only the pursuit of speed will drag your hind legs, let you suffer the consequences. The only sustainable way to "fast" learning may be to use immersion-based pedagogy. Find a way to immerse yourself in programming for a long time (several months. ）。 To make it work, you need to constantly push yourself to learn new things and quickly get out of the way. This is an advantage of coding training camp. When you come out, even though you are not an expert, you will learn faster. This can also be achieved through a dedicated tutor or learning with a dedicated beginner. 1. Read > Write code > Read > Write code ( day after day)

The first piece of advice I'm going to give you about how to learn programming efficiently is to go through the loop between reading the code and writing the code. Reading the Code (books, blog posts, open source code) will help you see the solution, learn about best practices, and get an overview of the language or system. But after you do this, you need to actually write the code yourself. can be anything. It can be a small coding exercise or an amateur project, but make sure you can put it into practice and use what you've learned in some way. If you don't, you'll find yourself facing the editor at a loss.

The trick is to make yourself uncomfortable. It's quite painful, but it should be. Code follows 80/20 rules. Spend 80% of your time on 20% of the code or 20% of what you've learned. Getting used to this uncomfortable feeling and overcoming it is key.

This iteration cycle should not occur on a weekly or monthly cycle, but rather on a daily cycle. The longer the knowledge waits to be used, the more blunt the axe of knowledge is. The longer you wait to learn new knowledge, the harder it is to incorporate it into your code.

I recommend reading the website about common programming topics is lobste.rs. There are many articles on many programming topics. Another good site is hacker News, but the site often deviates from the topic. 2. Don't get bogged down. Ask for help

My biggest mistake was to spend too much time learning about programming at an impasse. When I get stuck, I spend a lot of time on stupid things or something that I don't understand fundamentally. Sometimes it takes me a few days to finish the work, and I could have spent more time doing more things and learning more things if I could find a better solution. Being stuck on a thing for over one hours is basically a waste of time.

I recommend three things to avoid gridlock. The first is to try to always read more about the technology you use and master what is going on. Often, when you are in trouble, it means that you make incorrect assumptions about what needs clarification. The second is to consult the Internet. This is obvious, but still worth mentioning. Finding and asking people who have had this problem on the Internet is a very important skill. StackOverflow can be said to be the best web site on the Internet. Don't be afraid to ask yourself questions there. Usually, it's OK to try to properly articulate your problem. I really hope I can ask more questions before, but I always stop because I'm afraid of being stupid. My third suggestion is to ask for help from someone you know. Often, you may have understood the technology and had problems, but you might need a higher level of context to really unravel the mystery. Do not be timid, dare to go forward to ask it.

For example, when learning Docker, I spent a lot of time rebuilding images from the beginning. I fundamentally do not understand the Docker cache and use 20 minutes to wait for individual changes to dockerfile through. I may have spent 8 hours on waiting for the build. If I've read more about Docker or asked someone who knows, then maybe I've figured it out, and I can learn more in a shorter period of time. 3. Work for the project

In my experience, nothing can be more useful with working on your own projects to learn programming. With some exceptions, all the really good programmers I know have a habit of working on an amateur project (which can also happen at work.) ）。 Having an idea and trying to achieve this idea is very challenging. It requires a strong self-discipline. However, by trying to actually do one thing, you can learn how to decompose the problem and application technology. The various problems you face and how you solve them are really called programming. Knowing every wacky detail of a programming language can be helpful, but it will only make you more and more outdated. In addition, the drive to complete a project is the driving force for continued learning. The satisfaction gained from an amateur program is far more satisfying than what you learn in abstraction.

My advice for choosing an amateur project is to choose what you are interested in and how you can achieve it. Being able to express the implementation before the start always helps to keep me motivated. You will certainly learn a lot during this journey. 4. Recognize the distinction between deep delving and porters. Select accordingly.

There are two types of programmers: perfectionists and porters. Some people want everything to be right, they want to be perfect, they want to follow all the best practices, and write beautiful elegant code. They want to understand each line of code. Unlike those who are not 3,721, as long as their code can work, even if there is damage to the code base. It is very important to balance these two skills. Sometimes you should delve into a question or project and see what happens. Sometimes you should let it work, even if you don't know what's going on.

Whenever you spend too much time on something, ask yourself: Which method should I take? In most cases, you will want to take a median. You want to provide a good, solid solution, and you can confidently understand and modify it, but without wasting ridiculous time. As you grow as a developer, you will be better able to understand when to leave and when you need to do it in some way.

Personally, I like my project 80% perfect. If your project is absolutely 100% perfect and no line of code makes you feel embarrassed, then chances are you've spent too much time. 5. Talk to other programmers

A good way to learn programming is to talk to other programmers. No need to talk about any particular content. It can be something you're learning, something you think is cool, something you're working on. You'll find that many programmers don't like to just talk about programming. Doing so may allow you to learn a lot about libraries, services, programming languages and patterns. But, most importantly, you will learn how other people think about programming. You will find that things that you take for granted or have never considered are very different between people.

If you have nothing to talk about, go back to the topic of Editor Wars or Tab vs space. 6. Try everything. If you don't understand it, wait 6 months.

Finally, I would like to say that this has always happened to me, I have tried a lot of things, but I just do not understand. After 30 minutes of trying something new, I'll stop. I think it's quite normal at the start. But I remember many times, after 6 months (or 3 months or 9 months), I would go back to the same question or technique and figure out how to use it. This is because I have mastered some knowledge that I did not have before, or because it is just another way of framing. Waiting for a while and then going back is always one of the most useful ways.

An example of this is learning how to use the terminal. I remember that for a long time I was afraid to touch the terminal because I didn't know how to use it. I spent some time and followed the steps to use it regularly and to understand it. Of course, if I know someone who can answer me, or find a good resource to learn, this will not happen. Conclusion

These things can help novices learn to program in their long journey. I know I have more to learn and will continue to learn how to learn forever. The most important thing to say three times, please continue, do not give up, do not give up, do not give up. Of course, it's easy to say, because learning to program can sometimes be frustrating. Don't worry. This is normal. Everyone has experienced this kind of mood.