No code is inherently evil

No code is inherently evil. That's not a typo. It's a triple entendre, and the more time you spend building software, the more each meaning resonates with you. Let's dig in together and see what makes this idea so fascinating.

No code tools

Let's start with no code tools, an ever more-relevant topic in the age of AI. They promise to save you from the pain of writing code. Drag, drop, publish. It feels like magic, until it doesn't.

The honeymoon ends when you need to do something custom. Suddenly, you're staring at a wall of auto-generated spaghetti, or worse, a locked box with a single escape hatch that dumps you into a world of pain.

Want to add a feature? Rewrite half the project. Want to integrate with something outside the walled garden? Prepare for third-party hacks, ballooning costs, and a maintenance nightmare.

No code tools are often just a footgun: easy to pick up, but just as easy to shoot yourself in the foot with. The easy start is a trap. The real cost comes later, when you need to scale, customize, or migrate.

Analysis paralysis

But there's another kind of no code evil: writing no code at all.

The cult of best practice tells us to analyze, plan, and optimize before we even start. We chase the best framework, the right architecture, the perfect stack. We freeze, paralyzed by choice. Meanwhile, the real world moves on.

The truth? You learn more by shipping something ugly than by endlessly debating what's best. Write code, even if it's bad. Ship it, break it, learn from it, and do it better the second time.

The first version is disposable. The second is informed by reality. After all, you can't refactor what you haven't written. Writing bad code is a prerequisite to writing good code. Don't skip steps. Experiment, reflect, iterate.

Code itself

Finally, let's talk about the code itself. No code you write is evil by default. Code is just instructions. It's not malicious unless you make it so.

But here's the twist: even your best code will eventually be stretched, twisted, and abstracted into something you never intended. Features change, requirements shift, and suddenly your elegant solution is a Frankenstein's monster.

That's not evil; it's just entropy. The real evil is refusing to change, or worse, contorting your code into unrecognizable shapes to fit every edge case. Sometimes, the right move is to write more code, even if it means duplicating logic or starting over. Refactor later, when you know what actually matters.

Remember, code isn't sacred. It's a tool. Use it, break it, throw it away, and write more whenever you need to.

Conclusion

So, no code is inherently evil. No code tools can trap you, if you're not careful. Endlessly pondering over best practices and writing no code leads to stagnation. And no code you write is evil, until you let it rot. Write more code. Ship early. Refactor when it hurts. That's how you build things that last.