The professional quality of programmers was originally called "The Clean Coder". Just looking at the title of the book, you may think that this is a technical book explaining how to write concise code, but it is not. In contrast, the Chinese translation should be closer to the theme. This book is the experience of the programming master Uncle Bob for more than 40 years in his programming career. People lead the way.
On the one hand, this book expounds the author's insights and suggestions on agile development, and on the other hand, it explores what attitudes, principles, and actions need to be taken to become a truly professional programmer. And these seemingly unrelated things often determine the upper limit of a programmer.
What makes me more gratified is that although we are too far away from the author now, he himself has stumbled along the way, and many places can resonate, and seeing these places is an encouragement to himself again and again. This undoubtedly gave us enough confidence.
About rejection
A lot of non-technical books have mentioned this about rejection. The author has made a complete analysis here based on his own experience. In short, the company has to work overtime all day, all night long, every time it reaches the exit of the iteration, and the customer complains after the version is released, and all night positioning, all these are because this team of programmers is not professional enough!
What is the requirement, it cannot be clarified only by a requirement specification, so there will be subsequent customer dissatisfaction, redo; unit test, there is never time to write; automation? Hehe, just a click of the mouse is enough, what do you automate? ...software plays like this, no wonder programmers get tired.
If you encounter such a leader without team spirit, or the leader's ability is not good, the business personnel (more often the leader) promises the customer (more often the leader's leader) to complete a certain product on a certain day. Then pressed the underlying technical staff to work overtime desperately, all of which were caused by unprofessionalism. Based on his experience, the author tells us that this is wrong. For such a team, such a leader should be able to say "no", but if his own ability is not enough, he often has no "confidence" to say. This is a very contradictory thing. The author just proposed an ideal solution, which is actually much more complicated, but being able to recognize this and dare to refuse when appropriate is a great way to avoid programmers from falling into the trap of the workplace. important thing.
About commitment
Rejection corresponds to promise, rejection is to keep promise. People who don’t understand rejection will gradually become people who don’t keep their promises. Just imagine that too many promises are too full. Even if they have the heart to fulfill their promises, they are often unable to fulfill them. It's also possible, of course, that he never took keeping his promises seriously. A truly professional programmer should think carefully before committing, avoid committing too hastily, and not be afraid to commit without taking any responsibility. Of course, it's not just the programmer's responsibility, a good team is especially important. But unfortunately, in the contemporary Chinese job market, there are too many unprofessional teams. They will ask you to do 3 days of work in 2 days. If you dare not promise to complete it, then this job will not be yours. Yes, but assuming you agree, it often results in a delay. But that doesn't matter because they're used to delays. Some books criticize this practice of committing first and then delaying completion, but unfortunately, there are too many unprofessional teams in the market. I really hope that such a team can love less and less, because only a group with enough professional time evaluation and enough team spirit can create an environment that keeps its promises.
About programming
This may contradict the experience of most people. The authors caution us to try to avoid entering the fluid regime.
The so-called fluid zone is when programmers enter a state where their consciousness is highly focused but their thinking horizons are narrowed. I have a deep understanding of the highly focused state, that is, when programming is the most enjoyable, I am eager to see the program running and eager to enjoy a sense of accomplishment. In the eyes of most people, this state is a good state and can be immersed in. in the joy of programming. However, this is a state that the master needs to guard against. At this time, the thinking and vision will become narrow, and the compiled code will often affect the entire architecture. How to prevent entering the fluid zone, which brings me to TDD. Many people reject TDD, but it is actually the fluid state that affects their judgment. The three laws of TDD prevent them from "smoothing" programming. Assuming that what Uncle Bob said is true, the fluid state is indeed not the best state of programming, then TDD can really solve this problem, at least it can solve this problem for most people. It allows programmers to think about requirements, write test cases, write code, and refactor in the process of programming, instead of letting programmers run freely in coding.
Although I haven't finished reading this book, I have already benefited a lot. If I start working in the future, I will think of Uncle Bob's teaching from time to time, participate in a professional team, cultivate a professional attitude, and develop a professional habit. Be a professional programmer.