This depends a lot on the project methodology your are using (e.g. the Rational Unified Process versus Scrum), and how much you value process documentation in comparison to code.
In some contexts it is important that all requirements and design decisions are traceable: why did we choose this alternative, who decided it, where is it implemented? Usually, this means that a feature is designed separately before it is implemented, and the design is captured with textual descriptions, diagrams, etc.. These documents are deliverables of a design phase. If you have such requirements, then of course the diagrams should be created before writing your classes.
On the other hand, most projects do not need to document each step of their process. In fact, the Agile movement explicitly favours “working software over comprehensive documentation”. The code already contains the design, so it is not necessary to create extra diagrams at all. Whenever changes are made to the code (new features added, bugs fixed), the design changes and the old diagrams would be out of date. Updating all documents to reflect the changes takes a lot of effort that could otherwise be spent on adding value. It slows development down.
There is probably a middle ground between these two extremes that is right for your circumstances. For example, I find that a sketch of a diagram can be a very efficient way to communicate a design idea to other people, and that diagrams and overviews are invaluable for introducing new people to a system they are supposed to work on. The code itself contains too many implementation details that detract from the overall design, so “read the code” is not a good response to “do you have some diagram describing your architecture?”. This does not mean I have to create detailed diagrams for every class.