5 of The Best Board Games for Software Engineers

Board Games are in right now. As droves of consumers are cutting the cord, friends and families are turning to board games to fill their evenings with fun. Board games have seen a surge not only in popularity in the last decade, but also in creativity and depth.

Games from our childhood like Monopoly and Risk have been supplanted by games like Settlers of Catan, and Ticket to Ride. Games that have more depth, replayability, and strategy, without the hours-long slog of just wishing the game would end. But even now, Catan and Ticket to Ride are seen as gateway games to a world of board games that are deeper, more intense, and more fun.

But as software engineers, sometimes games don’t need to only be about fun. They can help us with our craft by honing skills that we can directly apply to real life.

I’d like to introduce you to my top 5 best board games for software engineers.

We’ve got: Dominion, which can teach us about chaining, or order of operations; Fields of Arle, which can challenge our cognitive load and help with branching decision making; RoboRally, which can teach us to plan for, and deal with, possible errors; Tzolk’in, which challenges our ability to plan ahead and manage resources; and social deduction games like Burke’s Gambit, which not only improve deduction skills, but also social skills.

Dominion

Dominion is a deck-building game. Think about games like Magic: The Gathering, except the players build their decks from the same pool of cards, and not from dropping hundreds of dollars on their own collections.

In Dominion, a basic turn consists of playing a card, then buying a card (and adding it to your deck, to be drawn later in the game into your hand). Some cards let you play additional cards, draw additional cards, or buy additional cards.

Dominion illustrates a key skill that software developers need to use: chaining.

I work mostly in Ruby, and chaining methods is a huge part of the language. You send data to one method, and the results of that method are then sent directly into another method. It’s not uncommon to see something like Item.where(color: 'blue').collect { |item| item.name }.uniq.sort.

Where this game differs from programming is regarding the Law of Demeter. In programming, you don’t want to chain too many methods together, because if at any point you encounter an unexpected nil value, the rest of the chain is not only worthless but could potentially throw an error. However, Dominion rewards long chains.

Since the basic turn is one action, and one buy, you want to augment your deck with cards that increase your potential to act or buy. But like programming, you need to be careful about the order you play the cards in. You need to play your cards that grant additional actions first, or you can’t play the extra cards that grant you additional buying power. Some cards let you draw more cards. So you might play a card that gives you +2 actions, then use the first extra action to Draw +3 cards. If any of those new cards grant you more actions, you’ll want to play those. Or, if you want to buy more cards, you might want to draw as many extra cards as possible and hope for more money to be used on your buying phase.

The game lends itself to a lot of strategy centered around the correct order of chaining different cards. And just like programming, you need to make sure you chain things in the way that you can still reach the elements later in the chain, and not suffer an unexpected crash in the middle.

Fields of Arle

Fields of Arle is a two-player worker placement game. The worker action area is divided into two seasons, Summer and Winter. Most actions on one side of the board require resources from actions on the opposite side. The game only lasts for 4.5 rounds, so planning where to send your workers in one season in order to collect resources for spaces where you want to send your workers next season can be a very difficult proposition.

There are so many decision branches because of the nature of the board set up, that it can be hard to hold all the required actions you need to complete a goal in your head. There might be something you want to buy in the summer, which requires 3 resources you can only get in the winter, but those 3 resources require a mix of 5 resources you can only get in the summer, and you might only have 4 workers. So now you’re planning on resource collection for the next two summer rounds, to be able to purchase something in the second winter round, to fulfill a coring goal in the third summer round. All while still trying to complete other goals requiring other resources.

Studies in the field of cognitive psychology have shown that the human brain has a limit in its potential Cognitive Load. Basically, your brain can only handle so much data and decision making at one time before it starts to impede performance. Chess is another good example of this. A novice might only be able to see a few moves ahead because the cognitive load required to process all the possible moves is too great, while masters have the practice and experience necessary to see several moves ahead.

Many programmers are familiar with this comic that humorously illustrates the dangers of a high cognitive load, and how it can impact performance. Code can have so many branching logic arguments and class or function calls to other files that it can sometimes be hard to keep everything straight when debugging a problem.

This is why coding conventions can be very important.

Sometimes it might seem arbitrary to have certain types of files in one directory, while other files are in a different one, but when you need to debug a problem, having these conventions reduces the cognitive load while moving through the code allowing you to have more brain power to keep track of the logic of the application.

But also, we need to be aware of cognitive load not just for ourselves, but for the users of our applications.

If you present too many options and too much data on any one screen, a user may be unable to fully utilize the app. The Nielsen Norman Group which specializes in User Experience Research has some guidelines for reducing cognitive load of a user. Games like Fields of Arle do take advantage of these guidelines sometimes. For example, if a space allows you to collect wood, it will use a wood icon. Any space that costs wood will also use wood icons. It allows you to scan the worker action spaces more quickly to see which resources are available, or which items you could buy with the resources you already have.

Reducing your cognitive load regarding resource management allows you to devote more brain power to the decision making. Which is a good thing for this game, because as I mentioned earlier, the branching decision trees spanning multiple rounds when planning your future turns can get very complex and confusing.

RoboRally

