As a principal client engineer at Mediatonic – yes, the same Mediatonic that developed Fall Guys, the non-violent battle royale that's taking the world by storm – Kieran Nee doesn't even really remember the exact title of the subject on his degree certificate.
But when it comes to his day-to-day, Nee says he's a "walking, talking stack overflow" with excellent communication and problem-solving skills. We sat down with Keiran to find out exactly what skills game makers are looking for right now when recruiting video games programmers.
What's your job, and what does it entail on a day-to-day basis?
My job is basically organising other programmers to make the game. That also entails me working with other departments. I spend most of my time talking with production, art, design, QA, and technical art, and trying to work out everything that we need to make the game, and making sure that everyone on all our team, and right across the project, have all the resources they need. [Answering] all the questions they need answered, and trying to unblock them and let them get on with their work.
What qualifications do you have?
I did a BSc Hons at St Andrews. I can't remember the exact title – I think it was just computing? – but basically software engineering, followed by a post-graduate diploma in Abertay, specifically in games programming.
What's the difference between an engineer and a programmer?
Realistically, there is not much of a difference. It's kind of a terminology thing. It's also just about how you approach problems. From my point of view, an engineer is looking to architect the system to work. A programmer is writing a bit of code to do something. Realistically, what it actually boils down to – I got this from a friend at my university, and I hate admitting this – is engineer sounds better.
What are the common misconceptions around programming?
I'd say the biggest misconception – particularly for graduates who are in programming – is that you're going to be coming in and making the game. Sorry, folks.
You learn how we make a game. And even between that game and the next game will change how we make the game. Pretty much every game is different. So the things that we are teaching grads are generally how to make a game, or approach how to make more games. Problem-solving is the key thing, and we're just making sure that people know how to solve problems the ways that'll help us make the games we want to make.
What languages should aspiring programmers prioritise learning?
Unity, Unreal, C# and C++. They are still the core languages that most of the games in the world right now are made in. C++ is what I cut my teeth on. It's not going away any time soon. It's probably the biggest language in the world.
C# and Unity let you get a lot of gameplay made fast and in relatively safe ways. C++ lets you do everything [although] it is so easy to get things wrong. But if you're making mistakes on a personal project, who cares? It's a little bit of time wasted. Get it out of the way. Learn how to make things in those two core languages, and you're going to be good. I'd also take a look at things like Python, a little bit of Java. They're very, very useful just for everything else, and for teaching you how to work in other languages.
Would you say it's better to have an average or a limited understanding of several languages than it is to specialise in one or two?
I would definitely say that it is better to know a little about a lot, instead of specialising early. I've been an AI coder, UI coder, I've worked on mobile. All of those were very different experiences and different skill sets, and often different languages. So the breadth really helped, because it let me decide what I was more interested in.
At times, I actually really like making buttons on a screen. UI is great because it's the first thing people touch, it's great. But I only got there by being willing to touch everything. And also being willing to turn your hands to everything – that's the important thing.
What other complementary skillsets could people look at bolstering to improve their chances?
You've got to be able to talk to other people and actually listen to what they're saying. Everybody assumes engineering's writing code all the time. I write code quite rarely nowadays. I always try to write more, but most of my job is communication. It's communicating from one group to another and making sure that people have the right information to do their job. Especially [during the pandemic].
What should aspiring programmers do after university to kick start a career in programming?
The best thing aspiring programmers can do after university is make games. One of the key things that we do when we look at your CV is look at your portfolio. Explain what you did, and the problems you solved, and what you found interesting about it. Then we can get an insight into if you really do want to make games, or you just think they're cool. But also how you approached the problem.
And that's the most important thing for me. When I'm hiring an engineer, I want to know you can solve problems. If you can solve problems, you can make games. Everything in games is a problem.
And what should people who didn't go to university do to improve their chances of landing a programming job?
It's very, very similar to if you did go to university, to be honest. You've got to make games. If you have examples of your work you can show to us and talk to us intelligently about, I honestly don't care so much about degrees. I can't remember what my first degree was. I remember where I did it, I remembered what I got, but I can't remember the title.
So I would say to anyone that didn't go to university that wants to make games, it's the exact same advice I give to somebody who did go to university: you've got to make games.
What aspects of your job do you think would surprise people?
In theory, I'm supposed to be the technical supremo on the project: the best engineer or the most knowledgeable. And in practice, that's rubbish. It's absolute rubbish. What I am – and what I found that most good leads and most principal client engineers are – is a broadly knowledgeable generalist with experience.
I'm basically a walking, talking stack overflow. I'm Google. People mention terms, and I point them in the right direction. And then act as a sounding board to help them get to where they need to be. I'd happily point at least three or four of my engineers right now who are better at engineering or programming than I am. Easily. But I enjoy doing what I do. And that's what I'm good at right now.
What's the best part of your job?
People. Putting stuff in front of people and seeing their reactions. People are responding with happiness to something you've spent a large amount of time – and passion and energy – making. And for me, that is by far the best part of making games.
And it comes down to joy. It just is bringing smiles, happiness, joy – any emotion to somebody's life is a blessing. Being able to do that day-to-day and get paid for it is unbelievable. It's a privilege. I'm very aware that we don't save the world; we're not going to solve the energy crisis. But we can make people smile, and I get to do that all day. It's great.
What about the more challenging aspects of your job? Things perhaps you didn't expect when you came into the role?
Interpersonal management is a very difficult problem. If someone's in a bad mood, you don't know why. Are they in a bad mood because something's happened on their project? Because something's gone wrong at home? Is their cat sick? But if you take it out on other people, or it's impacting your ability to do your job, it becomes my responsibility to try and work out.
And it's a very hard thing to train for. I wouldn't say I've ever had enough training to do it because it is a very complicated problem. People aren't easy. And particularly in engineering, we tend to get promoted a lot on the basis of: "Oh, great. You've made the game, and you know what you're talking about when it comes to the tech". People management's a very different thing.
Is there anything we've missed that needs to be said?
You may not be working on the big AAA game that you want to work on. You may not be working on the quirky little, amazingly artistic piece of art. But you can always find something that you can do well, that you can put a smile on the people next to you by doing well, and that you can be proud of.
Barclays (including its employees, Directors and agents) accepts no responsibility and shall have no liability in contract, tort or otherwise to any person in connection with this content or the use of or reliance on any information or data set out in this content unless it expressly agrees otherwise in writing. It does not constitute an offer to sell or buy any security, investment, financial product or service and does not constitute investment, professional, legal or tax advice, or a recommendation with respect to any securities or financial instruments.
The information, statements and opinions contained in this content are of a general nature only and do not take into account your individual circumstances including any laws, policies, procedures or practices you, or your employer or businesses may have or be subject to. Although the statements of fact on this page have been obtained from and are based upon sources that Barclays believes to be reliable, Barclays does not guarantee their accuracy or completeness.