Although the main title of this book is 「 Clean code 」, But in fact, the main content is ： How to be a professional qualified programmer . So subtitles are more appropriate as main headings — 「 The professionalism of programmers 」.
Programmers are professional technology ,「 Professional quality 」 It's something we need to keep looking for throughout our career , It's not just your pure technical ability （ Of course, excellent technical level is necessary ）, It also represents your ability to solve problems and create value . in other words , Personal technical ability does not fully represent the value of your profession as a programmer , More importantly, the way you think about and solve problems 、 Commitment to the task 、 Cooperation among colleagues, etc , Finally be able to lead the team to complete one seemingly impossible task after another ！
I will follow the writing ideas of this book , Pick a few ideas , Introduce the general content and my own feelings , I hope it will be helpful to the readers of this article .
" Professionalism " It has a deep meaning , It is not only a symbol of honor and pride , And it clearly means responsibility and obligation . The two are closely related , Because you can't get glory and pride from things you can't be responsible for .
This chapter mainly describes the requirements of being a professional engineer ：
- Assumed liabilities
- Know your field
- Keep learning 、 Training
- Cooperation and coaching
- Understand the business area
- Be consistent with the customer
As a qualified engineer , The first thing is to know how to take responsibility . This is crucial , Because this is the most obvious characteristic that shows whether you are reliable or not . Whether the task can be completed on time , Test and verify the system before it goes online , Even if it's because of your own mistakes , We need to take responsibility , Try to accomplish what you promise , Try to make up for mistakes . Once someone else has been labeled as unreliable , It's hard to tear it off again .
The second is that we need to stick to learning , Because technological innovation is very fast , Only by persisting in learning can we not be abandoned by this industry , And keep training , After all, practice makes it work for all walks of life .
Last , In addition to expertise , We also need and have the obligation to understand the business areas corresponding to the modules developed by ourselves , It is not necessarily necessary to be an expert in this field , But it takes time to understand the values and principles behind the business , Know what it is, know what it is .
Can is can , You can't just can't , Don't say “ Give it a try “
This chapter mainly describes a professional engineer , To say “ No ”, Also know how to say “ No ”.
A professional should know how to say “ No ”, Because it's only exposing the problem , To have a chance to solve the problem . The author of this chapter uses some examples to illustrate , When you think that the task assigned by the project manager is impossible , But when you choose not to fight , It led him to think you could finish it on time , In the end, it led to disaster .
So in our daily work , Know how to say “ No ”, To know how to refuse , Instead of just accepting .
and “ Why not? “ Is it important? ？ The point of view in the article is “ Why? “ It's not as good as ” The facts “ important , For this point , I think it would be great for policymakers to know why .
It is also emphasized that “ Give it a try “ The harm of , Because decision makers tend to put “ Give it a try ” As a promise , Into his project plan , And what engineers often want to express is that I try my best , But there's no guarantee .
There is a problem at this time , Project managers often hope that engineers can accurately estimate the workload , But the amount of work engineers estimate is often 「 I'll try 」, The actual situation may be quite different . Here I have two main ideas ： One is as a project manager , Need to know the progress in real time every day , Adjust the plan , After all, the estimated workload is often not very accurate , There are too many factors that affect ; The second is to estimate the workload , You can take PERT Method , Increase confidence .
be supposed to
This chapter mainly tells what commitment is , How to give a promise .
Make a promise , There are three steps ：
- Say you will do it .
- Take commitment seriously in your heart .
- Really put it into action .
Sometimes we can't live up to our promises , It's often because we promise something we don't have full control of .
Of course, sometimes there are various reasons why we can't keep our promise , This is normal . But if you want your image as a reliable person in your colleagues , So the most important thing is to warn the people you promise as soon as possible , The sooner the better ！！
Of course , We shouldn't give up some bottom line just because we promise , Breaking discipline and principles often slows down progress , Also test the code , Keep the code clean .
The time of the day actually goes by very quickly , How to work as efficiently as possible in this short period of time 、 To achieve as many results as possible is worth studying .
Meetings are inevitable in daily work , But meetings can also waste a lot of time . As the executive of the meeting , The agenda and goals need to be set , Determine the time spent on each topic and a clear goal .
And as a participant in the meeting , First of all, you have to know how to refuse a meeting , Avoid unnecessary meetings , Because the only person responsible for your time is yourself .
We have the most meetings in our daily life , It's a station meeting , Everyone answers the following in turn 3 A question ：
- What did I do yesterday ？
- What am I going to do today ？
- What's wrong with me ？
No one can speak more than 1 minute , The aim is to reduce the time of the entire station meeting , So the project leader is required to think about the content to be arranged before the meeting starts , Instead of just thinking about it on the spot , Everyone gives a crisp account of their work , Reduce endless conversation .
This book also introduces a time management approach ： Tomato working method . It's also a way of scheduling that I'm using right now , If you are interested, you can find out by yourself .
Managers and developers may have different views on estimates , Managers may feel that estimates are promises , And developers tend to estimate just guesswork . But there is no denying that , A relatively accurate time estimate allows managers to make appropriate plans .
Here is an estimation method ：PERT, According to 3 Estimate the number of tasks ：
- O： Optimistic forecasts , This is a very optimistic number , It means that everything is going well ;
- N： Nominal estimate , This is the most probable number ;
- P： Pessimistic forecasts , Considering the pessimistic numbers in all kinds of unexpected situations .
So the expected completion time of the task ：u = (O + 4N + P) / 6
Standard deviation （ The greater the number , The more uncertain the expected completion time is ）：v = (P - O) / 6
For example, a task , Optimistic forecasts require 3 God , Nominal estimates require 6.25 God , Pessimism requires 11 God , Then through the two formulas of appeal, we can get , The expected completion time is 6.5 God , The standard deviation is 1.3.
Of course, there are a lot of things in this book that are not mentioned here , Like how to deal with stress , How to cooperate , The rhythm of coding and testing . Although with the development of the times and the author of this book in the foreign workplace and domestic workplace differences , There are some things I don't agree with , Or find it hard to practice . But that doesn't stop this book from being worth reading by every engineer , I believe it will help you to become a more professional engineer .