Hi, I’m Owaish - Here’s How I Got Into Building Software

I'm Owaish Alam, a B.Tech student at ITER, SOA University in Bhubaneswar, and currently a full-stack development intern at Ektraa, an event marketplace.

I've been around computers for most of my life, although my relationship with them started very differently from where I am today. I didn't grow up knowing that I wanted to become a software developer. I just liked playing video games, had a lot of questions about how things worked, and eventually discovered that building things was as interesting as using them.

It started with video games

My earliest memory of really interacting with a computer goes back to when I was around five years old.

I had just gone to boarding school and didn't really fit in. During evening playtime, I sometimes ended up playing video games on the school computer instead. It didn't last very long. I changed schools within my first year, and for the next few years my access to computers was mostly limited to summer and winter holidays.

But the interest stayed.

By the time I was around nine or ten, I had started asking a different question.

How does someone actually build a game?

For a long time, I thought I wanted to become a game developer. I eventually experimented with making small 2D games myself - things like Snake, space-war games, and a game where you drove a car while dodging other cars.

I eventually lost interest in game development, but the curiosity that came from it never really went away. I was less interested in simply using software and increasingly interested in understanding how people made it.

From a textbook to the web

My first proper introduction to web development came when I was around twelve through something fairly ordinary: a school textbook.

It introduced me to HTML and CSS.

I kept going after the textbook ended. HTML and CSS eventually led me to JavaScript, and JavaScript eventually led me to React.

Like most people learning to code, I built things that weren't particularly successful.

I made a website for my school. Nobody used it.

At one point, I made a website for my town.

These weren't groundbreaking projects, but that didn't really matter. I was learning that I could have an idea, write some code, and turn it into something that actually existed.

Figuring out how to put things on the internet

At around thirteen, I started figuring out how to deploy the websites I was making.

They were simple static HTML, CSS, and JavaScript sites, and I initially hosted them using 000webhost. Eventually, while reading through Stack Overflow, I came across AWS and started experimenting with deploying things there.

I wasn't thinking about "cloud engineering" or infrastructure at the time. I just wanted to figure out how to put the things I made on the internet.

That meant deployment became part of programming surprisingly early for me. Years later, when I started working with backend systems and more complicated applications, the idea of deploying and managing something outside my own machine wasn't completely unfamiliar.

Going beyond the frontend

For the next few years, most of what I learned revolved around frontend development.

Eventually, at around sixteen, I wanted to understand what was happening on the other side of the applications I was building.

I started backend development with Express and MongoDB. From there, I moved into SQL and PostgreSQL and started working with ORMs such as Prisma.

As the things I wanted to understand became bigger, so did the list of things I needed to learn.

I started getting into system design and learning about Redis, queues, monitoring, logging, databases, infrastructure, and the various pieces involved in keeping an application running beyond simply responding to an HTTP request.

Interestingly, Docker came relatively late for me. I started using it more seriously when I began working with other developers on freelance projects. Once you're no longer the only person running your code, having a consistent environment suddenly becomes much more important.

I think this pattern has followed me throughout my time programming. Once I become comfortable with one layer, I eventually become curious about what's happening underneath it or behind it.

The first thing I built that strangers actually used

One of the most important projects I built came when I was still relatively new to backend development.

It was a Telegram bot for sharing files.

The idea was simple: you could upload a file to the bot and get something you could share with someone else. When they opened it through Telegram, the bot would send them the file.

I built it in JavaScript and didn't really expect much from it.

I didn't advertise it. I didn't post about it anywhere. Somehow, people started finding it anyway.

And then more people started finding it.

Eventually, the bot reached around 5,000 users.

To this day, I'm not entirely sure where all of them came from. Maybe Telegram's search and discovery helped. Whatever the reason, it was the first thing I had made that a meaningful number of complete strangers were actually using.

It was also when I learned that getting users creates an entirely new category of problems.

Files need storage.

Storage costs money.

And when thousands of people are using something you've built, those costs stop being theoretical.

I tried to find a way to make the project sustainable. At one point, I experimented with allowing uploaders to put a paywall on their files while the platform took a small fee from transactions.

It didn't work.

Eventually, I couldn't justify covering the storage bills anymore, and I shut the bot down.

