Many authors think that writing a program is enough, but the truth is that only well documented programs achieve any real usage.
When you are debugging a program, it is amazing how many small errors you find that have absolutely nothing to do with the awful symptoms you are observing. So don't stop testing when you are convinced that you have found 'the' problem.
Always write a program in the simplest, most straight-forward manner possible. That will make the program easier to debug and document. It may save the user a lot of time and will facilitate borrowing the code for another project. A few years ago, a summer student working on IBM's PL/I compile developed a very clever algorithm for allocating storage for PL/I structures that occasionally saved 1 to 3 bytes per structure. Unfortunately, nearly every PL/I programmer tripped over the algorithm at one time or other when debugging code. The cleverness saved storage but wasted an enormous amount of development time.
Too often, programmers take the attitude that they can finish a project is less time than it takes to build a specialized tool and never learn or do anything new.
Don't steal other people intellectual property, but don't reinvent the wheel. Many, many problems have been solved and the solutions are available; know what is out there and use it. It is always easier and quicker to adapt an existing program rather than writing a new one.
A few years age, Capers Jones at IBM showed that on the average the amount of computer resources used in developing the 'average' program exceeded the computer resources used in running the program by a factor of 28. The important thing is to get the answer and on to the next program.