The Value of Patience in Development
The best engineering work can't be demo'd in 15 minutes—real value comes from invisible plumbing and a thousand small improvements over years, not quick wins.
Read Original Summary used for search
TLDR
• Phoenix sells with "Twitter clone in 15 minutes" demos, but Nerves (embedded systems) requires patient, sustained effort—exposing how we conflate pitch-ability with actual value
• Good IoT devices need invisible fundamentals: A/B partitions for safe updates, watchdog timers, handling brutal power cycles, clock sync edge cases—none of which make for snappy demos
• The deepest satisfaction in software (like physical fitness) comes from accumulating hundreds of small improvements, not quick hits to the reward system
• Complex systems like Ash Framework or production Phoenix apps follow the same pattern—the path to quality is "much less clear, much debated" and takes care to shepherd
In Detail
The author draws a sharp contrast between technologies that deliver quick dopamine hits versus those requiring patience for deep value. Phoenix can be pitched with flashy 15-minute demos, while Nerves (Elixir for embedded systems) demands sustained effort to integrate hardware and software well—making it harder to sell despite potentially greater long-term value. This reveals how we've conflated "easy to demo" with "actually valuable."
Using his work on SmartRent thermostats as an example, he illustrates the invisible complexity: backlight brightness based on ambient light sensors, night mode logic, dark mode handling. But the real engineering depth is in the unglamorous plumbing—A/B partitions for safe updates, watchdog timers, self-recovery mechanisms, handling out-of-sync clocks and brutal power cycles. These fundamentals keep devices running for 10 years but make terrible demo material. Even "quick" frameworks like Phoenix require this same patient craftsmanship for production quality—Ash Framework's attempt to provide structure is "non-trivial" with "a lot to learn."
The parallel to physical fitness is apt: the first climbing gym session is fun, but the deep satisfaction comes after a year of accumulated strength. Good software, like good physical conditioning, is built through "many, many small improvements" and "a thousand small improvements." The challenge for engineers is learning to value—and sell—work that can't be compressed into viral demos.