It's kinda sad that art students are giving out advice for software engineers.

Not really sure how to take that comment... at best it's irrelevant, unless we were discussing art or software engineering. In this  instance we are referring to game design. If I were giving advice on software engineering I'd half understand, but even then, Technical Art does entail tools programming, so not really.

As to the advice itself:
I'd suggest writing all ideas down. In retrospect, you will always find ideas you thought were good, to be total crap, and vice versa. Brainstorming is a good starting point for any design endeavor, and you really don't want to have a filter from your brain to the paper (or word processor) at this point.

Well, I understand where you're coming from, but I stick by the design doc as the most important tool to make a good game.
Sure, if he just wants to make a game with no goal or purpose just for him to play, then by all means neglect it- there is nothing wrong with that, it's fun to sometimes do it, I used to when I started using RM2K. If he's going to make a game that others will play- he will have to translate his ideas into something that's fun and enjoyable, and that doesn't happen by accident- it happens by design. And games are not new, they have been around for as long as people have been able to communicate. You're referring to video games specifically, which are simply a different medium, not concept.

The game design document is a unique tool to games, in film it's your script, in design it's your thumbnail sketches, in animation it's your key poses, in programming it's your design pattern. You OBVIOUSLY don't make a design document where it doesn't fit, but in games it's very important. By the way, I never mentioned any OFFICIAL GAME DESIGN DOCUMENT. As I said, there are many templates out there to pick from, but in general they tend to cover the key areas of a game.  It's like saying "screw those Hollywood suits, you don't need a script! Just go shoot the film!".

Even looking at designing a game such as soccer (football!!), you may ask yourself questions in a doc that lead to more questions leading to a cohesive design like : "What is the goal of the game?" "-To score more than the other team" , "Ok, how do you score" "-You get the ball in the net". From here you could ask yourself how big the goal is, and play test, and iterate, and decide that perhaps the goal is too small or too big, and adjust, then you want to figure out how many players are going to be on each team, and how those players interact, and how that interaction can be unique (i.e.Only allowed to use your feet and head), etc., etc. The elevator pitch can be, "A competitive ball game where players can only use their head and feet."

As a beginner one may not know what questions to ask to get to these helpful answers, and that's where using a design doc comes in.

I can agree with being a free thinker, etc, but it's silly to try and re-invent the wheel- especially as an amateur/beginner. If David Jaffe comes to me and says he thinks he has a better method- I'll take it, he's got the experience to make such a call. I know I sure as hell don't have the experience create a new system, and he probably doesn't either, considering he's here asking basic questions, so I'm not deferring to my own authority, I'm trusting the experience of those who have done it.

There also seems to be some sort of misunderstanding as to what the design doc IS. I'm sure some people are very technical about it, and go about it in the cartoony way you described, but most of the one's I've seen are very gameplay and creativity- driven.

To say that enjoying game-making and making a good game are mutually exclusive is disingenuous.

These pissing contests get old for me really fast. The OP hasn't been on for a month anyway, I doubt he would benefit from any on going discussion anyway.