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 2: Saying "No"
Professionals dare to state the truth without succumbing to power.
Professionals have the courage to say no to their managers.
2.1 Opposing Roles
Whether you are a project manager or a programmer, you have a job to do. Your manager is doing his job by asking you to complete the login page by tomorrow, which is a goal he is trying to achieve and defend. But if you know that it's impossible to complete the login page by the next day, and you say, "Okay, I'll try," then you're not doing your job.
At this point, the only option for due diligence is to say, "No, it's not possible."
Take a look at a couple of conversations:
Conversation one:
Manager P: "You have until tomorrow to complete that login page,"
Little M (programmer): "Oh, wow! It's going to be that fast, huh? Well then, I'll try my best."
Manager P: "Great! Thanks."
What appears to be a harmonious conversation is actually less than professional on both sides.The P-manager assumes that you will finish tomorrow, while you might actually try to complete a task that the preconceived notion of a day's time simply won't allow you to do.
Talking like this avoids the outbreak of conflict, but it doesn't help solve the problem in the slightest.
Dialogue II:
Manager P: "You have until tomorrow to complete that login page,"
Little M (programmer): "Oh, sorry manager, it can't be done in such a short time."
Manager P: "And when do you think it will be done?" .
Little M (programmer): "How about two more weeks?"
Manager P: (making a few notes in his book) "Okay, thanks."
It's really easy to have a conversation like this, but there are serious problems with it, and people are acting extremely unprofessional.
Neither side is trying to find the best possible outcome.。
Conversation Three:
Manager P: "M, you have until tomorrow to complete that login page.
"Little M: "No, Manager P, this job will take two weeks to complete."
Manager P: "Two weeks? The architect estimated this would only take 3 days, and you've already spent 5 days!"
M: "The architects are wrong about the P managers. They did the estimate before they received the product sales request. I need at least 10 more days to do it. Didn't you see my updated estimate on the wiki?"
Manager P: (with a serious expression and shaking with frustration) "M, this is not going to work. The client is coming to see the demo tomorrow, and I have to show them a login page that works."
Little M: "What part of the login page do you need to be able to use tomorrow?"
Manager P: "I want the whole login page! It has to be able to log in."
Little M: "Manager P, I can make you a fake page that you can log into. This one is ready now. But the page won't check for username and password. And if you forget your password, there's no way to email you about it yet. It doesn't yet have a news bar scrolling across the top of the page like the big screen in Times Square, the help button and floating instructions don't yet work, it doesn't save a cookie for you to log in next time, and it doesn't set any permission limits. But you do get to log in. Does that look okay to you?"
Manager P: "I can log in?" M: "Yes, you can log in."
Manager P: "Bravo, Little M, you're a lifesaver." (Relieved, says, "Fantastic!" , walks away.)
In this example, they reached the best possible outcome. They disagreed and said "no" to each other, and then found a mutually acceptable solution.
Their performance was professional. There was a slight conflict in the dialog and a moment of unpleasantness, but this is the ideal situation when the goals that both parties insist on pursuing are not perfectly compatible.
The "why" is not as important as the facts.
Why does it take so long for the login page to complete Facing Facts Matters.
2.2 High-risk moments
The most important time to say "no" is at those critical moments of high risk. The more critical the moment, the more valuable the word "no" becomes.
The authors tell a story here about facing a project task with a certain deadline, making it clear at the beginning whether it can be accomplished at the moment, and saying "no" firmly if it can't be accomplished.
Even if it's a life-or-death project, it's more important to respect the facts and say no.
2.3 Be a team player
2.3.1 Try it out
By promising to "try", you are admitting that you didn't give it your best shot before and that you still have room for more.
Promising to "try" means that you can still achieve your goal if you work harder; moreover, it is a promise that you will work harder to achieve your goal. Therefore, by promising to "try", you are actually promising that you will ensure success. In this way, the pressure is on you. If your "attempts" don't achieve the desired results, you've failed.
If you have no new plans and are not prepared to change your behavior, and if everything is still done the way it was before you promised to "try" it, then what does it mean to "try" it? If you didn't have reservations, if you don't have a new plan, if you're not going to change your behavior, if you're confident in your original estimate, then, in essence, promising to "try" is a sign of dishonesty. You are lying. Your reason for doing so may be to save face and avoid conflict.
2.3.2 Negative confrontation
If a freight train is coming at everyone and you're the only one who's aware of it, you can gently pull back off the tracks and watch everyone else get run over by the car, or you can yell, "Car! The car is coming! Get out of there!"
2.4 The cost of saying "yes"
- Any piece of functionality that a client wants, once written, is always far more complex than what it says it is when it starts.
- What do we understand good code should look like? Good code should be extensible, easy to maintain, it should be easy to modify, and it should read with the flavor of prose
- The lesson from this story is that your stakeholders, whether external customers or internal management, know how to get developers to write code fast. But is it writing code efficiently? Not really. Is it writing code fast? Yes. That's how they get it done.
2.5 How to Write Good Code
Professionals often become heroes, but such an honor is not something they deliberately seek. They become heroes because they do an excellent job, not only on time, but on budget.
This shouldn't be done at the expense of saying "no" and writing code like crazy to get the job done, but it leaves little time to improve the quality of the code, and the code is written just to get the job done! If so, it is impossible to write good code.
"Is it possible to write good code? Is it possible to uphold professionalism?"
My answer was, "Yes. But you need to learn how to say 'no'."