Design documents are good: they force one to think about what they're doing before they do it. Too bad they've gone out of style, since they directly contradict the "agile" approach where you just fix it in the next sprint...

My issue with this is that there's a lot of times when it's faster for me to just build the thing. And building the thing is going to uncover problems a lot faster and a lot more accurately than me sitting down and trying to imagine all the problems that may possibly occur, and then missing problems anyway because it turns out reality is way more complex than you can plan for.

Design documents are great in situations where risks are high, or where code changes take a long time to do (usually because every code change requires a design document).

I don't know how much is required of you but I find it very valuable to take my iPad to a coffee shop and flesh out my idea on "paper" before I code anything. Then it becomes a lot easier to code the right thing.

Design docs don't contradict agile at all. If you had said scrum then I might agree.

I meant "scrum." I have worked in "scrum" shops that would leave team for design, but it is a rarity.