When you are asked to write a paper in school, you typically spend hours writing the "first draft." You then read that draft and revise it until it conveys exactly what you want to say, in the way that you want to say it. This is the "final draft," which is worthy of being turned in for a grade.
Writing a computer program is very similar. Often it doesn't take long to hack out the "first draft." "It works," you say to yourself. What happens next is one of the key differences between a good programmer and a great programmer. A good programmer does some testing, fixes any bugs, and then creates the pull request. A great programmer does some testing, fixes any bugs, and then starts refactoring. The great programmer knows that the "first draft" is just the beginning.
Here are the questions that the great programmer asks about the "first draft:"
- Is it readable?
- Is it understandable?
- Is it maintainable?
- Is it testable? (And better yet, is it tested?)
- Is it flexible?
- Is it scalable?
- Is it reusable?
- Is it efficient?
- Is it resilient?
- Is it secure?
- Is it documented?
"It works" isn't enough for a great programmer. "It works every time" is the true goal. Putting in the additional effort to stop and think about the above questions and do what is necessary to ensure they can answer "yes" to each is what helps the great programmer achieve that goal.
This certainly is idealistic and given that every project has constraints, it is not always practical to spend an inordinate amount of time refactoring to perfection. "Virtue is in the mean," as Aristotle said. Those who aspire to write solid programs will find the appropriate balance needed to ask themselves the questions and arrive at an appropriate level of "yes" to each of them, while staying within the constraints of their projects.