I Can't Do This
I Can't Do This
News
Yesterday, The PlayStation Revolution was released, it’s the third movie in the “From Bedrooms to Billions” series, and I am proud to have been a part of it. You can get hold of the movie here.
Tomorrow I’m giving a live talk entitled “Failing With Style” at the Games Industry Investment Summit event. It’s free, and online, and here’s a link.I’ll be live from noon, do join me.
If you haven’t wish listed Floor 13: Deep State, me and the team would appreciate it if you would. You can do so here, and read more about it here.
Now, let’s return to my 5-part series on the lessons I’d like to give the kid who ported Jet Set Willy in 1984, and this one’s about problem solving.
Problem Solving
In my early years making games, my thinking was non-conformist. My mind was more open to possibility, but it was also empty of experience. As for the ideal of a mind being full of experience, yet still open to possibilities not circumscribed by what already exists, I'm still working on that one.
One major issue with inexperience is that not only are you naïve enough to believe that anything is possible, once you hit upon problems, you don't have tools to solve them. This is the border patrol where dilettantes turn back afraid, and professionals go on. Professionalism is an attitude rather than a designation, which means that it's possible to arrive at the border patrol without the right documents, even if you are prepared to be professional. You need to have a lot of these encounters with border patrol before you're admitted into the undiscovered country, and there you will find yourself without a map.
What does this mean? It means that you don't know which problems are solvable and which are not. It means you don't have the knowledge yet, but that's the challenge of programming, that's its core appeal, or at least, it always has been for me, that the machine will perfectly reflect your intent, and that you alone are responsible for communicating your intent clearly. Your intent will not be filtered, or distorted, or second-guessed, or inverted — the machine will do exactly what you tell it. Nothing like modern reality where communication between people is more fraught than ever, with misunderstandings the norm.
Back in 1984, there were many long nights where I wrestled with my fear more than I did the code, but I was nonetheless determined to prevail and knew that if I could get my thinking in order, the game would be in order.
That said, I wish I had not entertained the most poisonous thought of all.. "I can't doo this"
Of course, you might well need to learn or practice before you can do something that seems beyond you, but my personal trainer had a great response when I said I couldn't do something. She simply added the word "Yet!" — so next time you catch yourself saying that you can't do something, just add "yet", because then you're being honest and giving yourself a vision of a better future.
So what lessons would I share about problem-solving with my younger self?
The Easiest Problem is the One You Don’t Solve
First, don't solve problems that don't need solving. Four decades ago, Chris Crawford was working on some AI and found that sometimes units would get stuck, and it would always be around U-shaped lakes. He tried all kinds of techniques to fix this, but in the end, hit upon the most obvious solution of all, just remove all the U-shaped lakes. Simplify, simplify, simplify.
If Someone Can Do It, So Can You
That the game has already been made, means that it can be made again. I mean someone has got Doom running on a pregnancy test kit for crying out loud, so don't worry son, you will get Jet Set Willy running on the Commodore 64. The four-minute mile was considered impossible until Bannister did it and then of course loads of people did it.
Let Go
I learned to swim aged 36, having been terrified of water all my life. The biggest lesson I had to learn was to relax and let the water support me. Relaxation is critical. Where focus is critical in writing good code, in debugging, you don't want focus per se, you want to be both systematic and totally open. Closing your mind means you will miss the obvious.
I'm really good at finding things. It's the closest thing to a superpower I have. I am both totally systematic, and totally open. When I was younger, my approach was more about focus, but narrowed focus means you can miss the obvious.
Swimming, martial arts, playing music, debugging, it's more about flow, openness and relaxed acceptance, with the deep memorisation of practice ensuring that the right technique is deployed in response to the constant awareness of the situation as it is, rather than how you would like it to be. The biggest key to debugging is to see the code like an artist sees her subject, and not in patterns that match the preset filters the mind is trying to impose on the world.
If you don't have this approach, you are vulnerable to flailing, which is exactly what happens when you panic in the water. Flailing is failing.
When an approach isn't working after you think you've tried everything, you must let your rising frustration melt and acknowledge that the approach failed, but you did not. Every attempt at solving a bug is part of a process that leads you closer to your solution. Get curious, not crazy. Crazy is "Oh you've got to be kidding me! How the hell does that not work?" Curious is "Oh how interesting! I wonder what this is leading me to?"
You Need Coaches
I didn't have anyone around me who knew more than me about the job I was doing, and that's something I make sure I have now. For programming, my mentor is Kieran D'Archambaud, who is not just a bona fide code genius, but he has a systematic approach, a superb attitude and curiosity by the bucket load.
On my current project, I'm retaining Kieran as a technical consultant. I could probably do the whole project on my own, and have in fact done nearly all of it, but it would have taken me longer, a lot longer, because the sticking points, while few, are easy for someone like Kieran to solve. Why would I endanger the project by not being able to turn to Kieran when occasion demands? Having a superb mentor like Kieran is a massive time saver, as well as a mental safety net that gives you confidence.
Be careful with your mentors though, in that just because they're brilliant at one thing, that doesn't mean they're brilliant at everything. You don't go to a doctor about getting your car fixed after all. That said, I haven't come across much that Kieran isn't utterly brilliant at.
You Need A Map
My son wanted to know why he should listen to his parents. My mum might have given me a slap for such impertinence, but I told my son that this was a great question. Here's what I said.
"Son, imagine you are at the edge of a jungle filled with treasures. People ahead of you are going in, and very soon you hear them screaming as they're eaten by a tiger or devoured by a snake. Now imagine it's your turn, and you are offered a map. The map won't tell you where the treasure is buried, but it shows you where the lions and snakes are so you can steer clear. Wouldn't you want the map? Parents are like that for the jungle that is life."
Mentors are your map. They won't tell you how to make a great game, but they will help you avoid mistakes that cause the frame rate in your Unity game to stutter because you didn't know how best to work around garbage collection.
Checklist? Check!
Once you have been working in any field for a while, you will have a bunch of repeatable process, like generating a build for your client, or managing protocols around version control, or archiving assets, or a million other things. Make a checklist, and use it. Don't rely on your memory. You don't have a bad memory, but your brain is not designed for that kind of rote nonsense. It's designed for problem solving. That's why we invented writing and checklist apps. Make checklists, use checklists, and until you do, do not pass go, and do not collect £200
If you enjoyed this newsletter, please like, comment, share, subscribe, it means a lot to me.