Mini Metro is a simple optimization game with surprising depth. It's all about optimizing systems to handle changing conditions with limited resources.

This is a common problem type throughout reality and has many similarities with the types of problems businesses hire software engineers to solve.

In this post we'll explore 3 skills Mini Metro teaches that are crucial to being an effective software engineer.

Want to get better at Mini Metro? 5 beginner tips to consistently score in the top 10%.

Decision Making with Incomplete Information

Mini Metro increases complexity in a run by popping up new, randomized obstacles for you to handle. This means that at any point you are making decisions on information that will be stale / out-of-date in the next 30 seconds.

This is very similar to the real world. There are only 3 guarantees in life - death, taxes, and change. Even if you had 100% of the information required to make a perfect decision that info would no longer be perfect in the next quarter / half / year thus making the decision itself imperfect.

Software engineers build systems that support real world conditions. When the real world changes, so too must the systems that support it. As such these systems must be built to be robust to the certainty of uncertainty - that usually means building systems that are flexible so they are easy to change when they need to. And they will need to.

-> Make quick, reasonable system decisions that can be changed later.

Optimize for Actualities not Eventualities

Mini Metro starts off slow but quickly ramps up in speed and complexity. If you are spending time / resources optimizing for eventualities (things that might happen) at the expense of actualities (things that will happen) those actualities will crush you before the eventualities ever get a chance to happen.

A similar thing happens in the real world in business and software. It's often summarized as "premature optimization is the root of all evil". We all want to strive to make things better but perfection is impossible and prioritizing perfect > good means you never get to good and instead get bad.

The problem with building perfect systems is that it requires a perfect understanding of the world (i.e. perfect information). As discussed, perfect information is not possible. Even if it was, it has a shelf life and thus is rendered imperfect with time. Thus imperfect.

The folly of pursuing perfect systems w imperfect information is often called The Build Trap.

-> So what should we do? We need to optimize for actualities (real things affecting us now / soon) over eventualities (things that might happen).

Some examples:

Mini Metro:

• Eventuality: Interchanges - Useless premature optimization. It only solves for one station getting overloaded but we cannot know which one station will get overloaded and this decision is impossible to change.
• Actuality: Lines / Carriages - We KNOW that system throughput is what ends games. This is a future actuality so optimizing for this at any part of the game is a good choice.

More: Mini Metro - The Best Upgrades to Choose to Optimize your Metro System

Software Systems:

• Eventuality: Building microservices to scale for your customers. If you don't already have 100k customers don't bother. Monoliths scale better and cheaper than microservices and software performance is almost never the real bottleneck so you will just hamstring your business' ability to move fast.
• Actuality: Build Simple Scalable Systems to solve for the biggest current / next problems that are cheap, easy to change, and scale to what you need right now / next. Use your saved time / effort to focus on other real problems you have right now - effectively erasing the possibility of eventualities.

Cattle not Pets

Mini Metro constantly changes the playing field. This means the optimal decision now is likely different from the one 5 minutes ago. To stay alive and get high scores you need to be ready and willing to restructure your entire systems when it makes sense - tossing what's not working and doubling down on what is.

Our reality is the same:

• It changes
• We have imperfect information
• Our previous decisions were imperfect

Thus the best system we can think of to support the reality of today is likely different than the one we created 12 months ago.

Now this is not a recommendation to go out and refactor your entire system every 12 months. That's usually a sign of premature optimization - why do you think your knowledge today is so perfect, so complete that you can fix everything perfectly when it never was before? Just as the -12 month decision was likely different from our current decision so too will the +12 month decision likely be different.

But it is to say that you should not hold any previous information or decision as sacred. These decisions are not pets (1:1) but cattle (1:many). The best way to handle this is to be logical, rational and optimize for the whole not the 1.

-> Systems / decisions are cattle not pets. Re-evaluate them when a new problem / opportunity arises, optimize for the whole, and refactor them when it makes sense.

Next

I think we can learn a lot from video games if we consider the core problems they represent. In many ways I find base building / simulation games to have lots of overlap with software systems which is perhaps why I like building software so much.

Q: Do you have a favorite base building / simulation game? What problems does it share with software engineering?

If you liked this post you might also like:

• Mini Metro - 5 Beginner Tips to Reach Top 10% on the Leaderboard
• Simple Scalable Systems - How to find 80/20 Silver Bullet Solutions for any domain
• 3 Tips to be an effective Software Engineer (with less work and more fun)