Recently I talked with some folks from a college involved with game development.
One of them says, "(person X) says he doesn't know anything about game development". Person X is a major official of a group that's all about game development! Then later "(person Y) doesn't know games" (or maybe he said, "game development"). Person Y is heavily involved in game development/creation education, and ought to know something about game development, surely. But person Y comes from the art side of things.
On thinking about it, I recognized that the speakers equated "games" and "game development", and further equated "game development" with computer programming.
Fairly obviously, you can know a lot about games, in a variety of ways, and not know much about game development. We get students all the time who think they'll be good at creating games simply because they like to play games a lot: NOT SO, bucko. Yet you can also be an important part of a team that creates electronic games, and know next to nothing about computer programming.
This long introduction leads to the key question: is "game development" now the equivalent of computer programming for games, or is it something much broader? When creation of an electronic game was a one-person endeavor, back in the 70s and 80s, every game developer had to be a programmer. But this "one hero per game" style practically ended around 1990--I've had students who were born later than that--as most games became too big to be done by one person.
Nowadays, many more artists than programmers work on electronic games. And there are teams of game designers, level designers, sound people, narrative writers, and so forth working on big games. Programming is the minority endeavor.
More important, in almost all cases programming nowadays can only screw up a game, not make it outstanding. What makes an electronic game outstanding is, first, the design, the gameplay; second, the look and feel of the game, which is a combination of design and art. Good programming can certainly contribute, but mostly, programming is there to implement the vision of the designers and artist, and is a fairly mechanical contribution to the game. But if it's poorly done, then it can ruin the game. Patches typically fix programming problems, they can rarely fix fundamental design problems.
Now mind you, unlike a great many of the people who teach programming (I do not), I actually worked full time as a programmer for a while before getting deep into networking and user support. Nonetheless, this is my take on programming, especially today:
"Programming is donkey work".
What I mean by "donkey work" is that programming is mechanical. We know today that many of the steps programmers used to have to do manually, are now done by software tools. Ideally, we'd like to be able to tell a computer-based tool what kind of game we want, provide it with art, and it would write the programming. Game engines go partway in this direction, simplifying programming by (in effect) doing some of it themselves.
Constantly, people are trying to write tools that will make programmers less and less necessary, less and less important.
Yes, yes, we know there is creativity in programming. But once we get past the highly entrepreneurial stage (which we have), too much creativity in programming causes problems. In games we want programming to be reliable, solid, fast--mechanical, not creative.
So what is "game development"? Not programming, folks, it's design and art, with programming coming in near the rear. Programming is a necessary evil, not the heart of an electronic game. (And if we stray into the world of non-electronic games, we have design and we have art, but we have no programming at all.)
Now perhaps we could agree that "game development" means programming, and we can change our "game development" curricula names to "game creation" (those that includes artists and designers, at any rate). Or we can recognize that "game development" means all aspects of game creation, not just programming.
Unfortunately, "game development" programs in colleges and universities are often started by programmers, who have no interest in art and little interest in design (and sometimes, little interest in games!). In many less-well-known schools "computer programming" is going away as a topic of interest for the millennial generation, or has already been dropped; "game development" is grabbed as a life-saver for those who want to teach programming but lack students. These "game development" curricula are about fifteen years out of date when they start. My own experience of this is that when programmers start "game development" programs, those programs are a disaster for artists and designers. "Game development" should be in the hands of gamers who are teachers, not of programmers.
If you're a student planning to pursue game creation as a career, find out whether the school you have in mind runs the programming version of game development, or the broader version that accommodates non-programmers.