Learning by Building: How Self-Learning, Practical Experiments, and AI Changed the Way I Engineer

Engineering, for me, stopped being about knowing answers the day I realized most real problems don’t come with clean documentation or step by step guides. They come with broken builds, vague requirements, and systems that behave differently in production than they did on my local machine.

That’s where self learning, practical experimentation, and lately, AI assisted workflows completely reshaped how I approach problems.

Self Learning Is Not Watching Tutorials

For a long time, I confused learning with consumption. Watching tutorials, reading blogs, bookmarking articles it all felt productive. But the real shift happened when I started learning by implementing, even when I didn’t fully understand what I was doing.

Instead of asking “Do I understand this topic?”, I began asking:

• Can I build something small with it?
• Can I break it and fix it?
• Can I explain why it failed?

That mind set made learning stick. Debugging a broken API integration taught me more about async flows than any theoretical explanation ever could. Fixing a state management bug in a React app taught me why architectural decisions matter early and how costly shortcuts become later.

Practical Learning: Observe, Don’t Assume

One habit that helped me massively is observing results instead of assuming behaviour.

For example:

• I stopped assuming a performance optimization worked I measured it.
• I stopped assuming a refactor improved readability I checked how fast I could understand it after a week.
• I stopped assuming an architecture would scale I simulated edge cases.

This approach exposed uncomfortable truths:

• Some “clean” code is hard to debug.
• Some abstractions solve problems I don’t actually have.
• Some optimizations add more complexity than value.

But that discomfort is valuable. Practical learning forces honesty, and honesty leads to better engineering decisions.

Breaking Down Problems before Solving Them

One mistake I used to make was trying to solve the entire problem at once. Bigger features felt overwhelming, and debugging felt chaotic. Now, my first step is problem decomposition.

I break tasks into:

1. What is the actual problem? (not the symptom)
2. What are the known constraints?
3. What parts can fail independently?
4. What is the smallest testable version?

This breakdown does two things:

• It reduces cognitive overload
• It creates checkpoints where learning happens naturally

Instead of “build a feature,” I’m solving small, observable problems. And small problems are easier to reason about, test, and improve.

Using AI as a Productivity Multiplier (Not a Crutch)

AI tools especially Cursor AI changed how fast I move, but more importantly, how I think.

I don’t use AI to replace understanding. I use it to:

• Generate boilerplate faster
• Explore alternative approaches
• Refactor code more confidently
• Debug edge cases I might miss

Cursor feels like a pair programmer who never gets tired. When I’m stuck, I don’t ask it for “the solution.” I ask:

• Why might this fail?
• What assumptions am I making?
• Is there a simpler approach?

The real power of AI is not speed alone its feedback. Immediate feedback accelerates learning, and learning compounds.

Automation over Repetition

Another shift in my engineering mind set is actively removing repetitive work.

If I find myself doing something twice, I ask:

• Can this be automated?
• Can this be standardized?
• Can this be documented once and reused?

Automation doesn’t just save time; it reduces human error and mental fatigue. Simple scripts, reusable components, or even AI assisted workflows free up energy for actual problem solving instead of mechanical tasks.

Long Lasting Solutions Come from Understanding, Not Hacks

Quick fixes feel good until they don’t.

Over time, I noticed that solutions last longer when they’re built on:

• Clear problem understanding
• Simple, testable logic
• Fewer assumptions
• Measurable outcomes

This doesn’t mean over engineering. It means intentional engineering. Sometimes the best solution is the simplest one that can evolve.

Debugging as a Teacher

Debugging deserves special mention. It’s frustrating, slow, and humbling but it’s also the best teacher.

Every bug teaches:

• How systems actually behave
• Where abstractions leak
• Which assumptions were wrong

I’ve learned more from bugs than from successful builds. And now, instead of dreading debugging, I treat it like reverse engineering someone else’s thinking sometimes that “someone” is past me.

Final Thought: Engineering Is a Loop, Not a Ladder

Learning in engineering isn’t linear. It’s a loop:

Build → Observe → Break → Fix → Improve

AI accelerates this loop. Practical learning strengthens it. And breaking down problems makes it sustainable.

The goal isn’t to know everything. It’s to learn faster, adapt better, and build things that survive real world usage.

That’s the kind of engineering I’m excited to keep practicing.