Making = Thinking

It’s better to experience than to learn. Below are interactive sketches that demonstrate foundational ideas in Design, Business, and Technology — rooted in neuroscience and made visceral with code. They’re not the best examples yet, but this gives you a sense of where I want to head.

Design: Optical Centering Isn’t Visual Centering

A classic design principle is that perfect vertical centering often feels off. Why? Our perception is subject to implied gravity and form distribution.

Click the button to toggle between “actual” and “optical” centering.
Notice how the square “feels” more visually centered when slightly below the mathematical midpoint.

Why this matters:

This subtle shift isn’t just aesthetic—it reflects core ideas from Gestalt psychology, where German theorists like Wertheimer, Köhler, and Koffka showed that our perception favors holism, organizing visual elements into unified wholes rather than isolated parts. Principles such as figure–ground and Prägnanz (good form) explain why a shape slightly lower feels more centered within its context. The Bauhaus designers of the 1920s, influenced by these ideas, intentionally used visual balance—placing elements where they feel right—to create compositions that are harmonious and perceptually balanced, even if not geometrically centered .

Business: Redundancy Makes Resilience

Supply chains are systems — and fragile ones at that. This sketch shows how breaking a single link disrupts flow unless backup paths (redundancy) exist.

Click the button to toggle redundancy. When redundant paths are shown, the backup “detour” flows above the main chain if a break occurs.

Why this matters:

In When More Is Not Better, Roger Martin warns that an over‑focus on efficiency often undercuts resilience. He describes how systems built for lean performance tend to develop “too much connectedness … and too much pursuit of perfection,” leaving them vulnerable when disruptions occur. Martin draws on systems thinking to show that robust supply chains—like natural systems—benefit from “productive friction” and intentional redundancy to maintain flow under strain.

This demo brings Martin’s warning to life:

• Without redundancy, the system collapses at the first failure.
• With redundancy, the network reroutes—maintaining continuity and demonstrating how resilience trumps excessive efficiency.

Tech: Why Encapsulation Makes Code Simpler

Compare how procedural and object-oriented code handle the same visual—10 bouncing balls.
Click Show Code on either side to reveal how many lines it takes for each approach.

Left (Procedural): All the data (positions, velocities, colors) is stored in separate arrays. Updating and drawing every ball means juggling all these arrays together in the main loop. As complexity grows, this approach quickly becomes hard to manage.

Right (Object-Oriented): Each Ball object keeps its own data and knows how to update and draw itself. The main loop just asks each ball to handle itself. This makes the code easier to read, extend, and maintain.

Why this matters:

Encapsulation and abstraction—core to OOP—mean you don’t have to know how a Ball works inside, just that it can be updated and drawn. This approach makes it far easier to scale your code as you add more features or types of objects.

“The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.”
—attributed to Alan Kay, creator of object-oriented programming

Abstraction and encapsulation are what allow software to grow from simple sketches to complex systems without becoming tangled.

Learning happens faster when it’s embodied. That’s the design of the Useful MBA. —JM