Jerry Weinberg's book, Weinberg on Writing: The Fieldstone Method (093263365X) describes a technique of gathering ideas like fieldstones until you have a collection with which you can build a book. Such a technique may not make you a William Faulkner or William Shakespeare, but it will enable anyone to become a journeyman author.

Fieldstones can come from anywhere. Here are some pointers to some I've come across:

• from Annie Lamott's Bird by Bird (via [http://ellen-kushner.livejournal.com/42408.html?thread=478376#t478376 Ellen Kushner's blog]):

  • "I thought such awful thoughts that I cannot even say them out loud because they would make Jesus want to drink gin straight out of the cat dish."

• Bruce Eckel's [http://mindview.net/FAQ/FAQ-006 definition of mentoring]:

  • Consulting guidance on a project - that is, a team is working on an actual project and the mentor comes on site periodically and helps "steer the boat," which includes reviews and walkthroughs of design, code, and/or process. You could think of it as "someone to watch over you."

• J. Steven York's [http://york-multiplex.blogspot.com/2006/03/writers-and-other-delusional-people.html writing blog] states:

  • "Stealing words is a crime. Stealing ideas is frequently a smart thing to do, but always steal from the best. Start with Shakespeare and work your way forward."

  • "And remember that you don't even have the right to call yourself a failure if you don't try, and you still don't have the right unless you've stopped trying. Until then, you're still a success waiting to happen."

• [http://www.altisinc.com/Links/100_Rules.html One Hundred Rules for NASA Project Managers] by Jerry Madden includes such gems as these:

  Rule #8: Running fast does not take the place of thinking for yourself. You must take time to smell the roses. For your work, you must take time to understand the consequences of your actions.

  Rule #43: Documentation does not take the place of knowledge. There is a great difference in what is supposed to be, what is thought to have happened, and reality. Documents are normally a static picture in time that get outdated rapidly.

  Rule #63: Software has now taken on all the parameters of hardware (i.e., requirement creep, high percentage of flight mission cost, need for quality control, need for validation procedures, etc.). It has the added feature that it is hard as blazes to determine it is not flawed. Get the basic system working first and then add the bells and whistles. Never throw away a version that works even if you have all the confidence in the world that the newer version works. It is necessary to have contingency plans for software.

  Rule #82: Wrong decisions made early can be recovered from. Right decisions made late cannot correct them.

  Rule #87: Projects require teamwork to succeed. Remember, most teams have a coach and not a boss, but the coach still has to call some of the plays.

  Rule #88: Never assume someone knows something or has done something unless you have asked them; even the obvious is overlooked or ignored on occasion, especially in a high stress activity.

  Rule #90: A puzzle is hard to discern from just one piece; so don't be surprised if team members deprived of information reach the wrong conclusion.

  Rule #94: Mistakes are all right but failure is not. Failure is just a mistake you can't recover from; therefore, try to create contingency plans and alternate approaches for the items or plans that have high risk.

  Rule #96: Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.

  Rule #100: Never make excuses; instead, present plans of actions to be taken.

  • Also see this [http://appl.nasa.gov/ask/issues/14/practices/ask14_lessons_madden.html similar and related list].