Five tips for writing code for good programmers

To be a good programmer is to be as good a professional as possible and to do as much as you can with quality work. And a popular word can be used to sum up: do, the right things to do immediately. (Do it.) Do it right. Do it right now

1. Make a list of what you want to do in a day

The best way to accomplish complex activities is to split them into simple activities. And in the morning, you split the activity that you want to complete in a day, and then you have to make a schedule that will help you:

To better understand this activity.

You will have a focused goal every day.

Improve your ability to estimate, and in a few days you will find that you can predict the amount of work for a day.

2. One thing at a time

Focusing on one task is more productive than doing multiple tasks at the same time, and different studies have proven this point and are posted on different media (such as CNN).

Concentrate on your work for 25 minutes and rest for 5-10 minutes. You can use a popular technique such as "tomato work" to help you manage your time. There are tools to help you measure the time you spend on different tasks, my favorite is Cooltimer, and here are 10 good time tracking applications.

3. Doing the right thing

The following two are the key to examining whether things are done correctly:

It's a good way to be proud of the solution because it's not just a common solution. Follow the "Software quality Pyramid" principle

The workaround must be checked at least once. Among your colleagues, ask a distinguished developer who you respect to examine your approach and accept his sincere suggestions.

4. Don't give up halfway

It is well known that if there is still a glass to be cleaned, it cannot be said that it has been washed. Paint the walls or drive to a place we agree with the same thing, but we don't think so in software development. Even if we do not complete all unit tests, or if we do not verify that the implementation is in line with the needs of the user, we also say that we have completed the task. This is typical behavior from Hopenhagen driven development and is very harmful.

When there is no change in demand, it is only when you are absolutely sure that there is no need to improve the solution to the task.

5. Instead of apologizing, it is better to remedy than to abandon the least desirable.

If you're going to spend extra time doing some code testing, or refactoring unreadable classes, do it because it's time to invest in the future. But if you're stuck on something or delaying the project too long, look for an easier solution. It may not be as elegant as the program you are currently implementing, but at least you have a plan. Be sure to document the future risks of the project, and something needs to be re-examined.