Gaming has come a long way since the days it was seen as frivolous fun. Nowadays, it's a massive industry that's attracting serious scientific interest. Nevertheless, in my profession — software development — gaming still isn't widely seen as something directly useful to my job. Reading Justin Worthe's excellent article on how programming games inspired his software development made me realise that playing games has helped mine. Here's how.
Playing games gets me addicted to 'Flow'
What is Flow?
Flow, in short, is a state of total concentration on the task at hand. It happens when my skill at a task is perfectly aligned with the challenge presented by that task. If I'm highly skilled and a task isn't challenging enough, I become bored. If I'm a novice and the task is too difficult, I become anxious. When there's a balance between my skill and the challenge, however, I enter that magical state where I can concentrate for hours, losing track of time and of my surroundings.
According to its progenitor, Prof. Csikzentmihalyi (that's "chick-sent-mi-hai" to those of you whose Hungarian is as rusty as mine), we are at our very happiest when we are in a Flow state. Good game designers know this and try to make games that elicit a sense of Flow. That sense of total absorption is a core component of the experience and the enjoyment of playing games. Anyone who has ever sat down in the evening to play "just an hour" of their favorite game, only to be snuck up upon by the sunrise, knows this feeling. I'm looking at you, Civilization!
Games allow me to maintain my state of Flow by giving me control over the skill-challenge balance. If the game is getting boring, I can switch to a higher difficulty level. If the game is unenjoyable because I keep failing, I could lower the difficulty or try a different combination of weapons or spells. In a multiplayer game, I could identify the skill I'm lacking and practice it against automated bots, or maybe even overcome the obstacle with with a friend in co-operative mode.
How Flow helps me in software development
Flow while programming is no different to Flow while gaming. I'm sure that almost every programmer knows the magic of uninterrupted, hours-long stretches of coding. You know what you need to accomplish but it isn't a boring or repetitive task. You're familiar enough with the tools that you're using so that you don't have to think about them. You can just focus, not noticing things like temperature, hunger, or the passage of time. When you emerge, you feel as though you've been productive. You're satisfied and happy. That's Flow.
As a person who plays games, I'm frequently exposed to this state. I know what it feels like. This has helped me as a developer in two important ways: First, I know how pleasurable Flow is, so I can actively seek to achieve and maintain it. I know that when I'm in Flow, I'm at my happiest and my most productive. This means that finding Flow is a win for both me and my team, so I know I need to find it. Second, when I realise I'm not in Flow, I can try to figure out why it's missing. I can do something about it — just as I would in a game:
If I get bored while working on a task, then maybe it is too easy. This usually happens when I'm doing something very repetitive. In this case, I ask myself: should I "turn up the difficulty" by automating this task? Developing an automation is a lot more challenging. It also happens to be very useful to my job: If I get the automation right, nobody, myself included, has to spend valuable time on that boring task any more.
If I'm stressed or anxious while doing a task, the task is too hard. This is the one I encounter more frequently in programming. It means that I should "lower the difficulty". To do this, I ask myself:
- Is there a "a different combination of weapons or spells" — a better method or a more suitable tool — that I should be using to accomplish this task?
- Is there a specific skill that I need to "practice in single-player" — setting time aside to develop it — before I return to the task?
- Does the task require me to go into "co-op mode with a friend" by opting for pair programming with someone more experienced?
Playing games teaches me useful behaviours
All games reward players for doing certain things. While the specific behaviours that get rewarded, as well as the rewards themselves, vary by game genre, there are a couple of common ones:
1. Curiosity
Open-world role-playing games such as The Witcher or Skyrim are particularly good at rewarding players for being curious and for exploring. In The Witcher, for example, I'm lured far off the beaten path by question mark icons on the map, and receive various riches for reaching the marked locations.
These sorts of incentives are especially useful when I arrive in a new area. They encourage me to explore, find out where things are, and get the lay of the land. I also learn that the most obvious route is not always the best one. Rather than rushing straight to the finish line, I'm enticed into caves and up mountains. For who knows what I might find there! A bag of gold? A flaming sword? A rare mineral? Though sometimes, it turns out just to be some unpleasant, forgotten ruins!
The same applies to software development. Whether it's a programming language I haven't used before, getting put on a new project with an unfamiliar codebase, or getting access to a new server, exploring can be very helpful. In all of these cases, being curious and having a look around before I get started with the "main quest" helps me get a sense of where everything is and why, which can only help me in the long run. I may even find things that others hadn't noticed or were long forgotten about: an important "TODO" that was never done or a huge, mysterious, hidden ZIP file that really shouldn't be included in those nightly backups. I'll likely end up encountering a bunch of "unpleasant, forgotten ruins", too — but that's all part of "the game".
TIP: Keep in mind that in the real world, your "main quest" — your project — can't just be left unfinished in your Steam library without consequence. Spend time exploring, but be sure to time-box it sensibly!
2. Persistence
The stakes in most games are never much higher than just having to wait for a few seconds to respawn at a previous checkpoint. I'm taught that my failures are temporary, and my successes are permanent.
I'm also taught that no task is insurmountable: if I ever get stuck, I just need to keep trying. I know that I'll get a little bit better every time, until I can overcome whatever obstacle, or defeat whatever monster, has been put in front of me. And when I finally do, I feel that awesome sense of accomplishment: a much greater reward than whatever trinkets the slain monster drops in the game. The Dark Souls games, which are very challenging compared to most modern games, rely heavily on this reward: the feeling we get after overcoming a challenge. One way of looking at it is that people enjoy games like Dark Souls precisely because they are hard. I think the real reason is because the difficulty gives you the feeling that your victory is earned.
I don't think I have ever won a single "boss fight" in any game on the first try. Rather, I'm repeatedly dashed against the rocks, maimed, and eviscerated. Each time, though, I get a little bit further and start to see the patterns in the monster's behaviour, until I'm finally able to get the upper hand. This thought pattern is useful for my job, because at some point in my programming career, I will encounter bugs of "boss-fight" proportions. The strategy and attitude required to squash them is the same: try, try again, getting a little closer each time.
TIP: When you hit a hard problem, think of it as a "boss fight" in a game and put yourself in that same mindset. Remember that a bit of time and effort is all that separates you from your solution. Don't give up. Rather, when the going gets tough, motivate yourself by looking forward to your well-earned victory.
3. An Inclination Towards Teamwork
Multiplayer games orientate players towards working together. Sometimes this is explicit: In Heroes of the Storm, for example, you earn more experience for the same outcomes when you are playing with friends than when you are playing alone. More importantly, games teach me that there are implicit rewards to teamwork. Chief among them is an increased chance of success. The more effort I put into working together — identifying goals, deciding who should be doing what, allocating resources, and communicating — the greater this chance of success becomes.
In DOTA and related games, the strengths and weaknesses of each player on the team dictate not only what character they should play as, but how they should spend their time and individual resources during the course of a game. Each player has an individual goal: the 'tank', a tough character, attempts to protect weaker characters; the 'healer' focuses on keeping everyone else on the team alive; the 'carry' focusses on destroying the enemy. These individual goals are aligned toward the ultimate goal of winning the game. Clear communication is essential for making these strategic decisions before a game begins. So are the myriad tactical decisions that occur during the game, such as coordinating a surprise attack.
The success of a software project is similarly dependent on teamwork. Rather than trying to destroy the enemy's "Ancient", there is a deadline coming up. Rather than needing a "tank", a "healer", and a "damage dealer", you need a front-end guy, an ops guy, and a backend guy. Trade teamspeak for Skype, and in-game chat for Slack. Teamwork is teamwork — and multiplayer games can help a person practice many of the skills that comprise it.
TIP: Often, teamwork in games falls apart because some of the roles are seen as less glamorous than others — everybody wants to play as the "carry"! The same thing can happen in a software dev team. If everyone is "chief data scientist", you probably won't end up with a finished product, which is the ultimate goal. You should always keep in mind that the needs of the team should come before the needs of our egos.
Playing games teaches me how to grasp abstract systems
The primary purpose of playing games is to have fun. But before I can really start having fun, I have to learn how to play the game. Every time I pick up a new game, I want to learn how to play it as quickly as possible so that I can really get into the meat of it. This always involves learning how to navigate a UI, learning some set of controls, and some set of rules. Every video game is a complex, abstract system with which I must familiarise myself before I can enjoy it.
Sometimes this is a very simple task. In Super Hexagon, for example, you only use two buttons to not crash into things. More often, there is a lot more to come to grips with. In Elite: Dangerous, you begin the game sitting in a spaceship with basically no instructions or objectives. Looking directly ahead, there are about 9 components to the Heads-Up Display, showing you about 30 different pieces of information. On the left, a navigation panel with five screens of more information, and on the right, a systems panel with 5 screens of more information and controls. That is a lot to take in, especially while trying to figure out how to maneuver a 25-ton vehicle with six degrees of freedom! Good luck — and try not to hit the sides of the space station on your way out!
Playing games means that I'm putting myself in situations similar to this fairly regularly. If these are the sort of mental gymnastics I do for fun in my free time, then familiarising myself with a new codebase suddenly seems a lot less hard. The codebase doesn't even come with the guy over there in a bigger spaceship bristling with lasers, who wants to take whatever is in my cargo hold!
A codebase and the tools I use to interact with it, in other words, are also a complex, abstract system: a bunch of controls, views, and interlinked systems and subsystems governed by some set of rules. The quicker I can grasp such a system, the sooner I can be effective within it. Games let me practice this skill in wonderfully unsafe and threatening environments.
Jacob Clarkson is a Junior Data Scientist at Explore-Software.
