The following article is reproduced from (my master's blog): http://www.hifreud.com/2015/03/11/let-it-go/
It feels great to write, and I recommend it to programmers who are in the same situation as me!
about work
I used to think that I was very energetic and could do several things at the same time, but later I found out that it is not what I thought at all. If I think about everything, I will not be able to do everything well. I am not Windows, and I don't know the macro Parallel and micro-serial, so my attitude is to only do one thing at the same time, and concentrate on doing this one thing and solve it one by one.
About technology
It is a very common scenario to encounter a problem that you don’t understand at work, but there are many ways to solve it. Some people will ask their colleagues directly, some will ask Baidu or Google, some will directly check the API, and some will look at themselves. Summary blog. Each method basically solves the problem, and the key to the problem is what kind of habits lead to what results.
Ask your colleague directly: Maybe you think it's too simple, it's not a big deal to ask, but in most cases, the result is that the problem is easily solved, but the next time you encounter this problem and forget it, ask the colleague again . Week by week. I have never had any precipitation. Even if one day that colleague leaves, the problem will become a problem forever.
Baidu or Google: This has gone up a level. I understand that the problem must be solved by myself. I believe that most programmers are arrogant and don’t like to ask other people’s questions, so they habitually solve it by themselves. But Baidu and Google are also skillful. Some people can find it, some people can't. Here, the programmers are divided into levels. Usually, it is some large technical community that can solve the problem. Therefore, it is better for you to go to StackOverflow, CSDN and other places if you have nothing to do.
Check the API: When the front-end time is used to do EasyUI things, directly open the official website to see the use of the API. At this time, a colleague came to see it, and it was more efficient to talk about how to solve the problem on the Internet. On this issue, our opinions are unified, check the API. Because although Baidu or Google solved the problem, it only solved a point problem, and if you check the API, you will get a face effect. It took a little more time to search for questions and answers, and the results were worlds apart.
Check out your own blog: Programming may seem like a job at your fingertips, but at the end of the day, it's mental work. With the increase of working hours and age, memory will deteriorate, and if you don’t watch technology for two months, you will basically be strangers to you, so you usually develop a record of the knowledge points and encounters you have learned at any time. It is necessary to have a good habit of arriving at problems and solutions. It doesn't take too much time. Every time you encounter it, you can record it. According to Agile's thinking, summarize the problems of the previous period every month. There may not be any growth in the short term. But in this imperceptible, after a few years, the gap is obvious. And as far as the few big cows I have met now, almost all have the good habit of taking notes and writing technical experience at any time. Look up to the bulls.
about habits
Result-driven, don't be complacent because of how perfect the process is, the result is the only criterion for measuring the success of a thing. Habits are developed slowly. I did a Maven migration some time ago. It took nearly 2 days, and there was no problem with the local test, but after submitting it, it ran on others. In the end, I found that the problem was that when I tested, I did not clear the local cache, which caused the local to always be easy to use, and others were not available. Lao Xu said that I have bad habits. Indeed, sometimes I am a little eager for quick success, but when it comes to technology, I cannot be in a hurry, so I can only move forward one step at a time.
Lately I have been staying up late and working overtime. As a result, my memory is completely useless. I forget what the front foot says, and the back foot forgets. I always wanted to make an EasyAgile thing, a personal task management tool. Later, I found that worktile.com has exactly the same requirements as I thought, but it is a B/S structure, but B/S is just B/S. Stick with it, write everything down, prioritize, and tackle one by one.
About thinking
学习技术的思维是一根筋，不要总想着把什么东西做出来了就可以了，大家都是学技术的，随便找个差不多的人，给定足够的时间，大家都可以实现功能，而问题是谁实现的更好，在出了问题的时候谁能更快的定位和解决问题。做技术，多问问为什么这么做，这么做有什么好处，技术细节是怎么实现的，性能有没有问题，采用这种方案会导致什么问题，能不能符合业务需求，出现问题的解决方案或者替代方案是什么。比如Java中的匿名内部类，为什么会出现，是为了回调，在java中不允许像javascript那样在参数里传递方法，所以java的解决方案就是匿名内部类，表象上传入的是一个类，实际需要的只是那个重写方法，并且在JDK1.8中已经引入了C#中早就存在的Lambda表达式，看起来就更像是传入了一个方法。漫漫技术路，思维是既定的，但是这种思维的习惯需要时间来慢慢养成的。
关于项目
最近在做一个私活，后台的接口+维护系统。每当客户跟你聊的时候，你会发现，他口中，所有东西都是很简单的。比如维护系统，在客户嘴里就是一堆增删改查，当然，不可否认的是，维护系统大多数的操作确实是增删改查，但是也有很多的逻辑是很复杂的，并且这些很复杂的逻辑会占到30%甚至更多，会占用开发时间的60%。而当你把这些困难，或者换个词叫做成本告诉客户的时候，客户不会思考自己的需求，而是会直接怀疑你的能力，在他眼里，这种小事情都办不到，或者需要这么长时间，这么多钱，你是在骗钱么。而这时候，你就需要斟酌一下自己的词汇，用更多的口舌来说服对方，这个就是需要这么高的成本。最后结果只有一个就是你做，但前提有两种，第一种是客户妥协，第二种是自己妥协。这个时候，沟通其实比项目更累，
前段时间还跟一个要做商城网站的人聊需求，而对方是完全不懂技术的类型。他的想法是，如果你有一套系统，我可以买过来。即使这个是以前给别人做的。在这个地方，先撇开别人的老路再走还有没有意思的问题不谈，单从版权问题上来聊，就有很大的隐患。国内大部分人的想法是想要免费的，或者最少成本的拿到一套软件，因为在客户眼里，软件就是一个光盘，或者一个U盘，里面存了点代码，甚至，就是一个地址，让他下载了一堆他根本看不懂的文件。这东西怎么就能值几十甚至上百万。这是一个很可怕的想法。就像现在的大学生毕业设计一样，网上下载个Demo，Copy一下，随便改改，署上自己名字，搞定。没有人去关心，背后究竟是谁做的，怎么做的。没有人关心原作者的心血。这是个恶性循环。