I've worked at a very large (60,000+ employee) company, so perhaps my background clouds my judgment somewhat, but I think requirements documents are quite helpful. The Software Functional Specification that was handed to me provided a good background to the problem space.

When I wrote the Software Design Specification (100 pages, oof...), I easily solved 2/3 of the bugs before I touched a single line of C code. I was surprised, since I didn't think I would enjoy the documentation process, but it really helped. I designed my module using English and pseudo-code, sent the spec around for comments, and when the spec was approved it was a (somewhat) simple matter of conveying a solid design into C.

Meetings still suck and should be minimized, but documentation is really essential. I always glance at the Design Spec for a feature before going into the code, since it gives you some solid background as to what exact problem they were trying to solve.

This is essentially a very brief summary of the 37 Signals (e)book, "Getting Real" http://gettingreal.37signals.com/

I suggest you all read it. They have some really, really good points and analogies.