Five years of professional programming experience

There is no specific order here: 1. if you can evaluate or process performance problems at the application layer, you can extract them from the database layer. "sorting by xx" and "combining by xx" are typical examples. the application layer is always easier to measure than the database layer. this is the same for MySQL on the server and SQLite on the handheld device. there are some good comments on hackernews, so here I clarify: we only do this for some specific queries, not to speed up the response of a customer, but to reduce the replay, if this query seriously damages the database and is a major bottleneck for all users.
2. avoid concurrency as much as possible. if not, remember that the more powerful the ability, the greater the responsibility. avoid using threads directly. use a higher level of abstraction if possible. for example, in iOS, gcd, dispatch, and Operation queue are good helpers. the human brain cannot be used to think about endless temporary states. It is disgusting to think of the experience I learned.
3. Use as few States as possible and keep them in a local place. The utilities are mapped to something.
4. Short and composite methods are your friends.
5. annotations are dangerous because they are time-and misleading, but they are equally dangerous without annotations. do not comment on trivial items. However, if you need to write a specific part, you need to write a few paragraphs strategically. your memories will disappoint you as soon as tomorrow morning, even though you have already had coffee.
6. If you feel like a regular meeting "may be okay", it is the kind of failure that will cause a catastrophic one month in the product. I believe you have the courage to doubt it too much, test it and verify it.
7. communicate all concerns with your team when you have any questions.
8. Do the right thing. You usually know what it is.
9. Your users are not stupid. They just have no patience with your "simple method.
10. if an engineer has not been assigned the maintenance work of the long-term system they have created, they should be skeptical. 80% of the blood, sweat, and tears in the software are after the software is released, that is, when you become a tired but smarter "professional.
11. The list is your friend.
12. Take the initiative to enjoy your work with a clear destination. Sometimes this requires some effort.
13. for silent failures, I still have nightmares. monitor, log, warning. however, be cautious about false successes and the inevitable desensitization. keep your system identifiable and alert.
14. At the end of the day, we should pay for complicated problems, so we should work as important as possible.
Original article: 14 lessons after five years of professional programming