WHY WON'T THIS WORK?! Coding Angry for Fun and Profit
Why building apps the wrong way can be the right way
Reto’s Note (2026): The central thesis for this article is that it’s worth hacking something together quickly to see if the idea works before investing the time in improving the way you built it. Reading it now, in the midst of SDLC Agents and Vibe Coding it hits different. The two hours of time spent building an app the wrong way in order to get the basic peices together can now be done in about 10 minutes of Vibe Coding (or collaborating with an Agent). For some people, handing over the first-pass to an Agent defeats the purpose of learning, but in my experience it just removes the first layer of frustration.
Writing good code is hard, but if building something the simplest, easiest way can still be frustrating, what effect does the extra cognitive load of trying to build it the right way have when you’re just trying to experiment?
I know people who find peace in coding; engineers who find Zen when working on a complex problem. Each new method implemented, bug resolved, and puzzle unravelled is a step on a path that brings order to a chaotic universe, and with it, a sense of harmony, contentment, and happiness.
I am not one of those people.
I’m not saying I don’t find enjoyment in coding. I do. The high from deciphered new APIs and manipulated them into making your device do something it couldn’t before is intoxicating. You feel as a God amongst mortals, able to bend the universe to your will. All things are possible.
But until that moment, my emotional state hovers somewhere in the spectrum between white-hot rage and tear-inducing frustration.
Frustration is one our most common shared experiences
Though we engineers don’t often often talk about it with non-engineers.
The banner image shows me, 20 minutes into debugging a problem, which turns out to be that I’d forgotten to call .show() after creating a Toast in Android.
I spoke with a colleague recently—an experienced engineer new to Android—who wanted to write an app to automatically turn on his Internet-connected lights when he got close to his house. He’d done a course on Android, so he was familiar with Android fundamentals. He talked a lot about his frustrations.
I figured it should take me about an hour to go from nothing to the app he described. Rather than sit down next to him and pair program, I figured I’d record myself writing the code (and cut out the (really) boring bits.)
This screencast shows the easiest, fastest, and possibly wrongest way to build this app. Those 16 minutes represents about two hours of real-time coding and debugging, and implements everything within a single Activity. There’s a thousand ways in which this implementation is wrong—and I spend some time at the end of the video explaining why everything should be done differently.
Developing real apps for mobile is complicated
A lot of people—myself included—spend a lot of time crafting the perfect code samples, walkthroughs, tutorials, and training, so when new developers are ready to write their first app, they’ve got all the tools they need to architect it correctly, and implement it efficiently.
But if you’re trying to get a feel for Android, or even just figure out if an idea is possible, is it worth figuring out and implementing Fragments, Services, and Intent Receivers? Understanding the subtleties of the Activity and app lifecycles?
If you want to write a high quality app that users will love and VCs will want to shower money on, the answer will be a resounding yes. BUT, that doesn’t mean you have to learn all that stuff up front. If you go into it knowing you’re going to start again, it can be fun to write something hacky and kludgy just to have some fun and prove your idea can be done. I think of it as an incentive to learn the hard stuff.
As a result of this throw-away work we’ve learned something very valuable: It’s possible to do what we want—automatically turn on our Internet-connected lights when we get close to home.
When I want to learn how to code using a new platform, API, or framework, I’ll start by experimenting, trying, and failing, until I make headway or get bored.
On Day One, I just want to download the SDK, fire-up an IDE, and experiment. I’ll invest a few hours getting a feel for how things work without worrying much about the right way to do it. That’ll produce something ugly, buggy, poorly architected, and totally unscalable—but workable as a prototype.
Reto’s Note (2026): These days, I think using some combination of an LLM, Agent, or Vibe Coding experience is an amazing alternative to spending hours proving your idea can be real. You can acheive that goal in minutes.
Engineering is about translating incredibly complex concepts into simple state machines
A mobile app, at its root, is just manipulating transistors that let you create AND, OR, and NOT gates, that in turn can be used to create more complex logic—we’re really just dealing with logic circuits, which when you boil it down, is just a series of trues and falses.
These basic building blocks are used to construct increasingly complex APIs, frameworks, and platforms—which are in turn used to create increasingly feature-rich apps for users. Each step along this path effectively encapsulates best-practice implementation details, so we we don’t have to start every project defining an object, creating a linked list, and writing a quicksort algorithm.
I can take a video on my phone with a few swipes and touches, and start watching it on my TV with a few more. When you stop to think about the number of interacting systems it requires (electricity, power distribution, digital-analog conversion, video recording, video broadcasting, LCD display, Chromecast,…)—let alone how each of those systems works down to the physical layer (not to mention the complex decision process by which I decided on which video to watch, and the intricate and protracted negotiations with my wife to determine a mutually agreed-upon selection), it quickly becomes a fractal of complexity and intimidation.
As engineers, the difficulty, frustration, and ultimately the thrill of victory comes from unraveling the complications caused by multiple layers of abstraction within our code, the interaction between those components, and the way those systems are experienced by the end user.
To effectively write and (especially) debug code, you need to keep significant parts—if not all—of the system in your head. That means everything from the high-level architecture of how the pieces fit together, to how each of those pieces works—at times, all the way down to the physical layer.
The frustration comes from being pulled down the stack
We’re constantly switching contexts between “big picture” conceptualizations of how the system as a whole should work, and the excruciating detail of how each of its parts are implemented.
Say you’re incorporating Wi-Fi and Bluetooth signals into a self-learning system to trigger a geofence more efficiently. When it doesn’t work, the problem could be anything from a misunderstanding of how the Bluetooth APIs work, to mis-reading your Bluetooth signals, or forgetting to call .show() on the toast you’re using to test if it’s working.
Minimize the depth and complexity of your problem stack
To lower my frustration—and maximize my enjoyment I try to keep the scope of what I’m working on at any given time as small as possible. Once that’s working, I’ll take a step back and add more complexity, iterating quickly so that there’s a tight loop between solving a difficult problem and having a better version of my working app
In practice, that looks a little like this.
Each peak represents potential energy I can store, then expend while grinding through the coding and debugging tasks. The same general principle underpins most agile methodologies: Iterate quickly and stay flexible.
Take advantage of those highs as motivation for when you will throw your prototype away and build your app again, this time in a way that’s more robust, well-designed, and scalable.
Writing good apps is hard
Sadly, there’s no easy way to write apps. Whether you choose to build it the right way from scratch, or start with something crude and gradually refine it with each new iteration, you’ll eventually need to solve the same problems, and undergo many of the same frustrations.
Those frustrations are the price you pay for the moments of triumph—that incomparable feeling when you’ve manipulated a bunch of zeroes and ones into something that’s at once both inevitable and magical.
The secret to a long and happy career, is finding an approach that works for you—a technique that will let you bask in the sunlight of those highs more often than you spend in the dark depths of the lows.
For me, that means the right way to build an App is by starting the wrong way.
This article was originally published on my Medium page, and has been lightly edited before being republished here.