I read Chapter 4 this week. It mainly talks about some knowledge related to coding, when is the most efficient, when is it not suitable for coding and a series of questions
1. The code must work correctly; the code must be able to help you solve the problems raised by the customer; the code must be able to integrate seamlessly with the existing system; other programmers must be able to read your code.
2. Working in a distracted state will only cause serious waste
3. Don't write code when you're tired. Dedication and professionalism are more of a discipline than a long-term workaholic.
4. Much has been written about the high-efficiency state, which is often referred to as the "fluid state". Some programmers call it the "fluid zone", no matter what the name is, you may be familiar with it or even have experience with it. This is a highly focused state of mind that programmers enter when writing code, but their mental horizons are narrowed. In this state, they will feel extremely efficient: in this state, they will feel "absolutely wrong". So they have been striving to get into this state, and often measure their self-worth by how long they can stay in that state. Some people who have been in this state but have gotten out of it have a little bit of advice: Avoid entering the fluid zone. This state of consciousness isn't really extremely efficient, and it's by no means error-free. This is actually just a state of "shallow meditation", in which the ability to think rationally will decline in pursuit of the so-called speed. Let me be more clear. In the fluid section, you might be able to type out more code. If you were doing TDD at the time, you would repeat the "red/green refactoring" cycle more quickly. You will reap a sense of pleasure or conquest. The problem is that in a fluid state, you're actually giving up on the big picture, so you're likely to make decisions that you'll have to overhaul later on. It might be faster to write code in the fluid zone, but you'll have to go back and revisit the code more later.
5. Creative output comes from creative input
6. For some reason, software developers think that debugging time is not coding time. An important aspect of measuring whether you are a professional is whether you can minimize debugging time. Absolutely zero debug time is an idealized goal, unattainable, but as an endeavor.
7. Software development is a marathon, not a sprint.
8. You'll run into delays someday. Even the best programmers, the most dedicated employees, are not immune to delays, and the trick to managing delays is early detection and transparency.
9. What if your manager insists that you try your best to meet a deadline? What if your manager insists you “get on time”? Stick to your estimates! Any adjusted estimates made are far more accurate. Tell your boss that you've considered all the situations (because you did) and the only way to speed things up is to reduce the scope. Don't resist the temptation to speak out. If the poor developer finally succumbed to the pressure and agreed to try their best to meet the deadline, it would end tragically. Those developers would start cutting corners, putting in extra overtime and holding on to the slim hope of a miracle. This is the best recipe for disaster, because it creates a false expectation for yourself, your team, and your stakeholders. This way everyone can avoid facing real problems and keep the time to make the difficult decisions necessary. In fact, fast sprinting is impossible. You can't write code faster. You can't solve problems faster. Trying to do this will only end up slowing yourself down and creating a mess that slows everyone else down. Therefore, it is imperative to clearly tell the boss, team and stakeholders not to have such expectations.
10. Overtime does work and is sometimes necessary. Sometimes, by working 10 hours a day and not adding a day or two in the last week, you can indeed achieve progress that would otherwise be impossible. But the stakes are high. With 20% extra overtime, you can't actually complete 20% of the extra work. And now, if you have to work overtime for two or three weeks in a row. The overtime measures will undoubtedly fail. Therefore, the program of working extra overtime should not be adopted unless all three of the following conditions are met: (1) You can personally squeeze in these hours: (2) Short-term overtime, up to two weeks overtime: (3) Your boss asks Have backup plans in case overtime measures fail. The last one is the key. You should not agree to an overtime plan if your boss can't clearly explain to you the backup plan for a failed overtime plan
11. Of all the unprofessional behavior a programmer can exhibit, the worst is to claim to have done a task, knowing that it has not been done.
12. It's all too easy to define "done" if nothing is required to be done.
13. If a team falls into this misunderstanding, managers will hear that everything is going well. All the status report sheets everyone's work is done on time. It's like a group of blind people sitting on a picnic next to the tracks: no one can see that a train full of unfinished work is about to overwhelm them, and by the time they find out, it's too late.
14. Programming is hard. In fact, you can't write good code by yourself. Even if you are extraordinarily skilled, you can definitely benefit from the thoughts and ideas of another programmer.
15. It is the duty of every programmer to help each other. As a professional, take pride in being able to help others at any time.
16. Just as you should be proud of being helpful, you should be proud of being willing to accept help from others.
17. Programmers are mostly conceited. Stubborn and introverted. We didn't do it because we liked dealing with people. Most people choose to make a career of programming because they like to be immersed in figuring out the minutiae and fiddling with concepts to prove they have the most developed brains on the planet, and they hate getting caught up in the intricacies of communicating with others in the chaos
18. For most of us, since collaboration is not in our own nature, we need discipline principles to drive good collaboration.