Robo Rally is a game about moving your robot through a factory, and attempting to reach several checkpoints before the other robots can. The way each player moves their robot is by pre-selecting 5 moves before the turn actually begins. These can include things like, “Turn Right”, or “Move forward 2 paces”. You only have a certain amount of time to choose your 5 cards, and if time runs out before you do, the remaining movement spaces are selected randomly.

Where this gets dangerous is that each player does one movement action at a time. So while you might have planned out a perfect path for your robot, another player might block you, or bump you one space over, on one of their movement turns first. So now your entire plan can be offset by an entire column. Since the board has obstacles like pitfalls and conveyor belts, this could mean your pre-programmed set of movements send your robot to a very different spot on the board than you had planned.

Which brings us to a useful programming skill: risk management.

Since everyone is attempting to reach the same checkpoints in Robo Rally, you can generally assume where people might be trying to send their robots. So you might choose shorter movements where, even if you do get bumped over one space, you don’t risk driving your robot into an open pit. Sure, it might take you an extra turn to reach a checkpoint, but mitigating the risk associated with unknown movements could prevent you from having to start over from the beginning of the game board.

Just like in programming – it takes extra time to do things like write tests, and refactor large code blocks – but the risk of not doing those things is far too great. And if something unexpected does happen, you’ll be glad you planned ahead.

Tzolk’in

Tzolk’in is a game centered around collecting resources based on the Mayan Calendar. There are several “gears” on the board, each with 10 worker spaces that line up with a resource outside of the gear. Each round the gears move, so that each worker moves to the next resource (which increase in value as you move).

When you pick up a worker, you collect the resource they were on. The catch is that when you place a worker, you have to place them on the lowest-numbered open resource spot (ie: the least valuable). If multiple players have gone to a gear and filled in the lower valued resources, you’re in luck and can place your worker on a higher value resource. But each turn you can only place workers or pick up workers. And there are 5 total gears in the game, each one offering different types of resources.

So the difficulty in this game is strategically placing workers across the different gears so that they can advance far enough along those gears to be in just the right place at just the right time to get the specific resources you want when you pick them up. And since you can only place or pick up, and not both, you want to try to plan ahead to have as many workers on advantageous resource spots as possible to maximize your turn.

This type of time management can be useful when planning projects.

Knowing how to break up a project into smaller tasks, and when to schedule those tasks is very important. You need to make sure core pieces of your project come first, and that you don’t try to start a component that relies on something else before that piece is done.

Having a developer spend hours working on a ticket only to discover they don’t have all of the required pieces of the project isn’t just a waste of their time, but also a waste of the company’s time, and the client’s time. Knowing when and where to work on something is critical.

And I’ll be 100% honest – this example is a bit of a stretch and I really just wanted to find a way to include this game. The mechanics are fun, and if you Google for Tzolk’in Gears, you’ll find there’s an entire subculture of board gamers focused on painting their gears to more accurately reflect Mayan culture and artwork. Which ties in to another common developer trait – super nerdy hobbies.

Burke’s Gambit

There’s a large genre of board games called “hidden role/social deduction” games. If you’ve ever played Werewolf or Mafia, you’re familiar with the concept. There’s a basic goal that a large group wants to accomplish, and there is a group of secret bad guys who want to prevent this. They cant be too obvious in trying to prevent it though, because then the good guys can vote the out, and achieve their goal unimpeded.

In Burke’s Gambit, you’re a spaceship crew, and someone has been infected with a parasite. There’s a group of evil corporate bad guys who want to bring it to earth to weaponize it, and the group of good guys who want to save the planet by ejecting the infected crewman into space. No one on the ship knows who’s infected though – not even the infectee. If you’re a good guy, you want to investigate people to see if theyre infected, and if you find who it is, you need to convince the other good guys to vote with you to eject that person out an airlock.

The catch is that the good guys don’t know who the other good guys are. Everyone is going to claim to be a good guy. The other good guys might not even believe you, because in this game, the only proof you have to back up your claim is your own power of persuasion.

And you need to be very persuasive, because if you cant convince the rest of the crew that you’re telling the truth, the bad guys (who do know who each other) will know you found the infected person, and then attempt to kill them, because then the parasite randomly infects another player, and the good guys have to start all over.

This strikes a good balance between sharing info and sharing too much info, as well as highlighting the importance of persuasive logic.

So what skill can programmers utilize or learn from this game? Lying to your manager about how far along you are on your current task? No, of course not! But most developers deal with non-developers in their job every day. And sometimes we may run into issues that might be hard to grasp for people who are less technical, and you’ll need to explain the problem in clear, concise way that lays out the issue, why it’s important, and what should be done about it.

Social deduction and hidden identity games bring out that skill, because they rely almost entirely on being able to lay out a bunch of information clearly so that other people will listen and believe you.

Board games improve many life skills.

Board Gaming has come such a long way in the last 20 years that modern gaming applies to skills useful in real life much more than they used to, and perhaps in ways people playing the games don’t even realize.

Hopefully this article sparks people to think about their board games a little more deeply at how their current skills can be applied to them, or even how they can help you hone new useful skills.

---

culture education engineering product project management UX UX Design