Today I was reviewing a recent performance improvement for one of our systems. Part of the work involved implementing caching for a segment of the process. When I asked how we would measure the results, the engineer explained all the complexities: different environments, variable loads, configuration differences. It was all valid, but the explanation felt heavy, almost paralytic.

I paused and suggested a simpler approach: don’t change the existing behavior. Instead, add a parallel path of logic controlled by a runtime flag. One test with caching on, one test with caching off—same environment, same inputs, apples-to-apples comparison. This way, nothing “breaks,” and the performance gains can be measured accurately. If the results were good, we could later remove the flag and the old path, leaving a clean, optimized system.

She looked at me for a moment—and then something shifted. It was as if a switch had flipped. A window opened. She stopped seeing code as a single rigid version of execution. Instead, she saw a live system, one that could be experimented with safely, a system she could tinker with to understand the impact of her changes.

This small change in perspective did more than simplify a performance test. It broadened her understanding of what code can be—dynamic, testable, iterative. And once again, it underscored the importance of design patterns when working with complex systems: patterns aren’t just structure, they’re a language for thinking about code as a living, evolving thing.

This moment also highlighted a subtle but critical distinction: the difference between a programmer and a software engineer.

A programmer often sees code as a sequence of instructions—a single version of execution that must work correctly. Their focus is on making the code run, on “solving the problem” in isolation. Errors are bugs, performance issues are annoyances, and success is measured by whether the system behaves as expected.

A software engineer, on the other hand, sees the system as a living entity. Code is not just instructions—it’s a tool to explore, experiment, and optimize. An engineer anticipates impact, designs for change, and measures effects systematically. When you introduce a parallel path with a runtime flag, you’re not just testing caching—you’re thinking about observability, risk containment, iterative improvement, and the long-term health of the system.

The “engineering mind” reframes the work: every line of code has context, every change has measurable outcomes, and every decision is part of a larger system. It’s the mindset that turns code from a static artifact into a dynamic lever, a system you can safely manipulate to learn, improve, and scale.

That switch—the one that flipped for my engineer today—is really the flip from writing code to engineering software. Once you see it that way, experimentation, measurement, and design patterns become second nature.