36 programmers' guide to avoiding pits

👋👋 Link to the original text: A few words for the programmer

Hey guys, everyone! I am cxuan, an appropriate fishing time, and I wrote 36 suggestions to share with you. Many of these suggestions are my own practice, and some of them are the experience I gained from chatting with my colleagues. I hope everyone can close the pit in time.

1. If the code is not tested, then it will not work.
2. The source code is your friend, make sure you will use it.
3. Although you have written some code, it does not mean that you own the code. If a member of the team has to modify your code, please don't be angry.
4. Don't reinvent the wheel, the existing wheel or code base can help, search more.
5. If you have some ideas, but you haven't implemented them, it doesn't mean that these ideas are nonsense.
6. The source code just prompts the compiler what to do, but the compiler does not necessarily do it (compiler optimization).
7. Actively conduct code reviews, and don't carry out code reviews with arrogance.
8. Code that is difficult to understand is difficult to maintain, so write comments in time.
9. Code that is difficult to maintain is almost useless.
10. Learn to read the meaning between the lines from the business requirements and convert it into technical requirements.
11. The neater the code layout, the easier it will be to read your code. The easier it is to read, the easier it is to understand and maintain.
12. The code will not write comments by yourself. Your comments can help others understand, and more importantly, can help you understand. You may understand now, but what about 5 years from now?
13. Bad code will often come back to haunt you.
14. There are very few tasks that can be completed in 5 minutes, at least half a day.
15. The magic value is very bad.
16. Always document the code, not only to help others, but also to help yourself.
17. Project managers always want you to complete two days' work in one day.
18. If your product has a bug, your users will always find it.
19. What matters is not the quantity of code, but the quality of the code, because everyone will write if else, but not everyone will use the strategy pattern.
20. Remember: code reviews are not criticizing your code, so don't worry about it.
21. The biggest cost of bad code lies in operation and maintenance.
22. Fixing bugs in your code can improve your coding skills and improve your understanding.
23. You must always improve your skills, otherwise you may be out of the entire industry.
24. If the user does not request a certain function, please do not add it randomly.
25. If the code is not tested, it will not work (yes, I know I have included it twice, but it is really important).
26. If you write code that makes you feel very fulfilling, please don't be complacent, because there will always be someone somewhere that writes better code than you.
27. When testing code, you should test your code against frequent and boundary conditions.
28. Never trust user input, the user should always content killing .
29. We must always include buffer overflows in our daily considerations.
30. You have to spend more time thinking about how to write code, rather than spending more time writing code.
31. Change in requirements is the most hated thing.
32. Remember, your success depends more on your soft skills and how you articulate the problem and its solutions, rather than your technical ability.
33. When you see that some of your ideas are incorporated into the product, and many are discarded, don't take it to heart, because this is how things work.
34. Use version control, which will save you at critical moments.
35. Love your job, not your company. You never know when your company will stop loving you.
36. There will always be younger and more talented people joining the company. The constant salary inversion over the years illustrates this point well.

💪Finally, I would like to recommend my own Github , which contains a lot of hardcore articles, which will definitely help you.