There’s a strange feeling that comes with learning technology.
You can spend hours watching tutorials, reading documentation, taking courses, and solving problems and still feel like you don't know enough to build something real.
That feeling has followed me for a while.
I'm studying Electronic and Electrical Engineering, while also learning frontend development, IoT, and embedded systems. One day I'm working with React and TypeScript. The next, I'm looking at microcontrollers, sensors, circuits, or trying to figure out why some piece of hardware isn't behaving the way I expected.
There is always something else to learn.
And that's the problem.
For a while, I kept thinking I needed to learn more before I could seriously start building.
I eventually realized that was backwards.
Maybe building is how I learn what I actually need to know.
The Trap of Always Learning
The problem with always preparing is that there is never a clear point where you are “ready.”
There is always another course to finish.
Another framework to learn.
Another concept you don't fully understand.
Another project that seems slightly beyond your current skill level.
And because there is always something else to learn, it becomes easy to confuse learning with progress.
I've fallen into that trap myself.
I'd jump between frontend development, engineering courses, IoT, programming, and different ideas I wanted to explore. I was learning, but sometimes it felt like I was constantly starting rather than actually moving forward.
That's when I started changing how I approach learning.
Instead of asking:
“What do I need to learn before I can build this?”
I started asking:
“What do I need to learn to solve the next problem?”
That small change makes building much less intimidating.
You don't need to know everything.
You need to know enough to take the next step.
Building Forces You to Learn Differently
Tutorials are useful. Courses are useful. Documentation is useful.
But building something of your own changes the learning experience completely.
When you're following a tutorial, the path is already laid out. You know what comes next, what code to write, and often what the expected result should look like.
When you're building your own project, none of that is guaranteed.
You make decisions.
You run into errors you have never seen before.
You search through documentation.
You try something that doesn't work.
You change your approach.
Then, eventually, something works.
That's where I think some of the most valuable learning happens.
For example, while working on IoT projects, I’ve had to move between hardware and software, dealing with sensors and microcontrollers on one side and interfaces and data visualization on the other.
The interesting part isn't knowing every technology beforehand.
It's figuring out how to connect the pieces.
And every problem becomes a question:
Why isn't this working?
Then you look for the answer.
That process has taught me something important:
You don't always need more preparation. Sometimes you need a problem worth solving.
I'm Still Figuring Things Out
I don't want this to sound like I suddenly figured everything out.
I haven't.
I'm still learning how to write better code, design better interfaces, understand engineering concepts more deeply, and build projects that actually work outside of a tutorial.
Some projects will fail.
Some ideas will change halfway through.
Some things I build will probably look very different a few months from now.
And I think that's okay.
I'm sharing more of what I build because I want a record of the process the messy middle- not just the polished result.
The bugs.
The things I misunderstood.
The solutions I eventually found.
The decisions that worked and the ones that didn't.
I also want to meet other people who are doing the same thing: learning by building.
Because something is motivating about seeing someone else struggle through a problem, solve it, and then share what they learned.
That's the kind of developer and engineer I want to become.
Not someone who knows everything.
Someone who keeps building, keeps learning, and knows how to figure things out.
What I'm Building Now
Right now, I'm exploring the space where software and hardware meet.
On the software side, I'm building with technologies like React and TypeScript, learning how to create interfaces that are not just functional but actually enjoyable to use.
On the hardware side, I'm experimenting with microcontrollers, sensors, and IoT projects. That means dealing with things that don't always behave exactly as expected—which is a pretty effective way to learn.
I'm also studying Electronic and Electrical Engineering, so I'm constantly discovering connections between what I learn in class and what I can actually build.
That's probably what interests me most.
A web application doesn't have to exist completely separately from the physical world.
A sensor can collect data.
A microcontroller can process it.
A backend can move it somewhere useful.
And a frontend can turn that data into something a person can actually understand and interact with.
There's a lot I still don't know about all of this.
But that's exactly why I'm building.
I want to see how far I can go by learning one problem at a time.
So, What Now?
I don't have a perfectly defined roadmap.
And honestly, I'm starting to think that's okay.
For now, I want to keep building projects, documenting what I learn, and gradually getting better at connecting the different things I'm interested in.
Some posts here will probably be about frontend development.
Others might be about IoT, embedded systems, engineering concepts, or something completely different that I happen to be exploring.
I also want to share the parts that don't usually make it into portfolios—the debugging, the mistakes, the confusion, and the small breakthroughs that make a project finally work.
Maybe someone reading this is also stuck in the “I'm not ready yet” phase.
If that's you, I'm learning the same lesson myself:
You don't have to wait until you know everything.
Start with what you know.
Build something.
When you hit a problem, learn what you need to solve it.
Then build again.
That's what I'm going to do.
Build before I'm ready. Learn along the way. And keep going.
I'm Just Getting Started
This is my first post on DEV.to, and I think it should start here.
I'm not writing because I have everything figured out. I'm writing because I want to document the process of figuring things out.
I'll be sharing projects, experiments, lessons, mistakes, and whatever interesting problems I run into along the way.
If you're also learning to code, studying engineering, building projects, or trying to figure out how all these pieces fit together, maybe we can learn from each other.
For now, I'm going to keep building.
One project. One problem. One lesson at a time.
Top comments (0)