I'm a sophomore studying electrical engineering and I'm interested in going into embedded systems. I've been seriously programming for about six months. I understand the syntax of the languages I'm using, but I still struggle to break a large idea into smaller algorithms, implement each part, and connect everything together.
Online, I often see people building complicated projects or tackling difficult problems, and it makes me wonder how they reached that level. Projects that seem manageable to experienced programmers would probably take me many months, if I could finish them at all. I have several project ideas of my own, but I'm not sure whether they're currently beyond my abilities.
I'm not planning to quit programming. I'd like to understand what progress usually looks like, how much time I should practice each day, and how many months or years it generally takes to become genuinely comfortable writing programs without constantly feeling lost.
4 Answers
For embedded programming, try making small, tangible projects instead of waiting until you feel ready for a huge idea. A small computer or microcontroller with LEDs, buttons, sensors, or a motor is enough. Follow a tutorial, then change one part of it and gradually add features.
You’ll likely begin by reading and modifying existing code, which is valuable practice. Over time you’ll learn how to structure programs, debug hardware and software together, and turn a vague goal into manageable tasks. There’s no magic daily number of hours; consistent practice several times a week is more useful than occasional marathon sessions.
The timeline depends on your goals and how consistently you practice. With focused work over a few months, you can become comfortable making small programs. A year or two of regular projects may make larger applications feel much less intimidating, but you’ll never reach a final level where every problem is easy.
The important comparison is not with impressive projects you see online. Those examples often hide the author’s previous experience, research, libraries, and failed attempts. Measure progress by whether you can solve slightly larger problems than you could a few weeks ago.
There isn’t really a point where you can program absolutely anything without help. Programming is a creative skill, much like designing a circuit or writing a novel, and there’s always another language, library, tool, or problem to learn.
After six months, it’s completely normal to know syntax but struggle with designing a solution. That skill comes from building lots of small projects and recognizing common patterns. Start by writing down the problem, drawing diagrams, identifying the inputs and outputs, and splitting the work into small functions before you write code. You’ll still use documentation and search engines throughout your career—even experienced programmers do that constantly.
Think of fluency as knowing common tools and patterns well enough that you can focus on the problem instead of looking up every basic operation. Loops, conditionals, functions, data structures, debugging, and basic algorithms are the foundation, but fluency develops gradually through repetition.
You don’t need to implement everything yourself. Using a reliable library is usually the right choice unless your goal is specifically to learn how the underlying technique works. Build small projects, revisit old code, and increase the difficulty one step at a time. Even experienced developers regularly consult documentation and examples.
The advice about planning with notes and diagrams makes sense. I’ve been trying to jump straight from an idea into code, which probably makes the problem feel much larger than it really is.