10 things you should know about … programmers

The stories we live over the course of our careers shape the way we see each other and affect our work together. ‘10 things you should know about ...’ is a series prepared with game developers to share what we feel and hide from each other as we collaborate on a game. Agree, disagree, share and add your own to complete the picture.

Read previous posts about artists, designers, leads and producers.

1- Often our work will involve thinking deeply about complicated systems. It can take quite a while to get everything we need in place in our minds, so please don't interrupt unless it's important; after the interruption it may take 20 minutes to get back to where we were again.

2- Just because it was easy for coders to add a feature in game X, doesn't mean it will be easy in game Y because internally they will both be built completely differently.

3- There is always a cost to doing something quickly: it will create 'technical debt' because of the shortcuts we had to take. If we object it’s because in the past we’ve been asked to fix a problem we wouldn’t have had if we had done things correctly the first time around.

4- Expect initial time estimates to be wrong and ask for updates mid task.

5- Once I start a task I’m not going to want to stop until it’s done, no matter how long it takes, so I need to be told.

6- Nothing takes 5 minutes. Nothing. Don’t be fooled by promises of simple solutions.

7- If I come across as black and white in my thoughts, it’s because I have simplified probabilities into logic so that decisions can be made.

8- If I don't implement exactly what you want, it is a communication issue. I choose to disambiguate things in the way which is best for me - if you want something done a specific way, you will need to give specific success criteria.

9- We are not always good at asking for help. It helps when the management team can recognize when we are struggling to facilitate a discussion. 

10- Just because I am a programmer does not mean that I know how to do all the other technical things that a project requires.

Written with the contribution of Tim Aidley, Jordan Ault, Dave Hollingbery, Mark Lintott, Kim Russell, Rik Skews, Chris Solarski, Will Sykes, Sean Turner and others who wish to remain anonymous.