You’re a Developer, All Right. But You’ll Never Be a Supervillain.

A story about why great software isn’t just built, it’s presented.

Development for Self

In the movie Megamind, the protagonist creates a new superhero to battle after taking over a city. Unfortunately, his chosen “hero” turns out to be a reckless thug who ends up fighting him for the title of “best bad guy.”

During their exchange, Megamind delivers a brilliant line:
“Oh, you’re a bad guy, all right. But you’ll never be a supervillain.”

When asked what separates the two, he explains: Presentation.

That line has stuck with me for years.

My first steps into coding were purely personal. I wrote small scripts to solve problems I was facing in daily life. One of my first projects was a Python script that generated a completely static, JavaScript-free HTML site so I could share photos from my time in the Philippines.

These tools were for me. They worked well enough but were never meant for anyone else to use, let alone become something commercial.

When I started thinking about building “real” applications, I imagined that professional developers were writing everything from scratch. I thought every company was creating bespoke code for every possible task. It was an intimidating idea and one that kept me from experimenting for too long.

Once I entered proper product development, I realized the truth. Most applications are not built from scratch at all. They are layered systems of existing libraries, APIs, and frameworks held together by glue code and creative problem solving. The polish comes later, through refinement and presentation.

At first, that realization disappointed me. I felt that the developers who created those core libraries deserved more recognition for their innovation. Over time, however, my perspective changed.

Development for Others

No matter how elegant your code is, people will use what feels intuitive and fits their needs. The best solutions balance both power and simplicity.

If you create a clever command-line tool that requires terminal experience, you may have already limited your audience. Your peers might appreciate it, but most users want ease of use, not complexity.

User Experience design matters just as much as functionality. A great tool with a poor interface frustrates users, increases support requests, and limits adoption. A smooth, well-considered experience can buy you time and trust while you refine the back end.

Good design is not a luxury. It is the bridge between capability and usability.

Pick Your Path

Not every piece of code is meant for the public. Many of the small scripts and utilities I have written exist only to make my own life easier. They were never designed for distribution or profit, and that is perfectly fine.

Other projects, however, have a wider purpose. They can solve real problems for other people, and those deserve to be built, polished, and shared.

Reflecting on this distinction has changed how I approach development. I now start every project by asking a simple question: Who is this for?

If it is for me, I focus on efficiency and practicality. If it is for others, I think about usability, presentation, and the overall experience.

So to you, reader who made it this far, consider your audience before you begin building. Not every project needs a clean, polished interface, but some absolutely do. The sooner you recognize which approach applies, the more likely you are to create something that truly resonates with its intended users.