I've started a handbook called "The People's Guide to Contracting". It's a work in progress, so you can check here from time to time if you want to see it grow. Here's what I've written so far:

People’s Guide to Contracting 

In the words of John Zinn “Wherever you go, there you are!”

1. Be prepared from the start - You’ll be interviewed for the job. There’s usually a period of time to ramp up before the job starts, but not always.
   1. The O’Reilly Bookshelf - has most books available on software development online for a small subscription fee, available as a trial.  Your local software user group can sometimes get you a free subscription. O’Reilly gives away lots of books through user groups.
   2. Books in printed form are good and easy on the eyes, but dated sometimes.
   3. Online forums - are useful tools to post and reply to topics you have questions about. Usually have rapid responses.
      1. Stack Overflow
      2. Codetown.us
      3. Various Usenet News Groups on specific topics
   4. User groups - good to bounce ideas in person
   5.  
2. Invest in the appropriate tools and equipment. You’re called in as a contractor because you have the skill set the customer lacks. That includes knowledge about the subject, technology, and you as an independent contractor must provide your own equipment and software tools. There’s no time to waste on slow computers and out of date tools. Get the best you can afford and keep it up to date. Be sure you and the customer have the same configuration. 
3. Listen carefully to every aspect of the project - Keep good notes. Google Docs is a useful tool that lets you outline and categorize your notes. It’s reliable and can be secure. You can also easily download everything quickly for use when you are offline.
4. Analysis - Unified Modeling Language (UML) is an industry wide standard and your best friend. Start with Use Cases and support them with Interaction Diagrams, Sequence Diagrams, and the rest of the UML tools. Modify these diagrams every time something new arises. Fowler’s UML Distilled is good.
5. Code dissection - This is why I started this handbook. I call my approach “The ABC’s of Code Dissection”. 
   1. Get code mentors to walk you through existing code. There’s nothing better. But, keep your eyes open for false assumptions.
   2. Use pseudocode to model existing code. Numbers and letters work well for modeling. For example, use variable names like A, B, C... and values like 1, 2, 3... to speed up transcribing the model. Use your computer to capture the model if possible to avoid having to copy notes.
   3. Print out the codebase and pin it up on the wall. It’s easier to deal with it in printed form. Use colors and diagrams to support your analysis. You’ll find yourself doing the same thing project after project. 
   4. Break the code up into sections. For example, user interface, database and server might be the top level sections. You’ll encounter overlap in the code, so create sections that capture where the code is and what it affects.
   5. Software architecture pattern recognition - You’ll begin to see patterns in the architecture. Isolate these patterns and you’ll have the power to reuse or change them. Gamma’s “Design Patterns” is good.
      1. Patterns allow for “pluggability” which is the ability to swap components easily. For example, say you discover your database doesn’t support a feature you need like stored procedures. Swapping the database can be a simple task if patterns were used in the SDLC.
      2. Code injection is the Spring Framework’s approach. It’s accomplished using patterns in the form of code components. Isolate repeated code to create objects, modules, whatever your programming language allows. Every bit of code you draw out into isolated units will speed up the SDLC and make the program run faster.
   6. Data modeling - you must often create your own data. Do a model of the project workflow. My example is “I am a beam of light”, which enters the eye. The light hits the retina, etc. Separate out verbs and nouns, making a glossary. You’ll wind up with a Data Dictionary with names and attributes, quantities and constraints. You can create your own data from the dictionary.
   7. Testing - automate with unit and integration tests. Write tests to verify code before you write the code. Every change you make to existing code must not break the codebase. You can inject your test framework or have a separate test codebase. It’s easier to have a switch that turns testing on and off.
   8. Tools (draft):
      1. database - TOAD
      2. profilers - Clover
      3. requirement repository - ReqPro, Doors
      4. UML - Visio, TextEdit and Textpad 
      5. stay tuned...
   9. Always question the given scenario. Be brave and write snippets to prototype alternatives to run with test data.
   10. Make code components if you find changes overly involved to implement. For example, if you need to add a column to a database table and it involved dozens of independent changes to the underlying codebase, consider extracting the HQL (or whatever) and injecting reusable components.
6. Workflow - your daily workflow should include
   1. Log - keep a record of time, tasks and comments every day. The Log is your tool to keep your mind uncluttered. It allows you to think about other things while retaining details you couldn’t possibly remember later.
   2. Backups - use a code repository every time you change anything in the code with a README file or details explaining clearly what you’ve done and discovered.
   3. Daily standups - in one form or another you should talk with your team or lead every workday. Communication keeps details of work in the open and exposes hints and tips that make work more efficient. Beck’s “Extreme Programming” is good.