There won't be any documentation or there will be scant documentation, or it will be out of date. Find all the documentation that does exist. If it's in a team repository, don't make a copy. If not, put it there and ask your manager for permission to organize it, perhaps with some supervision.
Get everything up into the repository for the team and add a Glossary. All bases have jargon; document it in the glossary. Make sections for tools, products, customer-specific, etc.
Create / Update a software environment creation document. All tools, quirks, install choices, etc. go here.
Then upload a Getting Started With "ProductName" document or the like. Let it be just mind flow and self-organize over time. Then go through out of date docs and get them back to date. The other developers will appreciate it, you'll be contributing in a unique way whilst learning the code. Especially document all such things that stump you or are named wrong or are counter-intuitive.
Once your leaning curve is coming to an end, don't worry about updating the documentation. Let the next new guy do that. When he arrives, point him to your work. When he continually bugs you for answers, don't answer him. Rather, add the question to your documentation and then hand him the url. Fishing pole.
One side-effect is that you will have made a tool you yourself can reference months from now when you forget.
And although it's not documentation, a related issue is all the little quirky, manually intensive procedures your team mates do. Automate them with batches, sql scripts and the like, and share those as well. After all, procedural knowledge is arguably as big as declarative knowledge in terms of getting productive in a new environment. Whatever it is, don't do it; rather, script it, and run the script. Fishing pole strikes again.