The Strange Power of Functions, and Why a Double Oval Matters

Jul 14, 2026

9 min read

3 views

58%

What a toaster teaches us about thinking

What if the most important design principle in life, code, and crafts is not adding more complexity, but knowing exactly what should go in, what should come out, and what should stay the same?

That sounds abstract until you picture a toaster. You put something in, apply a process, and get something out. Bread becomes toast. A pastry becomes toasted pastry. A brick, however, becomes a mistake. The machine is useful precisely because it is limited. It does one job, and it does it predictably.

That same idea sits at the center of good programming, good tools, and good making. A function is a small machine for transformation. It accepts inputs, performs a defined action, and sometimes returns a result. But here is the deeper insight: the best functions, tools, and techniques do not merely do something. They reduce uncertainty. They turn effort into repeatable form.

That is why a tiny detail like using a Double Oval punch in a craft project is not trivial. It is a choice about structure. It is a way of saying: this is the shape that makes the process work. The oval is not the whole artwork. It is the interface. It is the boundary where material becomes meaning.

The connection between code and craft is not that they are both “creative.” It is that both rely on the same hidden discipline: a well designed input changes what becomes possible.

The real question is not what a thing does, but what it can reliably transform

When people first learn about functions in programming, they often focus on syntax: the name, the parentheses, the arguments, the return value. That is important, but it is not the point. The point is that a function creates a contract.

If you give a function the right kind of input, you can expect a useful output. If you give it the wrong kind of input, the result may be wrong, useless, or even break everything. A toaster is the same way. Bread in, toast out. Milk in, disaster. Bricks in, absurdity.

This is more than a coding lesson. It is a model for how we build systems of any kind. A recipe, a habit, a stamping tool, a template, a workflow, even a conversation: all of them are functions in the broader sense. They transform inputs into outputs through a predictable process.

The most valuable systems are not the ones that can handle anything. They are the ones that make the right things easy and the wrong things obvious.

A good function does not impress you with flexibility. It impresses you with reliability.

This matters because modern life often rewards the opposite instinct. We want tools that do everything. We want workflows that adapt to every situation. We want craft supplies that can be repurposed endlessly. But too much flexibility creates ambiguity. Once a process can accept anything, it often loses the ability to produce anything specific.

That is why constraints are not enemies of creativity. They are what make transformation legible.

Inputs, outputs, and the hidden cost of “none”

In programming, there is a subtle difference between a function that returns a value and one that simply does something. Some functions hand back a result. Others mutate the world they touch. And some, like print, appear to do work while returning none, a special marker for the absence of value.

That idea is easy to overlook, but it is a powerful mental model.

Many forms of work in life feel productive because something happened, but they do not necessarily produce a reusable result. A meeting may feel active. A craft session may be busy. A day may be full. Yet if nothing can be carried forward, the process was closer to a print statement than a return statement. It created noise, not leverage.

This is where the distinction between doing and producing becomes useful. A function that returns a value gives you something you can pass onward. A function that mutates a list changes the state of the world directly. Both can be valid, but they are not interchangeable. Confusing them leads to fragile systems.

Think about making a card or scrapbook page. You can stamp an image, punch an oval, layer paper, and add embellishment. Some steps are about output, the visible artifact. Others are about state, like aligning, positioning, or preparing the base. If you treat every step as if it produces a final object, you rush. If you treat every step as if it only changes state, you may never finish.

The craft lesson hidden here is simple: know which steps are generative and which are preparatory.

The programming lesson is the same. Not every operation should return a value. Not every function should mutate data. But every function should be clear about what kind of work it is doing. Ambiguity is where bugs begin.

The Double Oval is not decorative. It is an interface

At first glance, a tool choice like a Double Oval punch seems minor, almost incidental. But tools are never just tools. They are interfaces between intention and material.

A circle, an oval, a rectangle, a tab, a notch, a return value, an argument list: these are all ways of shaping interaction. The Double Oval is useful because it imposes a form that can be repeated, aligned, and recognized. It takes an otherwise messy material and gives it an edge that can organize the rest of the design.

That is exactly what a function does in code. It gives shape to repetition. Instead of rewriting the same logic every time, you create a named transformation and use it again. The function is not the final product. It is the reusable shape behind the product.

