The Problem

I wanted to understand a circuit board product created by an electrical engineer I know. My technical background is in high level languages, and I have limited exposure to hardware and assembly. The product runs on a dsPIC microcontroller with all logic written in assembly, including Z-transform digital signal processing for line noise testing. My goal wasn't to become an expert, but to read his code well enough to appreciate what he built.

The challenge: I couldn't evaluate what I needed to learn because I didn't know the domain. Most learners in this situation pick a single comprehensive resource (a book, a course) and follow it linearly. But no single resource covered my specific path, from high-level programming background to dsPIC assembly to DSP concepts. And, importantly, because I do have a technical background including programming, there is overlap, but it's not overlap I can easily predict. I would naively need to consume full content items, whereas ideally I would focus only on the percentage of each content item that was applicable to my learning objective. Similarly, I can't know ahead of time what I am looking out for the most in a content item, i.e. the key concepts for me given my learning objective.

What I Tried

I asked Claude to build a learning plan. Rather than immediately generating a curriculum, Claude asked clarifying questions:

• Do I want to understand the "why" or treat some layers as black boxes?
• Do I learn better from theory first or hands-on first?
• How much time can I commit, and in what blocks?
• Do I have hardware access?
• Should the plan include the inventor as a resource?

This took several exchanges. Claude also asked follow-up questions when initial answers were ambiguous (e.g., clarifying whether "read and appreciate" was the real goal vs. "modify and maintain").

The Breakthrough

The resulting plan pulled resources from multiple places: Nand to Tetris for computer architecture fundamentals, Codecademy for assembly basics, Microchip datasheets for dsPIC specifics, Coursera for DSP theory, and various blog posts and tutorials. What made it valuable wasn't any single resource but the sequencing: Claude understood the dependency graph I couldn't see.

For example, the plan used x86 assembly tutorials to teach concepts (registers, stack, addressing modes) before transitioning to dsPIC-specific material, not because x86 is relevant to my goal, but because quality instructional content for x86 is abundant while dsPIC resources are sparse. The concepts transfer; only the syntax differs.

Later, when I hit a gap in my understanding of stack frames and function calls, Claude didn't just dump more resources. It asked what specifically was unclear (conceptual model vs. mechanics vs. application) and what format might help (visual vs. written). This led to targeted supplemental resources—animated diagrams of stack pointer changes during function calls—that filled the exact gap.

After working through the initial plan and gap-filling process, I realized the process itself was valuable. It's valuable not just for this topic, but for any domain where I'd face the same chicken-and-egg problem of not knowing enough to build my own curriculum. I first created a Claude Project template to capture the workflow, then worked with Claude to formalize it further as a Claude Skill. This required making explicit what had been implicit: my stable learning preferences (theory-first, visual when available, ~1 hour/day), the questions Claude should ask for any new topic, and crucially, the sequencing principles that made the original plan work. We discovered that some things I valued, like the cross-architecture resource strategy, weren't obvious and needed to be spelled out so a future Claude instance would know to do them.

What I'd Do Differently

1. Be explicit about goals upfront. I initially said I wanted to "read and appreciate" the code. Claude probed whether "modify and maintain" was the actual target. It wasn't—but that distinction significantly affected the plan's depth. I could have saved a round-trip by being clearer.

2. Verify resource access early. Claude suggested Coursera's Nand to Tetris course as "free to audit." When I tried to enroll, auditing wasn't available. Claude quickly pointed me to the official nand2tetris.org site (same content, fully free). I decided to pay for the Coursera course anyway, but I could have avoided confusion if Claude's information was up-to-date or I verified access when reviewing the plan.

3. Question recommendations before accepting them. Claude initially compressed the Nand to Tetris material to 4 modules to fit a tighter schedule. When I asked why modules 5-6 were excluded, Claude acknowledged they were valuable and the compression was a tradeoff I might not want. This made me realize I never spent time critically analyzing the plan before beginning it.

Lessons Learned

1. The dependency graph is the hard part - I couldn't build my own learning plan because I didn't know what I didn't know. The value of an expert (or Claude acting as one) isn't just knowing good resources—it's knowing the order that makes them useful. A multi-source plan with bad sequencing is worse than a single mediocre textbook.

2. Clarifying questions aren't delays, they're the work - The back-and-forth about learning style, time commitment, and goals felt slow at first. But it produced a plan tailored to how I actually learn (theory-first, hour-a-day chunks, visual when available) rather than a generic curriculum. The questions were the value.

3. Gaps are diagnostic opportunities - When I reported incomplete understanding of the stack, Claude didn't just search for more resources. It asked what was unclear and in what way. This turned a vague "I don't get it" into a specific gap (stack frames and nested function calls) with a specific format need (visual/animated). Precision in identifying gaps enables precision in filling them.

4. Reusable processes need explicit encoding - The original learning plan worked well, but the reasons why it worked were implicit. When building the Skill, I had to surface assumptions Claude had made (like using x86 resources to teach concepts that transfer to other architectures). Without making these explicit, a future Claude might not replicate the approach. What feels obvious in context often isn't preserved across sessions.