The Way to Neat Code

Synopsis:

This book is a summary of the experience of programming guru "Uncle Bob" over 40 years of programming career, explaining what kind of attitude, what kind of principles and what kind of actions are needed to become a real professional programmer. The author takes the detours and mistakes he and his colleagues have made as examples, with the intention of guiding those who come after him and helping them to take a higher step in their careers.

This book is suitable for all programmers and can be used as a reference for all those who want to become professionally literate in the workplace.

Chapter IX. Time management

Eight hours is actually a very short time - only 480 minutes and 28,800 seconds. As a professional developer, you definitely want to work as efficiently as possible and achieve as much as possible in this short time. What are the best ways to ensure that you don't waste this precious time? How can you manage your time effectively?

9.1 Meetings

There are two truths about meetings:

(1) Meetings are required;

(2) The meeting wasted a lot of time.

Professional developers are equally aware of the high cost of meetings, they are equally aware that their time is valuable, and they need time to write code and take care of things on their schedule. So, if the meeting doesn't have a realistic and significant outcome, they'll turn it down.

Denial:

The person who invites you to a meeting is not responsible for managing your time, only you are responsible for your time. So, if you receive an invitation to a meeting, make sure that attending the meeting will bring tangible and significant results to your current work, otherwise you don't have to participate.

Some meetings are about certain things you have already accomplished that are not relevant to the work at hand. This is when the loss of your project should be weighed against the gain of others. That's a bit of an understatement.But you deserve to have your project at the forefront of your mind.。

There are also times when someone in a position of authority (e.g., a senior engineer or supervisor on another project) orders you to attend certain meetings. This is a good time to ask yourself if their authority is more important than your own work plan. Similarly, colleagues and leaders on your own team can help with decision-making.

Leave the table:

Over the years, I've learned one simple rule:If the meeting is tiresome, leave the meeting.

It is important that you understand that remaining in the conference room is a waste of time; it is unprofessional behavior to continue attending meetings that do not mean much to you. Because you have a responsibility to allocate the time and money your boss gives you wisely, it is not unprofessional to pick a suitable opportunity to discuss how to leave the meeting.

If there is a real need for a meeting.Setting the agenda and objectives：

If you receive an invitation to a meeting, make sure you find out what the assigned topics are, how long each topic will take, and what you want to accomplish. If you don't get a definitive answer, you can politely decline.
Iterative Planning Meeting:The Iteration Planning Meeting is used to select the development tasks to be realized in the next iteration. Two tasks must be completed prior to the meeting:Evaluate the development time for optional tasks and determine the business value of those tasks.If organized well enough, acceptance/component testing should also be done prior to the meeting, or at least with an approximate program.
Iteration Review and Demo Showcase: This type of meeting takes place at the end of the iteration. Team members discuss what went right and what didn't go right in this iteration. This type of meeting can waste a lot of time if not organized properly, so it might be a good idea to hold it 45 minutes before the end of the last day. Spend 20 minutes on the recap and 25 minutes on the demo. Keep in mind that this type of meeting only involves the last week or two of work, so there's not much to discuss.
Argument \ Against:*Any argument that can't be resolved in five minutes can't be resolved by debate.The reason the argument takes so much time is because none of the parties can produce strong enough evidence. So these types of arguments are based not on facts, but on beliefs.
If points of view can't be agreed upon in a short period of time (5 to 30 minutes), they never will be. The only way out is to speak with data.
In an argument if you agree with the other person's conclusions, you must show action.
Be careful of these types of meetings: they are designed to vent emotions or get people to take sides. If there is only one side of the story at a meeting, avoid it.
If an argument has to be resolved, the parties to the argument should be asked to present the issue to the group within a five-minute period, and then the group should vote. In this way, the entire meeting would take no more than 15 minutes.

9.2 Attention Points:

Programming is an intellectual activity that requires continuous investment of energy and attention. Attention is a scarce resource; it is similar to magic points [2]. If you use up your attention points, you must replenish it by spending an hour or more doing things that do not require attention.
Professional developers learn to organize their time and use their attention points appropriately. We choose to program when we have plenty of attention points and do other things when they are scarce.
Attention points also decrease over time. If it is not used in time, it will disappear. One of the reasons why meetings are so destructive is because of this. If all your Attention Points are used in meetings, your brain is empty when programming.
Worry and distractions also drain attention points. Last night's spousal fight, this morning's car cut-off, last week's bill that you forgot to pay, can all quickly drain your attention points.

