DSA or Development? I Thought I Had to Choose.

In college, everyone seemed to have the same advice:

Pick a side. DSA or Development.

I picked development.

Looking back, that was a mistake.

At the time, I thought DSA was mostly about cracking coding interviews. I enjoyed building things, working with frameworks, designing APIs, and actually seeing something I built come to life.

So I focused heavily on development and convinced myself that it would be enough.

Then I started working on real projects.

And slowly, I realized how wrong I was.

DSA Doesn't End With LeetCode

One of the biggest misconceptions I had about DSA was that it was something you studied for interviews and then forgot about once you got the job.

But DSA doesn't really disappear.

It just stops looking like a DSA problem.

You don't necessarily sit down at work and think:

"Today, I'm going to solve a hashmap problem."

Instead, you encounter a problem where a hashmap happens to be the right solution.

I experienced this while working on a feature where an AI agent needed to query our database.

I didn't want to expose raw database records directly to the agent. I needed a way to control what data it could access while making lookups efficient.

So I used a hashmap to organize the data and make the required lookups easier.

There was no LeetCode problem.

No timer.

No test case asking me to return an index.

It was simply a real engineering problem.

And yet, the solution came from something I had originally thought of as "DSA."

That's when it clicked for me.

I wasn't solving a DSA problem for an interview. I was using DSA to solve a real engineering problem.

The More I Built, the More I Saw It

Once I started looking at development through that lens, I began noticing these patterns everywhere.

Rate limiting an API?

You might end up thinking about sliding windows, queues, or other ways of tracking requests efficiently.

Caching data?

You might need an LRU-style eviction strategy.

Building fast autocomplete?

A trie can become incredibly useful.

Matching records or removing duplicates?

Hashmaps and sets are obvious tools.

These aren't presented to you as DSA questions when you're building a product.

Nobody walks into a system design discussion and says:

"Here's a hashmap problem. Solve it."

Instead, you're given a requirement:

"We need this system to handle millions of requests efficiently."

And suddenly, the concepts you learned in DSA become part of the solution.

Development Tells You What to Build. DSA Helps You Understand How.

This is probably the biggest shift in my thinking.

I used to see development and DSA as two separate tracks.

Development: Build real things.

DSA: Solve coding problems.

Now I see them as connected.

Development teaches you how to turn requirements into working software.

DSA gives you the tools to reason about how that software should store, process, search, and manipulate information efficiently.

You can absolutely build applications without knowing much DSA.

But as the complexity of your systems grows, understanding what's happening under the hood becomes increasingly valuable.

The difference might not matter when you're building a small application with a few hundred records.

It matters a lot more when you're dealing with millions of records, thousands of requests, strict latency requirements, or systems where every inefficient operation gets multiplied at scale.

If I Could Go Back to College

I wouldn't choose between DSA and Development.

I'd do both.

I'd build projects because that's how you learn to create things.

I'd study DSA because that's how you learn to think about the problems underneath those things.

And, most importantly, I'd try to connect the two.

Instead of learning a hashmap only because it appears in a coding problem, I'd ask:

"Where would I actually use this in a system?"

Instead of memorizing what a queue is, I'd ask:

"What real-world problem does a queue solve?"

That connection makes DSA much more meaningful.

Better Late Than Never

I learned this later than I should have.

For a long time, I thought becoming a better developer meant learning more frameworks, more libraries, and more tools.

Those things matter.

But knowing how to build something is only one part of becoming a good engineer.

Understanding why something works, how it behaves at scale, and what trade-offs you're making is just as important.

So if you're still in college and you're currently trying to decide between DSA and Development:

Don't choose.

Learn both.

Build things.

Break things.

Solve problems.

And eventually, you'll start seeing that the two were never really separate.

I learned that a little late.

But better late than never.

Have you had a similar realization after starting to work on real projects?