The Role of a Generalist

Recently I was part of a group asked about the role of a Generalist in making video games.

This one is a toughie. At this stage of our industrys development a generalist is often not what is required as an obvious hire (besides the TD) – most often teams see a specific need for a specific discipline when hiring – “We need an AI guy” or “We need a shader writer”. You never hear them cry “We need a generalist”.

So, given that, why not? The first thing is to define what a generalist actually is.
A generalist is someone who can go anywhere in the code base and implement something, working with the domain expert in that area or by researching and designing said system. Now it’s not reasonable to expect that they would produce something to the same quality /speed as a domain expert, but it *is* reasonable to expect that they can produce something that will work and satisfy requirements (assuming the requirements aren’t something only a domain expert can satisfy).

So, it would be reasonable to expect a generalist to be able to build you a pathing system, even if he’s never done it before, or only worked on someone elses briefly. Will it be as fully featured as a domain experts? No. Will be as fast as a domain experts? No. But it will do the job and allow you to move forward.

Another definition of a generalist is someone who can go anywhere in the code base and get traction on a bug there. Something extremely useful when hitting beta, I’m sure you’ll agree.

Now the argument “well, I don’t want a pathing system thats just adequate, I want a pathing system thats great” is the one most often thrown up against the generalist ideal. And rightly so – this is a valid argument.

But, and this is the crucial bit – most development houses are not going to be able to attract domain experts in every part of video game code generation, nor should they be wanting to.

When building a game generally you need to identify certain area’s of risk, and certain area’s where you need to have at least X level of competence – you’ll need domain experts for those area’s.

However, for the rest of the code – all the bits that aren’t so critical – a generalist can serve you well since they can go write the memory manager, then go write the input system, then go write the save game system, then go write the lip synch system, then go implement the rudimentary animation system that your game design asks for.

They go all over the place filling in where you don’t have / don’t need domain excellence.

Now does that mean that generalists don’t have any domain specific knowledge? Usually they do – My three area’s where I have specialized domain knowledge are animation systems, scripting systems and the build process / tools. But that doesn’t mean I can’t (and won’t) be out of my comfort zone if I am asked to go optimize some shaders as well – I’m more than capable of that.

Generally generalists (see what I did there?) have more breadth than depth, excepting a couple of specific areas. Domain specialists tend to know their domain extremely well, but are generally clueless and out of their comfort area when taken out of it.

The other thing generalists bring the to table is the ability to see how all the pieces fit together. Rather than just knowing how to make the AI as clever as possible, they see how the AI system can use some of the terrain systems functionality, since they were just in there fixing something. They get to see potential reuse and coupling of systems to make everything play nice together which domain specialists often can’t (and shouldn’t have to) see.

They often are a great sounding board for domain experts to use as well – “Hey, I was thinking I could make this system much faster if I…” “Hmm, yeah that would work, but be aware that system X uses that array too, so if you reorganise it, you’ll have to refactor system X’s use too”.

And lastly, as has been mentioned, they are AWESOME bug hunters.

The current problem is that because generalists aren’t specialists, their value is more nebulous – they aren’t responsible for any one thing which makes it far harder to define their value at hiring time.

Yet, we as an industry insist our TD’s and lead programmers are generalists, but we don’t give them any method to gain the experience necessary to actually become one.

The need and value of a generalist is something that individuals come to after experience of shipping product a few times. Until then, the value just isn’t seen up front (along with automated testing, correct technical design documentation and so on) because it isn’t obvious and requires experience to understand why it’s valuable.

It’s a hard life for us generalists. But we are the oil on which a development team runs.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>