Why Coding Feel Less Like Play (and How We Can Fix It)
How the Tools We Build Are Shrinking and Why We Must Reclaim the Joy of Creation
There is a peculiar thing that happens when you sit down to build something today. Whether you are writing a piece of code, designing an app, or just trying to automate a simple task, there is a ghost in the room. This ghost isn’t a technical bug or a lack of RAM; it is a quiet, pervasive sense of anxiety. We’ve entered an era where software development often feels less like an act of discovery and more like a defensive crouch. We are surrounded by more “computing power” than any human in history, yet many of us feel smaller, more constrained, and more afraid to just play with the machine. To understand why we feel this way, we have to look past the code and into the very way we think about creation.
The Architect and the Scaffolding
Imagine you want to build a simple wooden birdhouse. In a world of “fear-based” creation, you wouldn’t just grab a saw and some nails. Instead, you would be told that first, you must install a “Safety-First Hammering Framework,” then subscribe to a “Premium Timber Cloud Service,” and finally, ensure your birdhouse complies with the “International Standard for Avian Housing 2.0.” By the time you’re ready to drive the first nail, you’ve forgotten why you wanted to build a birdhouse in the first place. You aren’t building a home for a bird; you’re managing a complex web of permissions and dependencies.
This is the state of modern software. We have moved away from the “First Principles” of computing — the simple joy of telling a machine to do something and watching it happen — and moved toward a culture of extreme risk aversion. We use massive, bloated tools not because they are the best for the job, but because we are afraid of making a mistake that someone else has already “solved” with a giant, heavy library of code. We’ve traded our agency for a false sense of security, and in the process, we’ve made the act of creation feel like a chore.
The Invisible Walls of the Digital Garden
Now, here’s the weird part: we often don’t even realize the walls are there. Think of it like a beautiful, lush garden that is surrounded by an invisible electric fence. You can walk around, pick the flowers, and smell the roses, but the moment you try to step off the path or plant something of your own, you get a sharp shock. In the world of software, these fences are the “Terms of Service,” the proprietary ecosystems, and the “black box” algorithms that we aren’t allowed to peek inside.
When we use tools that we don’t understand and can’t modify, we aren’t really the masters of our machines; we are just sophisticated tenants. We’ve become afraid to break things because we no longer know how to fix them. If your car breaks down and you can’t open the hood, you are at the mercy of the mechanic. If your software “breaks” because a company decided to change a feature or hike a price, and you don’t have the source code, you are stuck. This dependency breeds a subtle, constant fear — the fear that the ground we are building on might vanish at any moment.
Reclaiming the Workbench
So, how do we get back to that feeling of curiosity and power? It starts by stripping away the jargon and looking at what a computer actually is: a tool for thought. If you want to stop feeling afraid of the software you use, you have to start understanding the “irreducible truths” of how it works. You don’t need to be a computer scientist to understand that code is just a set of instructions, like a recipe. When we use open-source tools or simple, local-first applications, we are taking the “hood” off the engine. We are saying, “I want to know how this works so I can be the one in charge.”
Get Oscar,Sr Sarmiento’s stories in your inbox
Join Medium for free to get updates from this writer.
Think of it like learning to cook rather than always ordering takeout. When you cook for yourself, you know exactly what goes into the meal. If it’s too salty, you know why, and you know how to fix it next time. You gain a sense of competence and independence. Building or using “transparent” software — software that is simple, hackable, and owned by you — is exactly the same. It turns the computer from a mysterious, intimidating black box back into a workbench where you can tinker, fail, and eventually, create something wonderful.
The Joy of the Unoptimized Path
We are often told that “efficiency” is the highest goal. Everything must be faster, sleeker, and more automated. But there is a hidden cost to all that optimization: it removes the human element. The most profound insights in science and art rarely come from following a pre-optimized path; they come from wandering, getting lost, and poking at things just to see what happens. If we let fear dictate our tools, we lose the “happy accidents” that lead to real innovation.
To move past this time of fear, we have to embrace a little bit of messiness. We have to be willing to use tools that might be “less efficient” but give us more control. We have to prioritize our own understanding over the convenience of a “one-click” solution that hides the world from us. When we choose to understand our tools, the fear evaporates. In its place, we find that infectious curiosity that made us fall in love with technology in the first place. The machine stops being a threat and goes back to being what it was always meant to be: a bicycle for the mind.
Key Takeaways
- Fear Limits Creativity: Modern software development is often driven by a fear of making mistakes, leading to over-reliance on bloated, restrictive frameworks.
- The Problem of Dependency: Using “black box” tools creates a fragile environment where users have no control over their own digital lives.
- Transparency is Power: Understanding the first principles of how our tools work — similar to “opening the hood” of a car — reclaims agency and reduces anxiety.
- Local-First and Open Source: Prioritizing tools that are simple, hackable, and personally owned fosters a healthier relationship with technology.
- Embrace Tinkering: Real innovation comes from the freedom to experiment and fail, not from strictly following “optimized” but restrictive paths.
Source: Software in a Time of Fear by MysteriousRook
