40 Little Tips Only Veteran Programmers Know

Source: Zhihu, author: 大狐狸

Link: https://www.zhihu.com/question/36426051/answer/76031743

1. Refactoring is a programmer’s main skill.

1. A work log expands your brain capacity.

1. Profile first — only then do you have the face to talk about optimization.

1. Comments are valued for quality, not quantity. Do away with period-like “routine comments”. Comments carped on all over the place are really just background noise.

1. An ordinary programmer + google = a super programmer.

1. Unit tests are always a good deal.

1. Don’t write the framework before the implementation. Better the other way around: distill the framework out of the prototype.

1. If the code structure is clear, nothing else is a problem.

1. Good projects have a tough style: one-key test, one-key release, one-key deploy; lousy projects are sneaky by nature — passed on by word of mouth, nothing written down, all mysterious.

1. Don’t be afraid of change when coding; embrace change.

1. Keep recharging. There’s only one way for a programmer to die: dying of being out of date.

1. In programming, isolation is the direction, naming is the key, testing is the protagonist, debugging is the supplement, and version control is the regret pill.

1. One line of code, one soldier. Only an organized force has fighting power. Unit size shouldn’t be too large: squads of a thousand and platoons of ten thousand easily turn into a mass grave of ten thousand.

1. Refactoring / optimizing / fixing bugs: only one of these at a time.

1. Encapsulate simple modules; layer complex modules.

1. The human brain has limited capacity, so tidy beats messy. If you can’t read the code, try reformatting it; if the interface is awkward to use, try wrapping it again.

1. Iteration speed determines work intensity. If you want it faster, better and cheaper, start by simplifying the development process and speeding up iterations.

1. Forget optimization while writing code — premature optimization is equivalent to malicious sabotage; forget the code while optimizing — optimization has to be based on performance testing, not on agonizing over every line.

1. The best tool is pen and paper; the next best is markdown.

1. If your leader asks how long a task will take and you can’t answer, the task probably wasn’t broken down finely enough.

1. Better to overestimate by a week than to underestimate by a day. Being too “optimistic” easily scares the boss.

1. The most useful language is English. The next is probably Python.

1. Seeing once beats hearing a hundred times. Draw the results and everything is clear at a glance — debugging time drops dramatically.

1. Resources and code should both be under version control. A resource mismatch is far harder to track down than a code mismatch.

1. Don’t develop based on imagination, develop based on prototypes. The value of a prototype is validating an idea quickly and saving everyone time.

1. Plain text is the first choice for serialization. Binary, obfuscation, encryption, compression and the like can be added when the need arises.

1. The compiler will always understand micro-optimization better than you do. You can only push in the directions it isn’t good at.

1. Don’t make plans that are too big, too far out, or too detailed. Even if you make them, they’re useless.

1. At least half your time will go into integration. Time, time — there is never enough time.

1. When you go against mainstream opinion / method / style / habit, checking yourself first is the most reliable move.

1. Chase down bugs proactively, whether or not they’re yours. This makes your technical ability shoot up and your personal image soar; if your bug is dug out by someone else… hehe, then you’ll be in a very passive position ~≧﹏≦

1. When you don’t know which technical book to pick, choose a thin one. At least it won’t be too expensive, and you’ll be able to finish it.

1. git is the best. Simple, reliable, free.

1. Only throw assertions at “predictable irrationality”.

1. Logs should record time and category. And they must be able to redirect their output.

1. Comments are mediocre documentation. Better is clear naming. Let the code tell its own story.

1. Reinventing the wheel is a great way to train — provided you’ve seen other wheels.

1. code review is best done in groups or pairs. With some understanding of the business, the suggestions carry more value (though that’s not absolute). And it won’t become a burden. A single admin doing reviews personally easily becomes the team’s bottleneck.

1. Do your research before asking. Asking off the point gets you looked down on and wastes your own time.

1. Never look down on a program-girl (╯3╰)