Although I don’t write much code any more, I still think of myself as a programmer; I still have programmer tendencies in everyday life, like trying to “optimise” the world around me. When I was in hospital just last week, I was quietly infuriated when they did the scan before the blood test, forcing me to wait for the lab to analyse the blood. I was going to point out to the nurse how much more efficient it would have been to analyse the blood while I was having the scan; luckily another of my programmer tendencies (avoidance of social interaction) saved her from my grumpiness!
Yes, “we” (programmers) are an odd bunch, and one of the fascinating things about game development is the number of other disciplines that must interact closely with us during development. This post is for you.
Maybe you’re an artist. You might be dependent on programmers to make your tools better, allowing you to work more efficiently; perhaps you need your art to look better, or perhaps you need it compressing so you can fit more in. Never forget: we love you really. If it wasn’t for you, we’d have “art” like this, and we know it:
Of course, it can be a bit of a love/hate relationship at times. You drive us bonkers with your wacky organisation of source assets, mixing multiple logical changes in a single source control check-in, or going over your budgets. I’m sure we inflict just as much frustration in return!
Or maybe you’re a designer of game mechanics – someone who theorises about how the game should work, and requires programmers to implement your concepts. I think you may have one of the toughest jobs on the team. Unlike the artists, your specialism isn’t so obviously expert, because everyone’s an armchair designer with an opinion on your work. But programmers aren’t just everyone. We’re liable to say exactly what we think of a design in a brutally honest way; we may be upset if there’s something even slightly illogical about it, and from time to time, yes, we may appear to imply that we could do your job better than you. I feel guilty just writing about it. Sorry!
Whatever your role on the team, I offer two tips to get the best out of your programmers. As a small disclaimer, I certainly don’t mean to suggest that it’s your problem to make the relationship better – but I hope you find something of use here.
#1 Give me a problem
Programmers live to solve problems: there’s really nothing we love more. We don’t just love finding solutions: we love finding the best, most elegant solution. So there’s nothing we find more infuriating than being handed a solution to a problem and told to go do it – particularly when the request feels inelegant or arduous. We’re going to be immediately suspicious that we’re wasting our energy, that there’s a better way to solve your problem. If you ask a programmer to go do something and they react with doubt, negativity or a grudging manner, this is often why – and they may not even realise it themselves. [As a programmer, it's important to become self-aware in this regard so you can respond with "hey, what are you really trying to achieve with this thing you've just asked me to do?" rather than being grumpy]
I’ve seen some artists achieve a certain degree of success by getting closely involved and specifying very precisely how they’d like their tools to work. That’s fine, but the best artists I’ve known (best in terms of getting what they need from programmers) took the time to explain their job to the programmers: explain the challenges they face, explain what it’s like to be in an artist’s shoes using the software. They always got better results.
Think of it another way: if you just describe a solution without the problem, even if the solution is a brilliant one, a programmer will often struggle to implement it well. A thousand little decisions need to be made when implementing something, and without a good understanding of the problem being solved, these decisions aren’t going to be made well, adding up to a sub-par result.
On the other hand, if you explain the problem first, there’s nothing stopping you from giving solution ideas too. We’ll understand them all the better now they’re in the context of a problem.
#2 Explain why
Sometimes, you simply have to deliver a solution rather than a problem. It’s not practical to go to a programmer with every single problem you come across. If you’re designing game mechanics, your entire job is to come up with a solution (the game mechanics) to a problem (a high-level project vision). Nobody wants to take your job away from you.
When this happens, remember that programmers crave understanding. We need to know the answer to “why?” We can be like a five-year-old-child asking it over and over, just as maddeningly persistent and without the cuteness. Logic rules our world, and to see someone do something illogical is hard for us. So, take the time to explain why you took some of the big decisions. Explain the other roads you considered and why you didn’t take them. It might seem like a lot of effort, it might seem unfair to have to justify your work (after all, we don’t necessarily do a good job of explaining the technical decisions we’re making), but I’m not suggesting you do this simply to keep programmers happy. You should do this because you’ll better results out of them. By understanding why, we can implement your intentions, capture the spirit of your vision – not just the letter of a specification document. We might disagree with your decisions sometimes, but we’ll respect the careful thought you put into them.
I’ve sometimes seen designers write out their designs in minute detail in an attempt to improve how closely the implementation matches their vision. This is generally a big mistake. If you use design documents as part of your process, the best thing you can do to improve them is to explain “why”. Going one step further though, a design document isn’t a great format for explaining the process of reaching the design – so the best thing you can really do is to collaborate closely, involve other disciplines throughout, and iterate.
Universals?
I set out to write a piece about programmers, but I actually think these two tips apply generally to any human being. You don’t go into the doctor’s and tell them what medicine you need; you tell them your symptoms. You don’t do this just to humour the doctor, you do it because they’re experts in the problem domain.
Don’t tell experts what to do; describe the problem you want solving. Separate your goals from your solution ideas.
And you already know that explaining why is important when asking people to do something for you. Think of the trickier requests you make of other people in everyday life … asking a favour, demanding a refund … you know instinctively that explaining “why” improves your chances. A famous experiment by Ellen Langer at Harvard showed that significantly more people let someone skip ahead of them in a photocopier queue when they gave a reason (90% when the word ‘because’ was used in the request, 60% without); the part I don’t like about this is that it can be used as a bit of a trick: the technique worked equally well when the reason given was completely meaningless (“because I need to make some copies”). That’s certainly not what I was suggesting! Apart from the fact that a good programmer would probably see through a bogus reason, always go for methods of influence that are genuine, that leave both parties better off, and that build a good relationship.
Explain ‘why’ to give people motivation and a context to what they’re doing.