The project wasn't a successful business, but it taught me something that small personal projects couldn't: building software and operating software are two very different problems.

Getting something to work is only the beginning when real people start depending on it.

Freelancing and working with other developers

Along the way, I also started doing freelance work.

I've worked on roughly five or six freelance projects, ranging from smaller individual jobs to projects involving other developers. One of them was a certificate distribution and verification website for a computer training class.

Working with a team was a very different experience from building things alone.

On some of those projects, I was the most junior person on the team. A lot of my work involved smaller tasks and the less glamorous chores that simply needed to get done.

But that experience was valuable.

From college to Ektraa

I'm currently pursuing my B.Tech at ITER, SOA University in Bhubaneswar.

During my second year of college, one of my classmates forwarded me a message about an internship opportunity. I reached out, went through the interview, and ended up joining Ektraa as a full-stack intern.

Ektraa is an event marketplace, and working on a startup product has been very different from working on my own projects.

Personal projects give you a lot of freedom. If something breaks, you can rewrite it tomorrow. If an idea isn't fully thought through, you can figure it out while you're building.

That becomes much harder when you're working on something with bigger stakes, deadlines, other developers, and features that depend on one another.

Things can get messy surprisingly fast.

Communication before code

One of the most important things I've learned from working with a team has very little to do with a programming language or framework.

Communication comes first. Coding comes later.

We recently had a situation where we needed to build a lot of things in a very short amount of time.

We started working quickly, but we hadn't spent enough time discussing and aligning on everything that needed to be built.

It became a mess.

Some features ended up being poorly executed, and parts of the work eventually had to be rewritten.

The interesting part was that the underlying problem wasn't that everyone suddenly became worse at programming. We had started writing code before we had communicated enough about what that code was supposed to accomplish.

Experiences like that have changed how I think about becoming a better developer.

For a long time, improving meant learning another language, another framework, another database, or another technical concept.

Those things still matter.

But writing good software with other people also means learning how to communicate, ask the right questions, clarify assumptions, and make sure everyone is actually solving the same problem before the implementation begins.

Where I am now

Today, I'd describe myself as a full-stack developer, although I'll admit that the label sometimes gives me cold feet.

The more I learn, the more things I discover that I don't know.

I don't consider myself an expert. I'm still learning something almost every day, and there are plenty of areas where I know I need to improve.

Recently, I've started learning Go.

I'm also trying to get better at system design, writing clearer code, choosing better names for variables, and writing raw SQL.

Somehow, people ask me now

One slightly strange part of college has been finding myself on the other side of questions I used to have.

Classmates sometimes come to me asking things like:

• Which programming language should I start with?
• Should I focus on development or DSA?
• How do I get started with development?

I certainly don't have all the answers.

But there's something funny about remembering myself learning HTML and CSS from a textbook, digging through Stack Overflow to figure out how to deploy a website, and wondering how people built the software I was using.

I'm still asking questions today. They're just different questions.

And now, occasionally, I'm also the person someone else asks.

Outside of programming

Programming takes up a good amount of my time, but thankfully not all of it.

I enjoy anime and good TV shows, especially mysteries and detective stories. Sherlock, The Mentalist, Death Note, The Millionaire Detective, and Lost are some of the kinds of shows and stories I enjoy.

And on weekends, there's a good chance I'm watching football.

I'm a Messi fan, and when it comes to club football, I support Manchester City.

I just want to keep building

When I was a kid, the question that pulled me toward all of this was simple:

How do people build games?

I don't really want to become a game developer anymore.

But looking back, the important part of that question was never specifically about games. I wanted to understand how someone could take an idea and turn it into something another person could interact with.

Games became little websites.

Those websites led to JavaScript and React.

Frontend led me toward backend development. Backend led me toward databases, infrastructure, system design, and all the other pieces that make software work.

Small projects eventually became something thousands of strangers used. Working alone eventually became freelancing and working with teams. And what started as curiosity eventually led me to working on a real product while still in college.

I don't have a grand statement about exactly where I need to be ten years from now.

I just want to keep building things.

Sometimes they'll be useful. Sometimes they'll just be fun. Some will probably fail, and some might unexpectedly find thousands of users.

Either way, I want to keep learning enough to build the next one.