As a game developer, I'm accustomed to building games around game mechanics. It's often a struggle to convey the importance of strong core game mechanics when they are not visible like beautiful art or animations. This article makes it clear that adding game mechanics as a (problem solving!?) wrapper to a non-game is akin to adding (problem solving!?) graphics to a game.
Nevertheless, I think that parallel can extend further in ways that might soften the article's point (just as the author did at the end). Some game design components, like clear state feedback and reward, are not so much game mechanics as they are signals of the mechanic's state (usually done with art in its general sense). In the same way, those signals could be incorporated into non-games to reflect the internal workings of their state.
So, in the end, I agree with the article and think it provides an insightful lens through which to view the parts of games relative to more tradition software.
I had 6 internships under my belt by college graduation and they taught me a lot. However, by and large, I learned more about workplaces and teamwork than about difficult programming situations. Internships, in most of my experience, don't encourage really hard programming work.
I got that with my CS degree. The theory classes were 7 out of the 15 classes I took, but the programming classes were just as intense. We did complex image recognition in groups in Java the first year, tons of Scheme and Oz to learn concepts, and then wrote a whole networking stack and basic Linux OS in C. The latter two projects were significantly harder than anything I've done at an internship and required teamwork and a great deal of self-teaching.
It may be that my experience was abnormal (the school had a small but recognized CS dept), but I got the meat of my practical programming skills at school (ignoring independent work for the sake of focused discussion). Internships were certainly useful - but in my reflections I don't think they increased my programming power, if you will, all that much compared to school.
Nevertheless, I think that parallel can extend further in ways that might soften the article's point (just as the author did at the end). Some game design components, like clear state feedback and reward, are not so much game mechanics as they are signals of the mechanic's state (usually done with art in its general sense). In the same way, those signals could be incorporated into non-games to reflect the internal workings of their state.
So, in the end, I agree with the article and think it provides an insightful lens through which to view the parts of games relative to more tradition software.