I Didn't Start Coding to Build Websites. I Started to Solve Problems.

A reflection on building practical software, learning through real-world challenges, and turning repetitive work into digital solutions.

I didn't start coding because I wanted to build beautiful websites.

I started because I was curious about how things worked — and more importantly, how they could work better.

That curiosity eventually turned into something bigger.

I began looking at everyday problems differently. Tasks that required repetitive manual work. Information scattered across spreadsheets. Processes that could be simplified but had never been reconsidered.

I started asking myself a simple question:

What if I could build something to make this easier?

That question became one of the foundations of my journey as a software developer.

Learning by Building, Not Just Watching

Like many self-taught developers, my early journey involved tutorials, documentation, failed experiments, and plenty of moments when something that looked correct simply refused to work.

I learned by building small things, breaking them, and trying again.

Over time, my interest grew beyond simply writing code.

I became interested in how applications are structured, how interfaces communicate with users, how data moves through a system, and how technology can solve problems beyond the screen.

I realized that software development is not simply about making something function.

It is about understanding what should be built in the first place.

When My Workplace Became My Laboratory

Working in an educational institution gave me a different perspective on software.

I wasn't only looking at problems from the perspective of a developer. I was experiencing them directly.

Administrative processes, employee records, student information, and internal workflows often involved repetitive tasks and manual coordination.

These weren't hypothetical problems from a coding exercise.

They were real challenges affecting real people.

That environment gave me an opportunity to apply what I was learning.

I started developing internal applications designed to make administrative processes more organized, accessible, and efficient.

Projects such as employee management systems and student management applications became more than portfolio pieces.

They became practical exercises in understanding users, designing workflows, managing data, and making technical decisions.

And perhaps the most valuable lesson was this:

The best software is not necessarily the most complex software. It is the software that genuinely helps someone do their work better.

Building Is Only Half the Work

As I continued developing applications, I learned that writing code is only one part of the process.

A working feature does not automatically mean a good solution.

There are other questions that matter just as much:

• Is the interface intuitive for someone who isn't technical?
• Is the data structured properly?
• Can the application be maintained as requirements change?
• Does the solution address the actual problem?
• Is the technology appropriate for the available resources?

These questions gradually shaped how I approach development.

I became more intentional about architecture, user experience, maintainability, and the trade-offs behind technical decisions.

For example, when starting a new project, I don't want to choose a technology simply because it is popular.

I want to understand what the project actually needs.

Sometimes that means using a modern stack such as Next.js, TypeScript, and Firebase.

Sometimes a simpler solution is the better choice.

The technology should serve the problem — not the other way around.

The Role of AI in My Workflow

AI has also changed the way I build software.

Today, AI-assisted development tools can help me explore ideas, generate boilerplate code, investigate errors, and move from an idea to a working implementation much faster.

But I don't see AI as a replacement for understanding software.

It is a tool.

A powerful one, but still a tool.

When an AI-generated solution doesn't fit the architecture, introduces unnecessary complexity, or simply doesn't solve the actual problem, someone still has to recognize that.

That responsibility belongs to the developer.

AI can help me move faster. It cannot replace the responsibility of thinking clearly.

This has become an important principle in my development workflow.

From Building for Myself to Building for Others

The more I build, the more I realize that software development is a continuous process of learning.

There are systems I haven't built, architectural challenges I haven't encountered, and technologies I haven't explored yet.

And I'm completely fine with that.

I don't believe being a developer means knowing everything.

I believe it means being willing to understand unfamiliar problems, investigate possible solutions, and improve the way we build things.

Every project introduces a new constraint.

Every bug teaches something.

Every user interaction can reveal something that wasn't obvious during development.

That process is what keeps software engineering interesting to me.

What I Want to Keep Building

My goal isn't to build software simply for the sake of having something to show.

I want to build things that are useful.

Things that reduce repetitive work.

Things that make information easier to manage.

Things that give people a better way to accomplish what they already need to do.

Whether that means an internal administrative system, a public-facing web application, a dashboard, or a completely new idea, the underlying motivation remains the same:

Find a problem. Understand it. Build a solution. Learn from it. Make it better.

More Than Just Code

When I look back at my journey so far, the most meaningful part isn't the number of applications I've deployed or the technologies I've learned.

It's the shift in how I see problems.

I no longer look at a repetitive process and simply accept that it has to remain that way.

I ask whether it can be improved.

I don't just see a blank screen as an opportunity to write code.

I see an opportunity to create something useful.

And that is what I want to keep doing.

Not just building websites.

Not just shipping features.

But building software that makes a meaningful difference, one problem at a time.

I'm Rheva Iqbal Abdillah, a software developer interested in building practical digital solutions, exploring modern web technologies, and turning real-world challenges into meaningful software.