Sleep: Professional developers will organize their sleep to ensure that they have full concentration points to go to work early in the morning.

Caffeine: There's no doubt that for some people, the right amount of caffeine can help them use their attention points more effectively. But be careful, caffeine can also mess with your concentration.

Recovery:Once you run out of Attention Points, you can't control your attention. You can still write code, but most likely you'll need to rewrite it the next day, or suffer through it weeks or months later. So it's better to take 30 to 60 minutes to change your brain.

Muscle Attention:Muscular attention helps to improve mindful attention and goes beyond simple recovery. I have found that regular training in muscular attention raises the upper limit of mental attention.

9.3 Inputs and outputs

Another key point I know about attention is balancing input and output. Programming is a creative labor. I have found thatMy creativity thrives best when I have access to other people's creative minds, so I read a lot of science fiction. The creativity of these authors sparks my creativity with software.

Time Split and Tomato Work:

Set your kitchen timer (usually it's shaped like a tomato) to 25 minutes. Don't let anything interrupt you during the countdown. If the phone rings, pick it up and politely tell the person to please call back in 25 minutes; if someone comes to interrupt you to ask a question, politely ask if they can come back in 25 minutes. Whatever the interruption, you must wait until the end of the 25 minutes to deal with it.

After all, almost nothing is so urgent that it can't wait 25 minutes. When the timer goes off, stop what you're doing and move on to something else you've encountered in those 25 minutes. Take a break for about 5 minutes afterward. Then, set the timer for 25 minutes again and start a new tomato time period. For every 4 tomato time periods completed, take a break of about 30 minutes.

9.4 Behavior to be avoided

Sometimes you get distracted at work. It's likely because the things you have to do are panic-inducing, difficult, or boring. You may think that the job is something you are forced to deal with and there is nothing you can do to get out of it. Or, you just don't like the job.

Misplaced priorities:Whatever the reason, we can find ways to avoid real work. The act of convincing yourself that some work is more urgent, so you turn to it, is called misprioritization - raising the priority of a task, after which you have an excuse to put off the really urgent task.

Misplaced priorities are self-anesthetizing lies, and because we can't face what really needs to be done, we tell ourselves that other things are more important. We know it's not true, but we use it to fool ourselves anyway.

Dead end:

All software developers have to hit dead ends. Let's say you make the decision to go down a technical path that doesn't work. The more you hold on to that decision, the more time you waste. If you think it's about your professional credibility, you'll never get out of it.
You can quickly realize when you've hit a dead end and have enough courage to walk back. This is called The Rule of Holes: if you fall into a hole, don't dig.
Professional developers don't cling to ideas that they can't give up or get around. They keep their minds open to other ideas, so even at the end of the road, they still have other options.

Quagmire:

Worse than a dead end is a mud puddle. A mud puddle will slow you down, but it won't stop you completely. A mud puddle will prevent you from moving forward, but you can still make progress if you put your best foot forward.
The reason why a mud puddle is more troublesome than a dead end is that in a mud puddle you can still see the way forward, and it always seems shorter than going backwards (although it's not).
The hazards of moving on through the mire are not easily noticeable. Faced with a simple problem, you give a solution, keeping the code simple and tidy. Then the problem expands and becomes more complex, and you expand the code base to keep it as neat as possible.
Going backwards may seem costly in terms of reversing existing code and starting over, but going backwards is definitely the easiest way to go. If you keep going, the system can get stuck in a quagmire and never get out.

Conclusion:

professional developerWill manage their time and attention mindfully. They know the temptation to misprioritize, and they value their reputation enough to resist misprioritization.
They'll always have a variety of options thatAlways be open to hearing other solutions, they never cling to a solution that they can't give up.
They are also constantly on the lookout for quagmires that are revealing themselves, and avoid them once they get a good look at them. There is nothing worse than seeing a group of developers working in a futile scramble only to end up in a deeper and deeper quagmire.