Even if it is only a text document or a Wiki, documentation helps collect thoughts. Most programmers try to avoid it, probably because they see a lot of it as pointless, which a lot of it is. For example, rarely do UML diagrams prepared in advance (or after) match what was developed.
But some level of decent documentation will help you and those who come after you, so have a think about what you might need to plan and what others might need to know.
Tip: Don't be afraid to reject poor quality documents. It can be negligent to soldier on with insufficient information and not inform your manager of the problem.
Rejecting a requirements document that isn't good enough will cause consternation and fluster among the business analyst and customer and should not be done without reason. One role of a Lead Developer is to reject requirements that are too vague to proceed with development. For example, what happens when the cancel button that is shown on a page is clicked? What does “the screen should go back where it was going” mean when the screen is no longer valid for display?
