Minimal Working Example

A Minimal Working Example (MWE) is usually a good way of either isolating a problem or asking others for help.

The first rule about debugging is that the bug should be reproducible. While there are fringe bugs that appear out of nowhere, it’s hard to track them if there’s no good way of bringing them to light. So, there should be a way to make the error appear in a consistent manner.

A good way of doing this is to divide and conquer—in other words, to divide the program in chunks small enough to be analyzed in their own.¹ Many times, this is enough to track down a bug.

But sometimes it’s not. When this happens, a MWE is often the best way to ask others for help. Instead of being a fscking n00b and asking “what is wrong here?” your fellow programmers will more often than not help in good nature if you present them with a MWE. Why?

First of all, it shows your work. Anyone can just copy/paste the entire code to a forum asking for help, but that’s just lazy. Dissecting your code to produce a MWE shows that you’ve already worked to reject alternate solutions and have isolated the problem to the best of your abilities.

Second, a MWE is a tool for others: it should narrow—for the reader/reviewer—the gap between what you’re doing and what you want to do. It’s way easier for me to help if I know in advance what something is supposed to produce.²

Moreover, a MWE is not just for bugs. Many a newbie learning, say, LaTeX can learn new things by performing them on a MWE. If you just want to learn how to add an epigraph to your chapter, there’s no need to write the whole thing when a one-page Lorem Ipsum document will suffice. Learning on MWEs is a good first order approximation to new methods and techniques.³

So the human take away of this programming lesson is: be mindful of the system that will have to read your code—be it a human or a machine—and try to reduce its cognitive/computational load up front by doing your own work first. Everyone will be better off because of it.

1. This is another reason why dividing your functions is better done earlier than later.

2. For instance, I’ve seen many newbie programmers complain that their code isn’t working when it has no apparent mistakes. A common cause is that the function is correctly returning a result, but the newbie wants it printed to the console. See The difference between returning and printing.

3. But it shouldn’t be the only one. Many problems do not scale well and assuming that your small code will work when it has to be repeated 10,000 times is a common beginner mistake that should be addressed from the start. [DonJaime says: "...taken out and shot? Mentioned more often?].