Frozen three feet is not a day's cold - self-study chapter on personal learning methods

I was still watching the game (war3) last night, Xiaoyuan came over and asked me about 1024 tomorrow, why not write an article, think about it, 1024 is also a hot topic, hurry up and rub it, ha, just kidding.

Last time I talked about my blogging experience, so this time I will start from myself and think about how to learn. First of all, I will show the following:

I am an Android developer who just entered the industry. The following how to learn is described by my own method, which does not mean that it is suitable for everyone. It is only a suggestion for reference.

I used to spend a lot of time studying and playing games during my school days. Since I joined work, I have found that the allocation of time is becoming more and more important. During the interview, when I asked about the third-party libraries used in the project and some hot questions, the answer I often heard was that I didn’t understand it, the business was too busy, and there was no time at all.

Well, in fact, the business is really busy, and if you don't work, where will you get the salary. So after going to work, how to allocate time is a critical issue.

One of the biggest feelings I have after going to work is that there is not a lot of whole time, and the rest of the day is about 3 hours after arriving home at night, and these 3 hours may not be fully devoted to learning.

So make sure to use your spare time wisely.

Prepare a TODO application

学什么Don't let this problem waste your time since there are no very large blocks of time. Because every time I want to learn something, I will habitually open QQ, and then I may be attracted to play Dota (~~(>_<)~~)。

So, prepare a TODO application and throw the question of what to learn into your daily life.

  • For example, when taking the subway, I read the articles pushed by WeChat, and when I encounter something I don’t understand, write down the key words.
  • At work, when occasionally searching for a problem, when you find some knowledge that you have not known before, write down the keywords first; after the work is completed, come back to study with the keywords.
  • In the process of reading the book, you may also encounter some points. The book is not very clear, but you really don't understand it, so write down the keywords.
  • In the process of bragging with your peers, write down the keywords that others mention that you won't know.
  • When the QQ group is bragging, although the group is very watery, it is still possible to capture some keywords that are not understood.

Don't trust your memory, a good memory is not as good as a badly written true sentence.

Therefore, prepare a TODO application or a handy sticky note, as long as you can conveniently record keywords. When you have time, look at your log sheet, pick a keyword, and spend 2-3 hours digesting this keyword.

I wrote a demo myself to record:

After a period of time, you can see how many knowledge points you don't know you have encountered and how many you have digested now.

I used to like to save bookmarks, but later I found out that keywords are enough. I believe that programmers can use search engines well.

Develop the habit of taking notes

Taking notes is a great habit.

First of all, you should have a notebook; of course you can choose electronic, but I like paper.

  • At work, to conduct research, analysis, and final solutions to some problems, you must remember to summarize, organize, and write down these things in your notebook. Otherwise, the next time I encounter this problem, I have to find the code, and I have to think about it when I find it. It would be embarrassing to write it like this at that time.
  • Reading a book, if you have a book, it is basically impossible that you will not know all the things in it, and you cannot know all the things. Therefore, when reading a book, put a notebook next to it, and write down the good places you see (or things you haven’t paid attention to before) in the notebook (you can verify it based on the notes later).

    But I usually write some keywords directly on the table of contents that I don't understand, and then maybe read the marked parts again (maybe a few times), and finally record them in a notebook, so that you can put a This book, condensed into a few pages of notes, will save you a lot of time reviewing later.

  • Watching videos, I watch very few videos now, but I watched countless videos when I was in college. The best product of watching videos is the notes. The code may be lost or forgotten after a long time. With a little impression, it is still very painful to find a certain knowledge point in the video. Besides, the video takes up so much space, it is better to delete it and replace it with a new one. So, condensing countless videos into one notebook is still very good.

    There are so many good videos now, and I don’t need to recommend them anymore, everyone understands them.

  • Look at the blog, um, ditto, and record what you think is worth recording.

Develop a good habit of reading source code

Source reading, well, especially for third-party libraries you're using.

Never learn any source code during the interview. The reason is that the business is too busy, and what's more, "I don't think it's useful".

Reading the source code, I generally divide it into two types, one is rough reading;

Probably, according to the entry used, generally view the relationship between classes, the calling process, and understand its internal principles. For example, retrofit2, roughly read, understand that the core is dynamic proxy, and it actually relies on okhttp3 internally. The way of annotation in the interface method is actually used to extract and construct the request of okhttp by reflection.

Another is to read carefully;

Careful reading is to look at it very carefully, think about why it does this, and even if you encounter a better treatment of a certain place, you can take a notebook and record the code completely.

Rough reading to understand the general principles, and careful reading to absorb its essence.

Of course, it's easier said than done, so come on.

Note that the premise of reading the source code is that you know what it is used for and the basic usage. Don't just grab a library, come up and read the source code, why bother~

Long-term technical learning planning

The above points are accumulating relatively scattered knowledge points.

This is mainly a general direction of the study plan.

  • Set a deadline to finish reading a book. Whenever possible, consider maintaining a long-term reading plan. Not much to say about the benefits, don't care about the money of a book, it's worth learning a little something.
  • For long-term study plans, if you encounter some things that you don’t usually use, but want to learn but can’t finish in a few days, you can list them as long-term study plans, such as framework, a scripting language, React Native, etc. You can find a few Learning with a friend, mutual supervision may be easier to stick to. I have found a girl to learn framework together, one aspect every week...

Alright, that's how I learn~

Quantitative change leads to qualitative change. If you don’t stick to it, no matter how good the learning method is, it is useless.


Welcome to follow my Weibo:
http://weibo.com/u/3165018720


WeChat public account: hongyangAndroid
(Welcome to pay attention, don't miss every piece of dry goods, support submission)

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325765654&siteId=291194637