I'm not a big fan of Malcolm Gladwell's books, but one of the things I read about after seeing a review of his book Outliers got me thinking about my own students.
His book Outliers is based on the research of Anders Ericsson in which he studies the commonalities of "experts" and how they came to be that way. The upshot of which is that it is all about "practice".
Notionally, the book suggests that you become an expert at something by fulfilling a regimen of practice for "10,000 hours". You can read the research yourself to see how far Gladwell has stretched that notion. The thing is, 10,000 hours works out to roughly 3.5 years of full-time 8 hours-a-day work!
To give you a bit of background, I teach part-time at a University in the UK and one of my classes involves a module called Advanced Games Technology, in which we ask students to produce a full game for themselves over a two semester period.
We don't really specify much in terms of constraints other than "it has to be 3D" and "it has to use some middleware". Ultimately it is meant to be a portfolio piece for them, so they can throw all of what they've learnt into the game and produce something really polished.
Now I've been teaching this module for a few years now, so I've started seeing some patterns in terms of student response to this relatively simple and open brief. Can you guess what it is?
Yep, it's paralysis. Literally, for some reason the sheer concept of starting a project from scratch on this scale seems to throw most of the students into a cartwheel of indecision.
My thinking is that this is because up until that point, they have largely worked off fairly strict briefs and fairly regimented development schedules with specialized classes and teaching to support them. But then they are faced with "do whatever you really want to do" it seems what they really want to do is nothing!
Only, it's not strictly that simple. Because this isn't just common garden student laziness (anyone who has taught knows what that looks like). This is something else, and I feel like it has some relationship to the expertise issue. Which is that they simply have never practiced actually thinking of making a project from scratch for themselves.
Or rather, they haven't practiced often enough for it to be second nature that you have a hundred ideas you want to create and never have enough time for them. Almost everyone I know in the games industry has both done more than 10,000 hours worth of work in their respective roles and has also gotten hundreds of ideas for games they would like to make.
Analysis Paralysis
The other issue, I think, is that many of them fail to start because they are stuck in the limbo of indecision trying to choose which technologies to build and which middleware to use. I've seen this issue happening with indie projects as well. Literally never starting on something because the perfect technology is not quite there, even if one is "close enough".
The main factor is that if you find that there is always a barrier to you starting a particular project (be it a new piece of technology, a new art piece, or a new feature for a game), then you should maybe start thinking that practice in terms of just producing something is a good idea.
I used to get that kind of feeling a lot when I was doing my own indie games using Torque. I always found myself waiting for the garagegames.com guys to develop some new technology they'd been talking about so I could then work on using it for my game.
That whole notion of waiting for someone else to develop core technology simply wasn't something I ever had when I was working in commercial development, where we would rather work on our own solutions and not use someone else's.
But the end result was that I had an excuse not to simply practice and make progress even if ultimately I would end up using their solution further down the line.
How To Fix The Problem?
This is basically a mental blockage as much as anything else. But the ideal solution is to "practice" these things until they become almost like muscle memory. One great way I think to approach this, is to take part in a short term development competitions like Ludum Dare or any of the game jams.
At the very least you will not feel like you are the only one to have the blockage. But if you practice throwing together project code and "getting things done", you will eventually get over that hump of not being able to figure out where to start.
Here area few other ideas for practice for programmers:
Make yourself create small project files from scratch, including setting up all build settings. Create your own libraries from scratch and use them as both static and dynamic libraries.
Make yourself a testbed project and integrate new technology middleware into it often, write code so that you can "wrap" each middleware so that you can implement new ones in an opaque manner.
Take on a new aspect of technology, in an area you are not familiar with (animation, graphics, networking, physics, engine design etc).
Practice 2D and 3D, make prototypes that work with similar code across both (thinking in components is good here).
Work on math skills, practice things like orientations and simple but useful tools like easing. Do plenty of work involving different coordinate frames and transformations.
Work on interfaces and API designs. Time them and profile them. Look at how memory changes and how different sizes of allocations change the profiles.
Find a new aspect of the language and implement something new with it. Look at delegates, smart pointers and any new C++ standards features. Study new features in boost and other open source frameworks (POCO for instance).
Learn a new language, implement a completely unrelated type of project with it than you normally work with (i.e. a database, a tool of some sort etc).
I do think that many companies would actually be wise to give their devs time to practice starting smaller games from scratch too, although it seems fairly rare. But the idea of making quick prototypes and generally not sweating the details of choices or designs or architectures I think is a useful practice as it stretches you to not be concerned with details and instead by productive and experimental.
Of course the details matter, but then you can practice those issues separately. As the Ericsson research shows, the best experts actually use a well thought out practice regime. It isn't that you simply practice for its own sake, but that you practice in order to learn something new, or to commit to memory some process or practice that you can build on incrementally. In a way you are trying to find flaws in your own process and then factoring in corrections into the overall practice regime.
I've recently been teaching myself 3D art skills, and one of the things I've learnt is that simply practicing things like sculpting (for faces) helps to improve my eye for proportion and anatomy and helps me understand what makes a "good" image. So doing regular sculpting, even if I'm still fairly tragic at it all is good. As I learn the tools and the forms, I slowly begin to appreciate the underlying structure and process.
I think we can see code in similar terms. So doing quick and dirty prototypes will begin to show you the underlying patterns we need to commonly use in more complex works. Or will show us some aspect of design we aren't fully aware of until we actually try and develop in that area.
So my questions to you, the readers of this entry. Have you done your 10,000 hours? How do you approach practice and what do you do to work on your skills and to expand your working process? Have you tackled anything new recently? How did you learn the new area and how can you apply those learning processes to new areas next time?
[This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]
I was thinking that it would take me only 2 years, but then I realized that those 10.000 hours probably don't apply to game programming.
You can maybe become a master expert with 10.000 hours of shader programming
or doing stuff with databases.
If you spent 10.000 hours working on something specific, you can become a master of that, but game programming encompasses a lot of subsections itself. And becoming a master at them would require 10.000 hours each, IMHO.
I started learning scripting and making some basic games in Unity for a few months now. As soon as I get some more free time I'm going to try my hand at learning Blender. I already know a bit about C4D and Maya, so I'm hoping it won't be a huge jump. And I plan to learn the piano and learning music theory. In theory I'll be a one man production company, in actuality I'll probably go insane.
But I'm spreading myself relatively thin. I wonder how this 10,000 hour rule applies if you're practicing multiple things at once.
great article! my only comment is that 3.5 years of full time work doesn't seem like enough to really make you an expert in something as evolutionary and complex as game design or computer science. i think getting a formal education in the theory of computing is a better approach. knowing the theoretical foundations of a science makes you more an expert than practicing an evolving science where everything you know is no longer applicable in 5 years. though of course, you can't be an expert on theory alone.
Interesting article. I wonder how that 10,000 hours of work changes considering the more you do something, the better and faster job it becomes. If it took me 10 hours to do a task one day, by "mastering" it I should be able to do it in say... 5 hours or less. I question if at that point, you've already "hit" the 10,000 hour goal. Is the 10,000 just an arbitrary number to overwhelm and inspire or is there a literal science behind it?
In addition to the problems you've put up here Phil, there are more from my experience of higher education (I went into it at 26, having been involved with PCs since I was in single digits) and there were those on this level 4 HND Computing course who had done so many computing courses/qualifications beforehand - including private ones such as CompTIA and Cisco - and yet failed to grasp what a CPU is or how they would build a PC, despite being given the brief that it was to replace 20 office PCs and had to keep to a budget etc, or building a network, being familiar with "Hello world!" as a concept if nothing else etc etc etc.
The problems were very much akin to what you describe with your assignment. Just as regarding building office PCs, the students didn't know what budget they should keep to (it was up to them), what components they should use (one student was thinking to use Core i7s just weeks before the "sequel", if you will, was to come out), often their specifications missed out on hardware (such as a power supply!) and others simply failed to start at all. All this because they'd not even done their first hour of building a PC, let alone their 10,000th.
Given when I first was messing around with PC hardware (not at all in the days of the 286 to 486, but starting with a Pentium 133-based system) back in 1998 or so, I knew how awkward it was then with the tiny wee jumpers, setting the FSB and clock multipliers manually and such, but these students of varying ages (from 17 to 30) hadn't had that opportunity. Nor created it for themselves.
When it came to a more general knowledge, their lack of general knowledge was what was apparent. For Java programming, the tutor had decide they should use a primitive Java IDE (BlueJay as I recall) rather than Netbeans or Eclipse (why learn the primitive IDE for BlueJay when they're only going to learn something very different later? Self-sabotage much!), open-source software (including OpenOffice), 3D Buzz's free VTM series (which I knew of since UT2k3 and the first "Make Something Unreal Contest") or that the Dummies books are good place to start for *anyone* (including me). And none of them knew of Gamasutra and although I did pass the knowledge on, they simply weren't interested (either because of me and/or resentment or whatever). So all those post-mortems, GDC videos talking about development (especially interesting from a programming perspective if nothing else) etc were all ignored by them.
And all because they hadn't put in that investment that I had done and what William, above, is doing. As a hobbyist and/or serious enthusiast, you'll put hours into learning and acquiring a general knowledge with optionally some specialisation. There will be gaps to be sure, but only because you didn't require to learn them (although some book/video learning is always advised in my opinion) just like I did, whereas these students - and no doubt many more - never bothered and never learned prior, nor on the course, the tools needed to break a problem down and tackle it independently and by themselves at that.
Which brings be back to your post Phil, by the time your students get to you and you give them a rather open-ended brief, its akin to saying to an artist "here's a piece of A4, you have to use pencils and a rubber and it has to be abstract - now go draw something!", albeit a lot more complicated. I say that because these students will more than likely just play treble-A titles (or even single-A for that matter) which usually uses something like the Unreal engine. Few will think of Unity, Torque or even a game maker-type program for that matter. Even fewer will think to pick up a book or two on building a 3D game engine.
This bit here most of us will know, but knowing the education system like I do and students for that matter, it requires mentioning. Because building a game solo requires the student to be able to draw both concept and reference art, build geometry (be it characters through to static meshes) and skin that geometry (so Photoshop and UV unwrapping skills), design levels (which ties back in with drawing and building geometry) and possibly learning the programming language inherent in the middleware they choose. This is before sound effects and music come along. I'm willing to bet 50p that is what is going through your student's respective heads. That and their, again respective, brains each instantaneously turning into a mushroom cloud... ;)
And I find that's the problem - too many skills to know and practice and a combination of lacklustre tutors, students and material combined are dragging everyone who (at the very least) is decent down with them. But instead, I find for the most part (keyword there, "most", not "all") that tutors and education establishments do is slightly paraphrase the "Charlie Sheen maneuver" (as in "we've already got your money dude...").
And also drilling into them that programmer art is better than not having any art at all! But then, its that connection, I found that there is an animosity of "us vs them" with those who are in design (usually on Macs to sour it further) vs those who are programming rather than uniting them (as has been famously done at Carnegie Mellon).
Now I must apologise as this has become a big rant, it is something I'm passionate about but still. One final point, is that you're right that companies should allow programmers to build little projects of their own every now and then. A point brought up in the RSA animation about drive and motivation in the workplace (which you may have seen already, but for reference: http://www.youtube.com/watch?v=u6XAPnuFjJc - enjoy!).
"I used to get that kind of feeling a lot when I was doing my own indie games using Torque. I always found myself waiting for the garagegames.com guys to develop some new technology they'd been talking about so I could then work on using it for my game."
I was at GarageGames fostering indie game developers on the publishing side and saw this phenomena a lot. Talented developers - with teams and tech even - would stall or put off projects because they were always waiting for some external force to align just right to enable them frictionless development. Fuck that. You want to make the most awesome form of entertainment in the world (games) you gotta jump in and get all kinds of dirty and wet. You will probably even go cold or hungry. You will definitely go unappreciated or under-appreciated. I was one of the few indies at that time that cut through all red tape to get my game done and published (Shelled Online, published by Cherry Credits) and didn't understand why for every one project finished a hundred were abandoned, death by excuses. I figured I had tenaciousness they didn't and I think it's THAT aspect that should be taught to students - that making games is hard, long, often unrewarding work (in terms of profit, audience size, and critical acclaim), but if you love it you'll stick with it and see your game to completion at all costs, and that is the self-actualized reward in and of itself. The cynic in me says this is a form of Darwinism and it's not something to be turned around but rather a natural force to separate out the wanna-bes from the real deal.
"If you don’t want to work hard, there is somebody out there that is working hard at becoming great, and they will take your place." - Jeff Tunnell (on the 10,000 hours concept)
Teach your students that quote, strike fear in them for the competition over the jobs they want, and help them find their internal drive to make great games that millions may play and love. I got to have that experience and it was years of sacrifice in other areas of life balance but I wouldn't have had it any other way.
I'm concerned by the "3.5 years" Milestone with an "8 hour work day". If it is indeed an 8 hour work day, five times a week, 50 weeks a year assuming you rest a little, it's 2000 hours of work per year. That's five years to get your 10.000. And can you even possibly say that you work 8 straight hours on core edge expert kind of work? You don't answer any email? Attend to no meetings at all? Let's assume you have the "precious" gift of doing every single day expert type of work HALF the day, and the other half is spent in non expert still job related tasks. Then it is not five years, now it's 10. Assuming you work on your expert field for whole ten years, interrupted, without moving up to management or having less time to do expert work because you got good enough that now you're required to lead other not so experts...
Even if you work some stuff at nights or weekends, life has chores, illness, unexpected situations and such. Those 10.000 hours are hard to get because they must be spent explicitly in the thing you want to become an actual expert at, and the day just have 24 hours, with just so many other things to do. Assuming you already know what do you want to become expert at.
Oh, so just 1 year at a "typical" game studio. ;)
I was thinking that it would take me only 2 years, but then I realized that those 10.000 hours probably don't apply to game programming.
You can maybe become a master expert with 10.000 hours of shader programming
or doing stuff with databases.
If you spent 10.000 hours working on something specific, you can become a master of that, but game programming encompasses a lot of subsections itself. And becoming a master at them would require 10.000 hours each, IMHO.
But I'm spreading myself relatively thin. I wonder how this 10,000 hour rule applies if you're practicing multiple things at once.
The problems were very much akin to what you describe with your assignment. Just as regarding building office PCs, the students didn't know what budget they should keep to (it was up to them), what components they should use (one student was thinking to use Core i7s just weeks before the "sequel", if you will, was to come out), often their specifications missed out on hardware (such as a power supply!) and others simply failed to start at all. All this because they'd not even done their first hour of building a PC, let alone their 10,000th.
Given when I first was messing around with PC hardware (not at all in the days of the 286 to 486, but starting with a Pentium 133-based system) back in 1998 or so, I knew how awkward it was then with the tiny wee jumpers, setting the FSB and clock multipliers manually and such, but these students of varying ages (from 17 to 30) hadn't had that opportunity. Nor created it for themselves.
When it came to a more general knowledge, their lack of general knowledge was what was apparent. For Java programming, the tutor had decide they should use a primitive Java IDE (BlueJay as I recall) rather than Netbeans or Eclipse (why learn the primitive IDE for BlueJay when they're only going to learn something very different later? Self-sabotage much!), open-source software (including OpenOffice), 3D Buzz's free VTM series (which I knew of since UT2k3 and the first "Make Something Unreal Contest") or that the Dummies books are good place to start for *anyone* (including me). And none of them knew of Gamasutra and although I did pass the knowledge on, they simply weren't interested (either because of me and/or resentment or whatever). So all those post-mortems, GDC videos talking about development (especially interesting from a programming perspective if nothing else) etc were all ignored by them.
And all because they hadn't put in that investment that I had done and what William, above, is doing. As a hobbyist and/or serious enthusiast, you'll put hours into learning and acquiring a general knowledge with optionally some specialisation. There will be gaps to be sure, but only because you didn't require to learn them (although some book/video learning is always advised in my opinion) just like I did, whereas these students - and no doubt many more - never bothered and never learned prior, nor on the course, the tools needed to break a problem down and tackle it independently and by themselves at that.
Which brings be back to your post Phil, by the time your students get to you and you give them a rather open-ended brief, its akin to saying to an artist "here's a piece of A4, you have to use pencils and a rubber and it has to be abstract - now go draw something!", albeit a lot more complicated. I say that because these students will more than likely just play treble-A titles (or even single-A for that matter) which usually uses something like the Unreal engine. Few will think of Unity, Torque or even a game maker-type program for that matter. Even fewer will think to pick up a book or two on building a 3D game engine.
This bit here most of us will know, but knowing the education system like I do and students for that matter, it requires mentioning. Because building a game solo requires the student to be able to draw both concept and reference art, build geometry (be it characters through to static meshes) and skin that geometry (so Photoshop and UV unwrapping skills), design levels (which ties back in with drawing and building geometry) and possibly learning the programming language inherent in the middleware they choose. This is before sound effects and music come along. I'm willing to bet 50p that is what is going through your student's respective heads. That and their, again respective, brains each instantaneously turning into a mushroom cloud... ;)
And I find that's the problem - too many skills to know and practice and a combination of lacklustre tutors, students and material combined are dragging everyone who (at the very least) is decent down with them. But instead, I find for the most part (keyword there, "most", not "all") that tutors and education establishments do is slightly paraphrase the "Charlie Sheen maneuver" (as in "we've already got your money dude...").
And also drilling into them that programmer art is better than not having any art at all! But then, its that connection, I found that there is an animosity of "us vs them" with those who are in design (usually on Macs to sour it further) vs those who are programming rather than uniting them (as has been famously done at Carnegie Mellon).
Now I must apologise as this has become a big rant, it is something I'm passionate about but still. One final point, is that you're right that companies should allow programmers to build little projects of their own every now and then. A point brought up in the RSA animation about drive and motivation in the workplace (which you may have seen already, but for reference: http://www.youtube.com/watch?v=u6XAPnuFjJc - enjoy!).
And thank you for a very well written article.
I was at GarageGames fostering indie game developers on the publishing side and saw this phenomena a lot. Talented developers - with teams and tech even - would stall or put off projects because they were always waiting for some external force to align just right to enable them frictionless development. Fuck that. You want to make the most awesome form of entertainment in the world (games) you gotta jump in and get all kinds of dirty and wet. You will probably even go cold or hungry. You will definitely go unappreciated or under-appreciated. I was one of the few indies at that time that cut through all red tape to get my game done and published (Shelled Online, published by Cherry Credits) and didn't understand why for every one project finished a hundred were abandoned, death by excuses. I figured I had tenaciousness they didn't and I think it's THAT aspect that should be taught to students - that making games is hard, long, often unrewarding work (in terms of profit, audience size, and critical acclaim), but if you love it you'll stick with it and see your game to completion at all costs, and that is the self-actualized reward in and of itself. The cynic in me says this is a form of Darwinism and it's not something to be turned around but rather a natural force to separate out the wanna-bes from the real deal.
"If you don’t want to work hard, there is somebody out there that is working hard at becoming great, and they will take your place." - Jeff Tunnell (on the 10,000 hours concept)
Teach your students that quote, strike fear in them for the competition over the jobs they want, and help them find their internal drive to make great games that millions may play and love. I got to have that experience and it was years of sacrifice in other areas of life balance but I wouldn't have had it any other way.
Even if you work some stuff at nights or weekends, life has chores, illness, unexpected situations and such. Those 10.000 hours are hard to get because they must be spent explicitly in the thing you want to become an actual expert at, and the day just have 24 hours, with just so many other things to do. Assuming you already know what do you want to become expert at.