Old Dogs New Tricks

This page started out in 'MostGamesProgrammersDontGrokObjectOrientation'. The thesis moved to here is that older people (and here we are talking age 40++ :-)' have difficulty learning new skills. Or maybe they have less reason to do so?? The more interesting questions arising are how to bring about organizational changes that go with Xp and object-oriented programming, as the older people may run the company...

A 40-year-old assembly coder often doesn't want to extend his skill set, but if he's running the company he's denying his junior staff the ability to extend theirs in a professional capacity. This happens a lot in the games industry.

Here's some factors involved:

Most senior games programmers have been doing the job for a long, long time. They started out when you HAD to use LOTS of assembler in order to get the necessary speed, and got into the habit of squeezing every last drop of speed and memory out of the machine, sometimes finding bits of both of those things in the strangest of places.
Games also used to be pretty small things. Consider the classic arcade games (invaders, pacman, etc) - these are small enough that you can 'get away' with structural murder :}
Times have changed, and the complexity of games has skyrocketed; but many of the programmers haven't changed with them. Some don't care, or are just afraid of change, but it's churlish to assume that's the whole reason. Pressure of technological advance takes up much time - for instance, learning the new APIs, new hardware (new 3D graphics cards, new consoles, etc), new rendering techniques, and not just how to use them, but also how to extract maximum speed from them - and game development projects frequently go into schedule slippage and lead to programmers spending huge amounts of overtime trying to Get The Game Out For Christmas. When the game finally ships, learning OO is not the first thing on their minds: Spending time Having A Life again is...

I used to work in the game industry myself, and have been fortunate enough to have worked on large-scale applications as well (large-scale being 70+ engineers, cross-platform, COM development). I have since returned to the game industry, and feel like an idiot every time I mention the words "re-factor" or "design pattern". I am not in a position of authority where I work (I am only 23, and seniority *is* an issue), and am desperately trying to convince people around me to adopt better methodologies. There is a lot of resistance to this among the more "seasoned" engineers that I work with.

Does anyone have any ideas about how to 'trick' crusty old game programmers into re-thinking the way that they work?

My current thinking is to use a baseball bat and lots of threats... -- Matt

Maybe you should call refactoring "optimization" and then they'll listen?

There's also a YoungDogsOldTricks? (or OldTricksYoungDogs?) problem: I've seen several instances where a simple procedural program (or a goto) would be much more efficient and robust than some super-refactored OO program, but recently trained programmers are unwilling to do "old-fashioned" programming. It also astounds me that younger programmers are completely unwilling to look at a disassembly listing or do low-level debugging to try to diagnose performance problems. All generations of programmers can learn from one another. -- KrisJohnson

YoungDogs? need to gain experience to learn from. OldDogs? still need to be able to learn. If you stop being able to learn you cease to be able to adapt. Some YoungDogs? will never learn to adapt. I imagine that this ability has more to do with the individual's ability rather than their age. See LearnFromExperience.

One problem is that employers prefer people who have worked on the same sort of project or technology for years. Employing people with a wide range of experience might be better, as being exposed to a wider field gives you more opportunities for learning. I would prefer to employ people who can adapt - this has little to do with age.

It seems we take 5 steps forward and 4 steps back with each new software engineering technique that comes along. Software development is becoming a lot like the clothing fashion industry where only the young can keep up, or at least convincingly act enthusiastic, upon each new toy that reinvents the wheel in different combinations of old things, or things which are really just subjective preferences.

The IT industry feeds on change. It has a monetary incentive to hype change, otherwise nobody would pay for upgrades. Thus most of the stuff that is pushed on us is dubious or not nearly superior enough to warrent a complete overhaul.

As somebody once said, "40 years of computer science research and experience, and the best we can do is Java?"

CategoryHumanFactors