Refactoring is a programmer’s workhorse. 2. Journaling can increase brain volume. 3. Use profiler surveys first to talk about optimization. Notes your essence is not expensive. Avoid the menstrual routine. The cacophony of notes is actually background noise. Average programmer + Google = Super programmer. Unit testing always pays. 7. Don’t write the framework before you write the implementation. It’s better to go the other way and refine the framework from the prototype. Code structure is clear, other problems are not a problem. 9, good project style hard, one-button test, one-button release, one-button deployment; Bad projects are obscene, word of mouth, not text, mysterious. Coding don’t be afraid of change, to embrace change. 11, often charge. There is only one way for programmers to die: earthy. Programming, isolation is the direction, naming is the key, testing is the protagonist, debugging is a supplement, version control is regret medicine. 13, a line of code a pawn. Only by forming an organization can we have a fighting force. Unit size should not be too large, one thousand classes, ten thousand people row into a mass grave. Refactor/optimize/fix bugs, one at a time. Simple modules pay attention to encapsulation, complex modules pay attention to stratification. Human brain performance is limited, clean is better than clutter. Unreadable code, try to organize the format; Bad interface, try to repackage. Iteration speed determines work intensity. If you want to save as much money as possible, start by simplifying the development process and speeding up iteration. Forget about optimizing your code. Premature optimization equals malicious sabotage; Forget about code optimization. Optimizations should be based on performance tests, not on lines. The best tool is pen and paper; The next best is Markdown. 20. The Leader asks the task time. If he can’t answer, the task split may not be detailed enough. Would rather calculate a week, not less than a day. Being too “optimistic” will scare the boss. The most useful language is English. The second is probably Python. Seeing is believing. Let me draw the result. It’s easy to see. Debugging time is greatly reduced. Resources and code should be versioned together. Resource matching errors are far more difficult to detect than code matching errors. Don’t develop based on imagination, develop based on prototype. The value of a prototype is to quickly validate ideas and save everyone time. Serialize preferred plaintext. Such as binary, obfuscation, encryption, compression, etc., to be added as needed. The compiler is always better than you know micro optimization. Can only work in the direction it is not good at. Don’t set too big, too far, too detailed plan. It doesn’t matter if we do. 29. At least half your time will be spent on integration. Time, time, time is never enough. Contrary to the mainstream opinion/method/style/habit, first review their most reliable. Take the initiative to check the bug, whether it’s yours or not. This will make your business and personal image soar. I don’t know how to choose a thin technical book. At least it won’t be too expensive, and you’ll get through it. Git is the best. Simple, reliable, free. Only on “predictable irrationality” throw assertions. Log to write time and classification. And be able to redirect output. Comments are slightly worse documents. Even better is clear naming. Let the code tell its own story. Making wheels is a good exercise. That is, if you’ve ever seen another wheel. 38. Code review is best done in groups/pairs. Some knowledge of the business makes advice more valuable (but not always). And it’s not a burden. Personal review by administrators can easily become a bottleneck for a team. Do your research before asking questions. Not being able to ask is despised and a waste of your time. Never underestimate the program yuan

— the END —

# essays