Richard May from Rebellion tells us a bit about his role as a lead programmer at the UK studio

What is your job? What does it involve?

My title is lead programmer, but essentially I’m in overall charge of the technical side of a game project. I work with the other discipline leads (design, art, sound, etc.) as well as the game’s producer and our in-house engine team to ensure that the necessary tools and gameplay features are implemented in time and within budget. It involves quite a lot of people-management and scheduling. I’m also lucky enough to write code occasionally, something I still enjoy.

What are your main responsibilities?

I work with my team to make sure the designers, artists, animators, GUI designers, etc. have the tools they need to do their jobs. I oversee the technical design of gameplay features and project-specific tools, ensuring they can be built in the time available and will do the job we need them to. It’s also my job to make sure the game runs at an acceptable framerate on all hardware and is as bug-free as possible.

How did you get your job?

I started in the industry as a junior programmer, fresh from university, and worked up from there. After a short period at Codemasters on their graduate scheme, I moved to Rebellion and worked on Game Boy Advance games for a year. The company grew around me and I gradually moved from GBA to console, working as a gameplay programmer on a number of titles. Rebellion as a company has always had multiple titles in development at any one time and the growth of the company meant that there were more projects than there were leads. Having proven myself on previous projects, I was encouraged to take on the role of lead and the rest is history.

What special skills or qualifications did you need?

I did a BSc in Computer Science at university which gave me a good grounding in the basics of programming and C++. The vast majority of programming in the games industry is C++ so that was key to getting a foot in the door. Unlike many in the industry, I didn’t grow up programming in my spare time and for years I assumed that would be a barrier. In the end, a steady, methodical approach to problem-solving and a willingness to learn proved more important than knowing the ins and outs of every piece of hardware and programming language.

What new skills have you had to learn for this role?

I’ve learned huge amounts over the years but the main skill I’ve had to learn as a lead is people and time management. Despite the title, being a lead programmer doesn’t actually involve much programming – the larger the programming team, the less you tend to do. Rather, you need to know how to get the best out of the people you’re managing.

You need to be able to take the other disciplines’ (often quite abstract) requirements and turn them into something achievable. Experience as a games programmer is invaluable here as it gives you a good idea of what can be done and how quickly. Positivity is also important – it’s very easy to say no to new ideas or feature requests out of hand because of the additional work required. Sometimes you have to, but usually there’s a way to make it happen. Games are constantly evolving during production and the design’s requirements can change hugely over the course of a project. It can often seem like the goal posts are constantly shifting, so it’s important not to get frustrated and remain approachable. At the end of the day, you’re there to facilitate the designers and artists, not create some perfect edifice of code.

Describe a normal day. What do you do?

It depends a lot on the phase of the project. In the early days, the pre-production phase, I spend a lot of time in meetings with the producers and the leads from the other disciplines, trying to get a handle on the requirements of the project and what new systems need to be implemented. Later in the life cycle I’ll be scheduling my programmers, checking the quality of the completed work and ensuring there are no bottlenecks. Towards the end, around the “pre-alpha” phase, QA will start to test the game in anger, so to speak, and the work shifts again. Now it becomes more about triaging the bugs as they come in, assigning them to the relevant coders and prioritising things to make sure the game comes in on time.

I also try to find time to play the game we’re making. That may seem obvious, but it’s often difficult to do given all the other demands on my time!

What are the best and worst parts of your role?

There’s no worse feeling than the combination of a tight deadline and an intractable bug, something that you just can’t find, no matter what you do. When things don’t work it’s both demoralising and infuriating, but you have to knuckle down and keep plugging away. Often it won’t be you doing the work and keeping your team motivated can be the hardest part. Trust in your team, encourage an analytical and methodical approach and you’ll get through it.

The greatest joy is seeing something you worked on come to life. When it all works, when it does something that surprises you, it’s a brilliant feeling. There’s also nothing better than hearing from fans who love what you’ve made – so often, you can be too close to a project to see how good what you’ve made actually is. Seeing the positive reactions of the players is incredibly energising and inspiring.

What tips would you give to someone applying for a similar position?

You don’t need to be the greatest programmer in the world to be a lead. You need to be competent, obviously, but being able to build good relationships with your team is at least as important, if not more so. Be organised, show that you know how to schedule work and that you can talk to others around you. Be prepared to admit you don’t know something – no one knows everything – and knowing who to ask is almost as valuable.