5 Tips for creating good code every day; or how to become a good software developer

Being a good developer is like being any other good professional, it’s all it’s about doing as much quality work as possible. There is a popular sentence that summarises it: “Do it. Do it right. Do it right now”.

1.- Have your own to do list for the day.

The best approach to complete complex activities is to break them down into simple activities. Do this every morning by breaking down the different activities you would like to complete for the day and assign them a schedule. This will help you to:

• Have a better understanding of the activity.
• Have a focused goal for the day
• Improve your estimating skills. After a few days you will find that you can predict how much work you can do in a day.

2.- Do one thing at a time.

It’s been proven by different studies and published in different media (ie CNN) that it  is more productive to be focus only on one task than to do multitasking.

Work in short batches of intense work of about 25 minutes with a 5-10 minutes rest. There are popular techniques like the pomodoro technique to help you manage the time. There are also tools to help you measure the time you spent on the different tasks, my favorite one is CoolTimer.

3.- Do it right.

There are two keys to know if something is done right

1. To be proud of the solution; it is not just any solution, it is a good solution. It follows the principles of the “Pyramid of the software quality“.
2. The solution passes at least one review. Ask one of your colleagues that you respect as a good developer to review your solution and for his sincere opinion.

4.- Don’t finish something until it’s completely done.

We all know that if there’s still a glass to wash, we cannot say that we have done the dishes, the same applies for painting a wall or driving to a destination but in software development we don’t do that, we say that we are done even when we haven’t completed all the unit tests or when we haven’t checked if the implementation is correct with the customer, that’s a typical behavior from Hope Driven Development and that’s evil.

Something is only done when you are 100% sure that it won’t be necessary to work at all on that solution unless the requirements change.

5.- Better late than sorry BUT better sorry than never.

If it’s going to take you an extra day to complete the testing of some code, or to refactor a class which is unreadable, do it, that’s an investment in time for the future, but if you are stuck with something and you are delaying the project too much, just find an easier solution. It may not be as elegant as the one you are implementing, but at least you will have a solution. Make sure to document it as future risk for the project and something that will probably need to be revisited.

翻译版：http://www.cnblogs.com/wangkongming/p/3518582.html