After coming across it a couple of years ago, I saved this cartoon by Kolja Wilcke to my hard drive because it struck such a chord with me. I find it a wonderful example of what we might call a “Janus cartoon”: an editorial comic that makes both its intended argument and its exact opposite with near-equal force. In this cartoon’s case, I side with the antithesis, and adore both the strength of the argument and its clearly accidental nature.

Let me describe why I love it. You don’t need to fully understand the details about “static typing” versus “dynamic typing” to get the joke here; it’s enough to know that programming languages or techniques that use static typing generally enforce much stricter rules about how you write your code than those allowing dynamic typing. It trades reduced flexibility for a similarly reduced likelihood of certain sorts of bugs. The depicted metaphor of the two giraffe-puzzles, in fact, illustrates the difference very cleverly!

This is what I take to be the cartoonist’s intended message:

Mr. Static knows how to solve a problem: slowly and carefully. Observe how eleganty the restrictions of his system help him draw order out of chaos, forcing him to use industry-standard best practices while assembling this puzzle: corners first, then edges. He cannot even consider the middle pieces before establishing that solid framework to build upon further.

We may join him in looking askance at foolish Mr. Dynamic, shouting with glee over his clearly defective output, made with a quote “friendly” unquote system that lets him rotate its parts every which way. Never mind him, Mr. S! Keep your nose down, knowing that each piece you painstakingly place can only go precisely where it ought.

And here is how I cannot help but read this cartoon:

After having an absolute blast while rapidly bringing his vision of a solution into reality, Mr. Dynamic whoops with joy—unsettling poor Mr. Static, whose unforgiving toolkit has prevented him from achieving even a halfway-complete prototype in the same amount of time.

We cannot deny the imperfections in Mr. D’s solution. In fact, Mr. D will discover them as soon as he or his colleagues give his work a second glance. Laughing, he will take a few moments more to make the obvious repairs.

Perhaps Mr. S, after wiping the sweat from his furrowed brow, will snap another piece or two into his own solution before Mr. D is done. No doubt he will appreciate the peace and quiet after Mr. D ships his completed project and moves on to the next one.

Of course the real world provides us with many situations where a strict software toolkit that forces slow, thoughtful work might provide a net benefit. One thinks of the proverbial nuclear reactor control systems, or airliner autopilots.

But that’s not what this cartoon depicts. The puzzle-solvers are each trying to build a picture of a funny giraffe. I would suggest that this scenario does not present an optimal time for bringing the whole book of engineering best practices to bear.

This cartoon does not only contain a metaphor of static versus dynamic typing in computer programming. It also shows the pure joy that a code-competent creator can feel by building something new—however sloppily, or initially rife with runtime errors. The best tools for this style of computational creativity are very often the ones that let you throw the puzzle pieces around however you please, letting you rapidly make real the image which only hours ago existed only as a gnawing possibility.

The cartoon reminds us: when choosing your tools, consider the role of joy.