Tuesday, November 01, 2011
More on specialization
My recent post on specialization has ignited a bit of argument with people on one side saying that I've "come out against learning" and specialists who didn't like my use of their UI/database specialties as a poor example (if I die in a suspicious UI/database related incident, my post is to blame).
The point of the post was that we should encourage "multi-learning" or more cross-specialization without seeking to homogenize all specialization. The point of the "anti-specialists" is that a graphics programmer should learn more about physics programming. There are benefits, personally and professionally, to doing this. There are common solutions in both and insights that crossing boundaries can create. I agree.
On the other side, many deep specializations take, as Malcolm Gladwell wrote, over 10,000 hours of practice and an innate skill to achieve mastery. I use the example of musicians because as a untalented amateur musician, there is no way I am going to become skilled enough to even write 10% of the music that a game needs. However, having worked side-by-side with them and learned their workflow, I can still help them do their job. Having learned about mixing and composition a bit, I have widened my world and appreciate game sound tracks a bit more.
We often specialize far too much. For example, some studios have specialized QA to the point where a programmer just has to hand off barely compiling code and someone else integrates it. QA should be the more the responsibility of everyone creating the game. Everyone on the team should care about quality. It shouldn't be a role.
We should also learn more about every surrounding role, every day. We each shouldn't be just a specialist cog in a development machine. We should be "game developers" first and [fill in the blank] specialists second. How many games have you seen or worked on where its apparent that one area of specialization dominated and ignored the rest of the game?