"Two tips for becoming a good technician", which is very important in this blogProgramI wrote this article when I felt very interesting and touched on the attitude of the task.Article.
First.Don't treat the code you not own as blackbox
In reality, due to the time relationship, this is often not possible, mainly because of the reality of outsourcing processing in China or the boss to carry out project control and performance assessment by task progress, however, this method is the only way for a programmer to go from ordinary to excellent. Think about how we should not be a daily keyboard-hitting worker. If you think of a really thoughtful programmer, complete a SectionCodeIt's just a few minutes. If you really want to talk a lot of time, you should be familiar with the components and component relationships of the entire system. Another utilitarian idea is that if I design the entire system and start a company on my own, it doesn't accelerate my own initiative to learn other components. :) although this method is not advisable.
Second.Don't assume, just confirm
It is true that when we encounter problems, especially debugging, we always feel that there is no problem, and there is certainly no problem, so what exactly is the problem, the only way is to create a checklist one by one confirm.
After reading the comments, I thought ofPay-as-you-goAndPiece rate assessment. Currently, the pay-as-you-go system is widely used in China. Most of our programmers have solved many problems in performance appraisal to assess how much they have done. And boss always requires you to finish your work quickly. The boss is concerned with the progress, cost, and benefits. This kind of consciousness at the upper layer leads programmers to make a quick picture without making a good picture. You can think about how to support your family.
I just saw a case about the implementation of the piece-rate wage system. It said that when a manager went to implement this system, everyone complained about the strike and eventually the manager was transferred to another factory. Another Manager also needs to implement this piece-rate wage system. However, this manager first raises the level of everyone and tries to partially implement this system, finally, it was successfully implemented within the company within 10 months.
therefore, the two points raised by the author are effective methods for improving the quality of programmers. However, due to the current situation, we become code workers (the same as garment factory workers ), if the enterprise's senior management is not aware of this problem, it will not fundamentally solve the quality problem of the enterprise's software, nor can it improve the software quality. Because code workers are all starting from completing tasks , regardless of the quality, this attitude often wastes a lot of time, the overall quality is reduced . Therefore, to better solve this problem, the project should first give everyone a certain amount of time to adapt and improve their skills, and then Strengthen Quality Inspection (QC ), in order to be a win-win situation . If the project is outsourced and the project cycle is short, you can consider establishing a long-term mutual learning mechanism (in fact, it should be within the scope of corporate culture ), the Pair Programming mentioned in agile development is to establish a mechanism for mutual learning, mutual improvement, and mutual communication to improve the project. quality.