The Way to Neat Code - Reading Notes (3)

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 made by himself and his colleagues as examples, with the intention of guiding those who come after him and helping them to take their careers to a higher level.

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 3: Saying "Yes"

If you keep your promises, people will think you are "a responsible developer".

It's also the most valuable comment in our business.

3.1 Commitment language

Say it with your mouth; mean it in your heart; put it into action;

And that's whatpromiseThe three steps of the

(1) Verbalize that you will do it.

(2) Take seriously in your heart the promises made.

(3) Really put it into action.

3.1.1 Recognizing the signs of "lack of commitment"

We have a tendency to try to avoid taking responsibility.

Watch out for the following three types of words, and when they appear you should be alerted that you don't have to take this promise too seriously.

• Need/Should."We need to get this job done." "I need to lose weight." "Someone should be in charge of going forward with this."
• Hopefully/hopefully.I hope I can finish this tomorrow." "I hope we can meet again some other day." "Wish I had time to do this." "Wish the computer would hurry up."
• Let's (not let me). Let's turn around and see you later." "Let's get this over with."

3.1.2 What does real commitment sound like?

Look for similar sentences:I will ........ Before ............

You make a clear statement of fact about what you will be doing, and you also specify a deadline for completion.

That doesn't mean someone else, but you're talking about yourself. You're talking about an action that you would do yourself, and, instead of possibly doing it, or possibly doing it, you have to do it.

After reaching the time arrived, two outcomes were faced, either it was completed or it wasn't.

If you don't deliver, others can lay out your previous promises to embarrass you. You will feel bad for having broken a promise. It can be very embarrassing to tell someone that you didn't keep a promise (if that person ever heard you make a promise to their face).

Here the author also explains the underlying idea of failing to keep one's promises and gives a corresponding response.

1. The reason it didn't work is because I was banking on so-and-so to do it.

   Reason: You can only commit to what you can fully control. For example, if your goal is to complete a module that is also dependent on another team, you can't commit yourself to both completing that module and achieving seamless integration between that module and the modules the other team is responsible for.

   Response: If the end goal is dependent on others, then you should take some concrete action to get closer to the end goal.

2. The reason it didn't work was because I wasn't quite sure if I could really pull it off.

   Coping: Even if the goal is not accomplished, you can still move forward with all your might and get closer to your goal.

   Example:

   • Go through all 25 bugs and try to reproduce them.

   • Sit down with the QA who found the bug and watch the scene when the bug is reproduced.

   • Spend all the time at your disposal this week trying to fix bugs one by one.

3. The reason it didn't work is because there are times when there's really nothing I can do about it.

Response: If you can't keep a promise, then the most important thing is to give early warning to the person you're promising toThe sooner the better, the sooner the better.

Here's one thing to keep in mind:

​ If you don't tell others about possible problems early on, you miss the opportunity to get them to help you reach your goals and fulfill your commitments.

3.2 Learn how to say "yes"

stand on principle

He probably could have gotten it done faster if he hadn't written the tests. If he didn't do the refactoring and didn't run the full set of regression tests, he might be able to get the job done faster, too. At this point, if one is a professional developer, one does not give up the bottom line.

First of all, this assumption is inherently wrong. Even if you don't write tests, don't do refactoring, and omit full regression testing, Peter can't get things done any faster. Years of experience have taught us that breaking these disciplines and principles will inevitably slow down progress.

Second, as a professional developer, Peter has a responsibility to standardize his work according to the standards.The code must be tested and the code must have a corresponding test code. It is important to make sure that the code is clear and neat, and you must make sure that it does not affect other parts of the system.

If you have to work "overtime", you need to consider your managerial reserves. It's easy to verbalize that you'll take care of things over the weekend, but it's much more difficult to actually put in the effort to get the work done in a quality way.

Professionals know the limits of their capabilities. They know exactly how much longer they can remain productive overtime, and they understand very well the price to pay.

summarize

Professionals do not need to answer "yes" to all requests. However, they should strive to find creative ways to be as responsive as possible. When professionals answer in the affirmative, they use formal promises to ensure that all parties understand what is being promised.