Reading in a new week will naturally bring new experiences. Every time I pick up a book, I will have different perceptions and feelings. When I recall my original thoughts, I can’t help but have the thought of “Why did I think so at the time?” Sometimes I can't help but admire this idea, but I also sometimes question myself why I had such a stupid idea at the time. Everything is due to my understanding of the world and having a different idea. After all, I am no longer the me I used to be. People are making progress. Maybe what I didn’t understand when I read books at that time is a piece of cake now. After more experience, my understanding will become wider, and I am naturally reading. There will be a deeper sense of identity and reflection.
"Wait a moment, more deliciousness, more enjoyment" is vivid and easy to understand, but what does it really mean for programming? I found that in the two books I read, there are authors who use profound principles in other fields to make sense in programming. In my opinion, the reason why programming can be used is that it is too basic. , it seems to be a particle or even an element that creates the world. The foundation of everything comes from the most basic code. This work is to create a new thing in a new world, or even create a new world. It seems that all the big principles can be used in programming.
The book introduces the reasons for the delay of the project. This is what I can say is the most needed and ignorant place. When I actually started the project mentioned in the book, I found that everything was not as simple as I thought. At the beginning, I started with full confidence, but I found myself lagging behind my tasks again and again. The tasks that I planned to complete in a week are only halfway through, and there are still a lot of problems. When it comes to the need to replace the framework, I will not underestimate this task at all. It was only after reading the book that I found out that this reason may be a main suspect - the lack of a reasonable time schedule, which is true in retrospect. After all, when I first came into contact with it, I knew nothing and needed time to learn, but when it came to the real time, I was swayed by it. The pile of troubles is entangled in the feet, that is, the time that I originally expected to be reduced, but my work has not increased because of the reduction of time.
That's what I'm going to say next, what is the reason for this generally disastrous lack of a reasonable schedule? The book lists five points, all of which are deeply rooted in the hearts of the people. First, there is a lack of effective research on estimation techniques; second, they mistakenly confuse progress with workload; third, due to lack of confidence in their own estimates, software managers are usually not patient. The fourth is the lack of tracking and monitoring of the progress; the fifth is to increase the manpower when realizing the deviation of the progress. When I saw these five items, I immediately realized that I had satisfied two items, the first item and the second item. I could see signs of these two items in my body. The first item was the first item. Research can be said to be very lacking, but I only have a general understanding of what it does, but I am not particularly proficient in specific operations, so that I cannot effectively estimate the time progress of my work, which leads me to spend some time. Unnecessary waste, especially the second item, I didn't separate the progress from the workload. At the beginning, I felt that the greater the workload, the faster the progress, but now I see that I have entered a dead end, It makes sense to think about it carefully. I think I have done a good part of my previous work, but in the end, I found that the work I did did not reach a level that was recognized by everyone, which led to the embarrassment that I needed to change the framework. That is to say, I am afraid that my progress has only just begun, which means that the nearly 1,000 lines of code I originally compiled accounted for a very low proportion of the progress of the project, that is, the completion of the project. I am afraid I will doubt my life.
To say that I am optimistic, I am actually quite optimistic. After reading this book, I realized that optimism is not something that a programmer likes too much. The specific reason is very reasonable in the book. Computer programming is based on a very easy to grasp medium. We can develop programs in the form of very pure thinking activities, that is, thinking concepts. It is precisely because of the easy control of the medium, we will realize It is expected that there will be no difficulties in the process, which is one of the reasons for optimism. The reason why our optimism is not accepted by some people is that our structure is flawed, so there will always be bugs, that is to say, we There will be difficulties we never imagined. This is like "tailor-made" for me. When I first come into contact with some languages, I will have "this language is easy to understand", "I can easily realize my own ideas by doing this"... ...but when I really get started, I find that there will be some bugs I never thought of at that time. Take the assembly language I recently learned, I understand some of its principles, and use some of my own ideas. Implemented, but found that in the end, if the program crashed or ran an error, my original optimism also brought myself endless debugging pain.
Life is worthy of being our best teacher. One or two profound lessons will teach us things that cannot be remembered even by reading several books. Natural integration is an avenue for reading.