Consider a simple analogy. If a card is a sentence, then a punch is punctuation. Punctuation does not carry the whole meaning, but it determines whether the meaning is readable. A well placed oval window can frame a stamped image the way parentheses frame arguments. Both say, in effect, “This is the boundary. This is what belongs together. This is where transformation begins.”

That is why craftsmanship and programming share a deep aesthetic. In both, elegance comes from making the process visible without making it noisy.

A beautiful function is not one with clever tricks. It is one whose purpose can be understood at a glance. A beautiful layout is not one with every shape possible. It is one whose parts feel inevitable once seen.

Good design is often just correct framing repeated consistently.

This is true whether the frame is code or cardstock.

The most useful creative habit: design for repeatable transformation

The real payoff of understanding functions as transformations is that it changes how you approach projects.

Instead of asking, “What can I make?” ask, “What can I define so I can make it again?”

That is a profound shift. It moves you from one off effort to reusable structure. A function named multiply by three does not merely compute 3 times a value. It captures a rule. It turns a mental operation into something callable. Similarly, a punch, stamp, template, or layout choice captures a visual rule. It says, “When I need this effect, I will not reinvent it. I will invoke it.”

This is the bridge between technical thinking and hands on creativity. The best makers, like the best programmers, do not just execute steps. They build a library of reliable transformations.

Here is what that looks like in practice:

Name the transformation. What exactly changes? Is it size, color, emphasis, spacing, emphasis, or structure?
Decide the input type. What materials or conditions does the process require to work well?
Specify the output. What should be true after the transformation is complete?
Identify failure cases. What happens if the input is wrong, too large, too small, or incompatible?
Choose tools that narrow uncertainty. A punch, template, or function should make the desired outcome easier to repeat.

If you think this sounds overly systematic for something as playful as crafting, that is exactly the point. System does not kill creativity. It protects it from drift.

A craft project often becomes more satisfying when the steps stop being improvised every time. The same is true in coding. The moment you stop hand waving and start defining, your work becomes scalable. You can debug it. Share it. Reuse it. Improve it.

In other words, a good process becomes a kind of memory.

The difference between clever and dependable

There is a trap in both code and craft: the temptation to admire cleverness more than dependability.

A function can be written in a way that looks elegant but hides edge cases. A craft technique can look intricate but be hard to repeat. A design can be novel but fragile. The problem is that cleverness often performs well on first encounter and poorly over time. Dependability is quieter, but it ages better.

This is where the metaphor of the toaster is especially useful. A toaster is not glamorous. It is not trying to be a microwave, an oven, or a grill. It has a narrow purpose and a clear expectation. Because of that, it becomes trustworthy.

That is also why none matters. In programming, none is not an object of beauty. It is a warning that the process did not yield a value. But that absence is useful because it clarifies what happened. It prevents us from pretending there is a result when there is not.

Good systems tell the truth about their outputs.

Craft has the same ethic. If a punch or template produces a clean, repeatable shape, it is honest about what it can do. If a tool distorts the paper, tears the edge, or requires endless cleanup, it is pretending to be more useful than it is. The same project can feel effortless or frustrating based on whether the interface respects the material.

So the question becomes: are you designing for applause, or for repeatability?

The answer matters because real mastery lives in repeatability. Anyone can get lucky once. Fewer people can produce the same quality ten times in a row.

Key Takeaways

Treat every tool as a function. Ask what it accepts, what it transforms, and what it reliably produces.
Separate output from state change. Some actions return useful results, others modify the environment. Know which one you need.
Use constraints to increase clarity. A narrow tool or rule is often more powerful than a flexible one because it reduces uncertainty.
Design for repeatability, not novelty. The best systems let you recreate success without reinventing the process each time.
Respect the role of absence. When a process returns nothing useful, that is information, not failure to ignore.

Conclusion: mastery is the art of making the right transformation inevitable

We tend to think of creativity as invention, the moment something new appears. But the deeper form of creativity is more disciplined. It is the ability to create conditions where the right thing happens again and again.

That is what functions teach. That is what tools like a Double Oval punch quietly teach. The shape matters because the shape governs the transformation. Bread becomes toast. Paper becomes design. Input becomes output. Intention becomes form.

And once you see that, you stop asking whether a tool is merely simple or sophisticated. You start asking a better question: What kind of transformation does this make inevitable?

That question changes how you code, how you craft, and how you think.