Great Habits of Programmer

Most of you heard about _Refactoring: Improving the Design of Existing Code_, which is written by Kent Beck. And some of you may know that Kent Beck said:

> I'm not a great programmer; I'm just a good programmer with great habits.

But what are those great habits?

Kent Beck had provide some in his book. Also, you can find others through searching engine. Actually, maybe searching engine is the reason that you are reading this article. But for me, the following habits are what I have learned from my classmates and colleagues. It is useful for me. So, I share them to you and hope that these habits make you a better programmer.
## Create indexes instead of reciting while reading books and so on

It is exciting or tiring for programmers that they have to learn thousands of new technologies in order to catch up with the development of industry (especially for front-end engineers). Programmers are cleaver enough to learn new technologies, but most of them do not have enough time, for their lives have been occupied by countless meetings and requirements. And then, this trick is to help programmers save time and learn new technology quickly.

Let's see...

Create indexes => Just remember how to find the answer for a specific question

Recite => Try to store the answer in your head

So, this trick means that remember how to find the answer for a question instead of storing the answer in your head.

Take [jQuery](https://jquery.com/) for example. It is possible to remember all the [APIs](http://api.jquery.com/) of jQuery, but difficult. Actually, it is unnecessary for most of programmers to remember all the APIs of a library. What we should do is that scan those APIs and know **what** they can do. In another word, we do not need to know **how** to do with those APIs. Because we know that we can open http://api.jquery.com/ and search, anytime.

Also, it is unnecessary to remember all the tricks in _Refactoring_. We read this book, and knew some tricks which make our code better. When need to know how to do that, we can just consult this book.
## Reorganize what you had learned

Knowledge is not breadcrumbs that are unordered and uncorrelated. So, we need to reorganize what we had learned from books and bugs and so on.

But how to do?

It depends on you 囧. As for me, writing blogs is the answer. When writing blogs, I must review what I had learned. If something makes me puzzled, I will search on the Internet or ask others. Actually, I learn more while writing a blog.

Also, sharing what you had learned to others is another answer. Your audiences will throw questions at you. And you have to reorganize what you had learn in order to make everything clear.
## Read unit test and source code

A well-designed document is the best gift for a programmer, for this document will help programmers start quickly, and provide answers for most of questions. But the real world is not utopia, some libraries' documents are in a mess. What is worse, some libraries do not have any document.

So, don't be afraid of codes that are written by others, even if there is no comment. Anyway, it is the only way to understand a library without document. And read unit test is still a good choice, for it shows what the author expects this library to do or not to do.

But...

What if...

There is no unit test!

Read source code of the library, and try to guess what it is designed to do from the implementation. Or, just find a well-documented library, if you can.
## Think twice before coding

You can code at home, at table, at ... But you can not code at will. Coding is rigorous for your code will have a great effect on customers and your annual bonus.

As for me, think twice means that ask myself some questions. For example:
1. What do I expect this program to do?
2. How does current version work?
3. Why do I choose this solution? Is there a better solution?

Ask yourself all the questions that you care about.

Look at $$$, think twice before coding, or thrice for important things should be repeated thrice :).

The issue contains a draft article but does not identify a repository file, content entry point, or requested change. Review the repository's content structure and the issue discussion first; the scope and acceptance criteria need to be established before completion can be judged.

Written by the indexing model from the issue text.