Before I get going, you might wonder why I’d want to help you with this, particularly as I have no clue who you are. Perhaps I’m incredibly altruistic. Well, maybe sometimes, but today I’m just feeling selfish. Here’s why: I hire people for RTW, and being a hiring manager really, really sucks most of the time – hunting through piles of absolutely terrible CVs for the odd glimmer of hope.
This’ll probably take more than one post, so for today I’m going to focus on what you need to learn if you’re young or inexperienced, perhaps at school or university.
This is obviously just for software jobs, and it’s just my personal take on things. I hope we’re going to get something official up on the RTW website before long, but it will probably end up being slightly different when other points of view are taken into account, and I guess there will be no use of the word bollocks at all. Other companies may have a different approach, although I suspect that the bigger, more ambitious developers will have a lot in common with us. Many of them have excellent advice on their recruitment pages, so look them up. We’re all becoming more and more like mainstream software developers in the way we work and hire, so it’s probably also useful to read online about applying to Google, Microsoft etc (since there are plenty of people talking about this).
What I look for
Here’s what I look for when I’m hiring:
- Can you solve really tough problems?
- Can you do that collaboratively?
- Can you craft great code?
That’s really it. That’s the essence of what we do here. Let’s look at each of these in turn and see what it means in practical terms.
We’re working on some incredibly tough problems. I’m probably not allowed to describe all of them, but it doesn’t take much to imagine the kind of challenges involved in APB: a persistent world with the high availability and fault tolerant characteristics you’d expect of an online service, security concerns of keeping hackers and cheats at bay, performance challenges of simulating an urban combat environment with hundreds of players and network bandwidth minimisation to save our operating costs from swallowing us. This is just a snapshot of one product.
So you have to get good at solving really tough problems, and there’s no other way than to practise, lots. The sad thing is that your education (whether at school or university) isn’t necessarily doing this for you. If you’re not sure how to go about it, or aren’t sure whether the problems you’re working on are tough enough, you couldn’t go far wrong by trying old Informatics Olympiad problems. Follow the links to each year’s competition site – they (the websites, that is) vary in quality but most have the problems, the test data used, and sample solutions. You don’t need to be getting gold medal scores, but you should be getting some questions done in the time and feel that your ability is approximately up to the challenge.
If you’re still at school, aim to get into a serious, highly-rated computer science degree. If you’re already on a games degree, pick the toughest courses you can: “sound effect recording” might sound cool and will certainly make your life easier right now, but it’s not going to impress me if you chose it over a compilers course, for example.
Student projects are tricky ground. They’re obviously a great opportunity to work on a problem in depth and prove you can solve something tough. But they’re not the ideal way to get good (lots of smaller problems is far better), and you have to be careful not to be over-ambitious, particularly in the breadth of the problem. You just don’t have time to cover breadth – go for depth instead.
This is the people skills part, often called “communication skills”, but I hate that over-used term. It really comes down to two things: can you get someone else to understand your ideas, and can you understand theirs? It’s harder than it sounds, particularly when you realise that programmers are not the majority in a modern game team. For example, you’re going to have to be able to explain to an artist why their work is causing the game to run slowly, and how they can fix it, and conversely, you’re going to have to understand their usability requirements for the tool you’re writing, or how their aesthetic goals affect your graphics code. Even programmer to programmer can be difficult enough.
Again, practice, and lots of it, is the only way – and yet again, your education isn’t necessarily going to give you enough. Writing you can actually practice alone, and is worthwhile that way, although it’s better if you can find someone to review it. Conversations can’t be had alone, so you’re going to need to find other students. If you can, enter Dare to be Digital, but whether or not you do, find other ways to practise too, even if it’s as simple as finding like-minded people to discuss technical topics with, or trying to explain something technical to your parents!
Programming gets compared to lots of things: engineering, art, and craft. I think it can be like all three at times, and yet still be different – it’s its own thing – but craft is definitely closest for me. This is the constructive part of our work, where we actually build stuff. It’s where we pour our hearts and minds into our work, call on all our experience, and apply taste and good judgement.
Out of all these three areas, I think this is the hardest part for students to get good at: problem-solving is a raw ability and can be present at a young age, and you practise your people skills all the time without realising it. Writing great code requires you to have lots of experience writing code, including the experience of living with your mistakes on big projects. Peter Norvig reckons it should take ten years to get good (he also has some good advice on how to go about it).
Because I understand this, I’m not going to judge your code too harshly (I shudder when I see code when I wrote at 21 😦 ), but that doesn’t mean you shouldn’t try. If it’s just a matter of experience, shouldn’t you just write as much code as you possibly can? Careful! If this practice isn’t carefully directed, you could just be wasting a lot of time. You might eventually get good at carpentry by just building as much wooden stuff as you possibly can, but someone learning as an apprentice is going to be many times better in a fraction of the time.
So here are my top tips for getting direction and guidance:
- Don’t worry too much about getting guidance specifically on games programming. Great code is great code, and statistically speaking, the best programmers are most likely to not be games programmers.
- Read classic books. I’ll try to put together a reading list soon. As above, beware books about games programming.
- Read the best software writing online. Joel Spolsky has a great site, and also collates books called “The best software writing”, which should generate some more leads for you 🙂
- Be multilingual. Learning different programming languages will teach you substantially different ways of thinking about problems and expose you to different styles of programming. Don’t learn closely-related languages when you could be learning something very different. Pick one of Java, C/C++ and C#, one of Ruby and Python, one of Haskell and ML, one of Lisp and Scheme, and so on. Lua is highly popular in games.
- If you have time, contributing to an open source project is your best chance to work on a big project. It doesn’t have to be game-related.
- Discuss code with other programmers and learn to be critical. Don’t make any assumptions about code being good based on who wrote it – make your own mind up. Some of the main game tutorial sites online contain some pretty awful code, and student projects often end up resembling them closely. I’m not sure whether students just copy them out of expediency, or whether they actually see these sites as authoritative, but you should be able to do better.
- Get a summer placement / internship if you can. If you can’t get one in games, don’t give up – apply for anything involving programming.
Just add passion
Your average game developer job advert says “must have a passion for games”. Bollocks to that! That used to be valid, and still is in smaller companies where every programmer has a creative impact on the fun of the game. It’s also used in some places as a euphemism for “must be willing to work overtime for no pay out of love of the job”. But for big, modern teams, there are so many places to specialise that have nothing to do with gameplay: tools, databases, networking, and many more, so if they do still use this phrase, it’s probably just a tired cliche.
I see so many applicants go on about how much they love games, with absolutely no indication that they’re particularly good at, or motivated by, programming itself. This is the central tragedy of game jobs and game degrees: so many people want to do them for the wrong reasons. So feel free to have your passion for games – I welcome it – but make sure you’re just as passionate about programming and solving technical problems. That’s what you’re going to be doing all day.