Here is what we do where I work:

a) We use a wiki for documentation. Not Word files, or text files. A wiki that is searchable, fully change tracked etc. (I would recommend confluence, but confluence v4 is such a dog that I suggest you look elsewhere)

• Any repetitive or delegate-able processes should be documented.
• Checklists of "here is how we do _____" should be written
• Checklists are very important to building teams, as they allow processes to be done by anyone who can follow the list...

b) Version control, obviously

c) Case/issue tracking system, obviously

d) Commenting your work. This is the most nuanced thing, and it is so hard to teach, but as a contractor/independent, you may be able to grok this: Comments should explain your thought process and the why of what you are doing. Links to documentation, stack overflow, etc are appropriate. Paragraphs and pages of comments are appropriate. Explaining the things you tried and did NOT do are appropriate. One of the biggest problems of code is that the thought and sweat that goes into making something work one way (as opposed to a different way) is lost. There is a book, something like 'beautiful code' or such, that has a chunk on the comment blocks in a unit in one of the big open vcs systems (subversion or git, I think). It is beautiful because it tells the story. Here is what this code does. Here is how it works. Here is how it is structured. (I confess that this block, as I recall, may not go big into the "why" question.)

A corollary to this is: How many people go back and edit code just to add comments? We all should.... a lot. But in practice almost no one does.

Here is what we do where I work:

a) We use a wiki for documentation. Not Microsoft Word files, or text files. A wiki that is searchable, fully change tracked, etc. (I would recommend Confluence, but Confluence v4 is such a dog that I suggest you look elsewhere)

• Any repetitive or delegate-able processes should be documented.
• Checklists of "here is how we do _____" should be written
• Checklists are very important to building teams, as they allow processes to be done by anyone who can follow the list...

b) Version control, obviously

c) Case/issue tracking system, obviously

d) Commenting your work. This is the most nuanced thing, and it is so hard to teach, but as a contractor/independent, you may be able to grok this: Comments should explain your thought process and the why of what you are doing. Links to documentation, Stack Overflow, etc. are appropriate. Paragraphs and pages of comments are appropriate. Explaining the things you tried and did NOT do are appropriate. One of the biggest problems of code is that the thought and sweat that goes into making something work one way (as opposed to a different way) is lost. There is a book, something like 'beautiful code' or such, that has a chunk on the comment blocks in a unit in one of the big open VCS systems (Subversion or Git, I think). It is beautiful because it tells the story. Here is what this code does. Here is how it works. Here is how it is structured. (I confess that this block, as I recall, may not go big into the "why" question.)

A corollary to this is: How many people go back and edit code just to add comments? We all should... a lot. But in practice almost no one does.

Here is what we do where I work:

a) We use a wiki for documentation. Not Word files, or text files. A wiki that is searchable, fully change tracked etc. (I would recommend confluence, but confluence v4 is such a dog that I suggest you look elsewhere)

-- Any repetitive or delegate-able processes should be documented. -- Checklists of "here is how we do _____" should be written -- Checklists are very important to building teams, as they allow processes to be done by anyone who can follow the list...

b) Version control, obviously

c) Case/issue tracking system, obviously

d) Commenting your work. This is the most nuanced thing, and it is so hard to teach, but as a contractor/independent, you may be able to grok this: Comments should explain your thought process and the why of what you are doing. Links to documentation, stack overflow, etc are appropriate. Paragraphs and pages of comments are appropriate. Explaining the things you tried and did NOT do are appropriate. One of the biggest problems of code is that the thought and sweat that goes into making something work one way (as opposed to a different way) is lost. There is a book, something like 'beautiful code' or such, that has a chunk on the comment blocks in a unit in one of the big open vcs systems (subversion or git, I think). It is beautiful because it tells the story. Here is what this code does. Here is how it works. Here is how it is structured. (I confess that this block, as I recall, may not go big into the "why" question.)

A corollary to this is: How many people go back and edit code just to add comments? We all should.... a lot. But in practice almost no one does.

That is my 2cents

Here is what we do where I work:

a) We use a wiki for documentation. Not Word files, or text files. A wiki that is searchable, fully change tracked etc. (I would recommend confluence, but confluence v4 is such a dog that I suggest you look elsewhere)

• Any repetitive or delegate-able processes should be documented.
• Checklists of "here is how we do _____" should be written
• Checklists are very important to building teams, as they allow processes to be done by anyone who can follow the list...

b) Version control, obviously

c) Case/issue tracking system, obviously

d) Commenting your work. This is the most nuanced thing, and it is so hard to teach, but as a contractor/independent, you may be able to grok this: Comments should explain your thought process and the why of what you are doing. Links to documentation, stack overflow, etc are appropriate. Paragraphs and pages of comments are appropriate. Explaining the things you tried and did NOT do are appropriate. One of the biggest problems of code is that the thought and sweat that goes into making something work one way (as opposed to a different way) is lost. There is a book, something like 'beautiful code' or such, that has a chunk on the comment blocks in a unit in one of the big open vcs systems (subversion or git, I think). It is beautiful because it tells the story. Here is what this code does. Here is how it works. Here is how it is structured. (I confess that this block, as I recall, may not go big into the "why" question.)

A corollary to this is: How many people go back and edit code just to add comments? We all should.... a lot. But in practice almost no one does.