I’m coming to the end of my year and a bit placement, so I thought I’d mention a few of the more important things I’ve learned in my time at Strawdog Studios.

You’re not expected to know everything.

You will be asked to do things that you have never done before, admitting you don’t know how to do it is not only perfectly fine, it’s also a very good idea as it will help your manager to more accurately estimate the time said task will take you. Learning how to do something is an important skill to have, some-things can’t be found with a quick google search (sacrilege I know) sometimes you will spend hours, days even researching techniques and planning out how you’ll tackle a certain problem.

There’s no such word as can’t.

More childhood advise come back to haunt me. Simply put, you should, given enough time and resources, be able to write code to do almost anything. Often, things that seem impossible turn out not to be, if you just approach them from a slightly different angle. For example you may be working on limited hardware which just doesn’t have the power to render an effect properly, there’s always a way you can fake the effect when you need to, a lot of games programming ends up being black-magic smoke and mirrors thanks to the demands of having to run at 60 or 30 fps.

Don’t get attached to your code.

You are not the code you write, I’ll say it again, you are not the code you write. Code will need to be changed, sometimes your first attempt misses something you later find out, sometimes you’ll discover something that means you have to change code, sometimes the design will change and the problem the code was solving doesn’t exist any more. You can’t take these things personally, everyone has bad days where they write code that on reflection is terrible, learn from the mistakes you make and accept that any code you write may end up never being used.

Sometimes the job will be soul destroying

Personally, I think working in the games industry is the best job in the world, it’s challenging, you get to work with a bunch of fun people who really know there stuff, you get to bring ideas to life, plus everyone else thinks your job is really cool. But sometimes, like any job, there are bad days, days when you spend 8 hours tracking down some small little bug, days when things just don’t work, no matter what you try. I’ve spent days tracking down bugs that only appear in release builds deployed to the device, debugging by displaying a square on screen that changes colour depending on where the code is. These days happen, and you have to power through them, try to relish the challenge and if you can’t, think of it as paying for all the awesome days.

Stand on the shoulders of giants.

Programmers hate to re-invent the wheel, thankfully these days it’s easy to find code snippets to draw on. Most challenges you come across will have been solved before, and probably by people with more resources and expertise than you. It’s important to know that (licences permitting) it’s ok to use these resources, provided of course, that you take the time to understand what the code is doing and how it’s doing it, if you jump ahead and just copy and paste it, the time you save you’ll pay back several times over when it breaks and you have to debug it.

Keep a notebook and pen handy.

This one might not be the same for everyone, but a lot of programmers I know (myself included) swear by it. Sometimes, in order to work out a problem, you need to step back, away from the restraints of the computer and write something down, or make a drawing to plan out your approach, in the course of my years placement I’ve filled at-least 3 notebooks and numerous sheets of paper with plans, sketches and equations that are not only helpful at the time, but are good to look back over if you need to fix previously written code, can you remember what you were thinking 2-3 months ago? No, me either.

Ask for help when you need it.

No-one will think bad of you for it, most programmers like explaining things, and as stated previously, you’re not expected to know everything. Books and internet resources are useful, but nothing can replace talking to someone who knows what they’re on about, or running a theory past someone else to get a different angle, and remember, someday you’ll be the person with the expert knowledge in some area with someone asking you for advice.

Learn when to stop.

When I was at uni, pretty much all I did all day every day was code, any time I wasn’t coding, I was thinking about it. This had it’s up-sides, uni is hard, and there’s a lot of work to be done, so there’s not much room for down-time anyway. But at work, it’s different, true the work is hard, and there’s still lots of it but you’re there for longer, day-in and day-out, you have to be able to switch off sometimes, enjoy time away from programming, away from a computer in general if you can. I think that working at Strawdog studios really helped me learn this lesson, unlike other studios we rarely do over-time and everyone understands the need to have down-time, otherwise you’ll just end up burning out, your fun job will turn into a chore and that’s just no way to live your life.

Obviously everyone will have different experiences when it comes time to work in the industry, but hopefully these will help some of you just starting out adjust better, and maybe make the experience a little less daunting. If you feel I’ve missed an important lesson you learned please leave a comment.

This entry was posted on Thursday, September 3rd, 2009 at 12:33 am and is filed under Articles. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.