Read "Programmer's path to training-from small to expert" read Note 01

The first chapter is about pragmatic philosophy, what is the characteristic of a programmer who focuses on failure? We feel that they deal with the problem, the attitude of seeking solutions, the style, the philosophy, the more direct the problem to think about, always try to put the problem in a larger context, their success is another key is they are responsible for every thing they do.

What does "My code let the cat eat" mean? It's the pragmatic programmers who are responsible for their careers, not the fear of admitting ignorance or mistakes, which is certainly not the most enjoyable aspect of programming, but it's certainly going to happen-even in the best projects, thorough testing, good documentation, errors, late deliveries, unforeseen technical problems. And what we should solve is the most important. is also a character that a programmer should have. This means that we need to be honest and candid, that we can be proud of our abilities, but that we must be honest and responsible for our shortcomings-our ignorance and our mistakes. Responsibility is what you take on initiative, you assume that something is done right, but you don't necessarily have direct control over every aspect of the thing, and you have to analyze whether the risk is beyond your control, and you have the right not to be responsible for things that are impossible or too risky to do, except as far as you can. But you have to make decisions based on your own moral standards and judgments. When you meet a variety of situations, you can propose solutions instead of looking for interfaces and justifications. Don't say things can't be done, to show what can be done to save the situation.

"Software entropy" refers to a system of "disorderly" total, unfortunately, the law of thermodynamics to ensure that the universe of entropy tends to maximize, when the software "disorderly" growth, called "program decay." Many of these factors can lead to "software decay", the most important of which seems to be the psychological (or cultural) development of the project, "broken window Theory"-if a perfect city only a broken window, as long as a period of time ignore, will give the city an abandoned feeling, so there will be another glass broken, People began to litter, there was a doodle graffiti. Then the abandonment becomes the reality. So in a software, we can't tolerate broken windows, if some bad code, the team regardless, slowly these all the code will become garbage. In the same way, you don't want to be the first one to mess things up.

The moral of the "Stone Soup Boiled frog" is that the soldier became a catalyst, uniting the villagers, and doing what they could not have done with them-the consequences of collaboration, and finally everyone was a winner. The most important thing is that you will do the catalyst and make the catalyst for change. Remember the big picture and don't undermine the morale of the team because of the little things. Just like "boiled frogs in lukewarm water", we want to keep observing what's happening around you, not just what you're doing. "Good enough Software" lets your users take part in the tradeoff, making quality a requirement, and today's great software is often preferable to the perfect software of tomorrow, and if you give users something that they can use early, their feedback often leads you to a better final solution. "Communicate" know what you want to say, jot down the ideas you want to communicate, and prepare several strategies that tell them clearly. To understand your audience, you need to understand the needs, interests, and abilities of your audience. Choose the right time, you need to figure out their priorities, sometimes simply ask "now we can talk ...." ? " It's OK. Choosing a style is also important. Try to make your documents look good, get listeners involved, and respond to others. It's just as important to remember what you say and what you say.

Read "Programmer's path to training-from small to expert" read Note 01