Thinking about two years of development

         This year has been quite busy. In August, it was a little looser, but then it started to get busy again. Although I was busy with work, sometimes I could not help but fall into the stream of thinking and reflection. In the past six months (until now), after some teachers' teaching and thinking about the problems encountered in development, plus reflection on what some teachers have said before, I have a little idea about products and projects, which may be Experts and people who have come here are laughable and generous, but at least some of their own insights are briefly discussed here.
        This year is 2014. I entered the company as an intern at about this time in 2012, and I became a regular after the new year (spring 2013). It has been two years since I started developing the Zigbee network analysis system project in 2013. I was a C# winform programmer just getting started. I didn’t have any ideas or anything. I just knew some basic C# syntax. A lot of things have been touched, but only after knowing that there is such a thing. I remember that when a preliminary version of this project was developed, the main interface displayed some Zigbee packet structures, and some roughly analyzed Zigbee network nodes. Among them, there was a function called fake node (fake a network node to communicate), I did An interface that displays a drop-down list for users to select the node address, and some things that ordinary users can't understand at all. Then I did this function without any feedback after the function was executed. Although I knew that the function was executed, it was executed. There are not many obvious prompts and feedback for success and failure. At this time, the company needed to demonstrate this project at the Beijing Internet of Things Conference. I just fixed some obvious bugs, and then the company took the system to Beijing. After I came back, I was disciplined by my teacher (the boss, but a teacher than the teacher). He said a sentence: "Look at what you are doing. What we do will be used by others in the future." A simple sentence, I was very dissatisfied at the time, isn't it just used. At that time, I had the same thoughts as those who read this sentence and didn’t understand it. The above story is not the point, the point is the latter sentence. Let’s take a look at some of the things I have developed in recent months.
       During this year's development, I was confused about a project for a long time. The boss in charge of the project (also one of my teachers) has criticized me many times. He said this: "This project should be delivered by XX (me) Go, you take what you have made to face the customer, let you feel the difficulty of pre-sale (it should be pre-sale, I didn't remember this clearly), you will write programs with your heart in the future", when he said this At the time, I was still complacent that I wasn't a pre-sale. However, one night when the development was about to be completed (those times were very busy, I went back late, and sometimes worked overnight overtime), I couldn’t sleep for a long time, because I was thinking about this project, and Buddhists advocated epiphany, just when the development was about to be completed. I had an epiphany and figured out the entire project structure. The more I thought about it, the more excited I became, and I basically didn’t sleep. This is not the point, the point is that after I understand this project, I am disappointed with what my colleagues and I have been busy with for half a month. The day after I figured it out, a client came to visit. I had to adjust it in advance for people to see, but at this time, the bright spot appeared. The program of the system that controls the switch light button of the smart home collapsed at the touch of a button. , and most of the above functions can't be used, and you can't even watch it, because some interfaces will pop up a lot of MessageBox at one point, and one will pop up again, and it's endless. Although I was very disappointed and angry at this time, I still didn't realize it deeply, because I thought it was because there was no testing and modification after the project was completed.
         As the old saying goes, people can be used as a mirror to understand the pros and cons. The following story has aroused my thinking. Recently, a colleague wrote a program that I can understand, but because I can understand it, I feel like I wrote a bunch of programs. When he gave me a bunch of programs he wrote, he asked me to finish it At the time, it took me two days to fix it. You may be wondering if I have refactored it, but I didn't. After I fixed it, I gave it to him. Seriously, it was very painful for me to change it. Since the lower computer changed the protocol, the program needs to be adjusted. Since he didn't read it or thought I wrote it badly, he made a mess and then asked me how to change it. Just when I didn't ask how to change it, he Said to me with an air of arrogance and disdain, let's go, and I'll rewrite it myself. This... I broke out at the time. I spent two days and traveled and didn't write anything, and I was greeted with cold water when I was complacent. How can I accept it? However, this incident stimulated me. When I was thinking about the programs I wrote with him, I suddenly remembered what the two teachers said before. Money, when the project is delivered, we need to give an explanation. We can't mortgage the colleagues who deliver the project with the customer and leave it alone.
         Having said so much, many people may still disagree. I used the word "project" before, and then we have to think about the word "product". What is the difference between a project and a product? I have read that Mr. Liang Zhaoxin (the first generation of famous programmers in China, China's software industry has experienced an era of "personal heroes") once said some words in "Proverbs of Programming Experts", which roughly means making products. Most programmers don't eat youth food. Only programmers who are doing projects or those who don't even count as projects eat youth food. Maybe it's a bit exaggerated, but as a programmer, I think that making products and making projects are definitely not the same thing. Level, although the project is also used by people, it is definitely not as delicate as a product used by many people. Take my first story as an example, the user can't understand what the interface displays. When you click to run, who knows if the program is running or not. Take the entire interface as an example, no one knows that this function is done. What, not to mention the good-looking interface and stable functions. After thinking about it recently, I really understand the saying that as a product, it is intended for people to use. People have paid for it, and the money is earned through blood and sweat. I wonder who is willing to spend money to buy a product with bugs everywhere. Well-functioning or hit-and-miss software? What's more, large projects are very valuable, moving shafts of millions and tens of millions, how can we make reliable software for people to use with such an attitude? When I see some teachers, even if they are small, they will be as serious and careful as a very important thing. I am not only thinking that this attitude may be a product-making attitude. It is said that the quality of German things is very good, especially in the previous German period, some things built in China were not bad for a hundred years. In the past two years, there has been a mobile phone called Meizu. It is said that the head of Meizu has the same extreme attitude of doing mobile phones or doing things as Jobs. I feel that in the future, we should have the same spirit as making products. To achieve the ultimate in everything, we may not be able to achieve too many functions, but at least the functions must be stable. No matter how much tossing, there will be no problems, as long as the user is not closed It, it can never crash. Of course, it is difficult to achieve this level, but whether it is difficult or not, we must work hard in this direction. When you think carefully and make things carefully, there will be bugs, but there will be many, many fewer, and then they will be improved again after rigorous testing. At this time, I will have a very relieved and satisfied feeling in my heart, and I will no longer have to be like before. When I paid, I couldn’t put it down, I couldn’t eat well, I couldn’t sleep well, and I couldn’t sleep until the middle of the night and be called back to the company to adjust the program. When the salesperson demonstrates the system to the customer, we can give it to them with confidence, without worrying that something goes wrong and embarrassing. I would like to use this article as a summary of my thinking in recent months. I hope that I will always remind myself to be perfect, the program is stable, and I will never be a driver in the future. . .

                                                                                                                                                           On the evening of October 30, 2014

{{o.name}}

{{m.name}}