What beginners get wrong about CAD first
The single conceptual gap that causes most early confusion.
What beginners get wrong about CAD first is treating it like a drawing tool that records a final shape, when it is actually recording a sequence of operations that built that shape, and every later confusion, a feature that will not edit, a change that breaks something unrelated, traces back to that one misunderstanding.
Writing a short course for people who had used neither CAD nor simulation before turned out to be the fastest way to find out what a beginner does not yet understand, since every question they asked exposed an assumption an experienced user had stopped noticing they were making.
Photos on a corkboard, blocks in a tower
Photographs pinned freely on a corkboard can each be moved, resized or removed without disturbing any of the others, since no photograph's position depends on where another sits. A tower of stacked wooden blocks behaves differently: pulling out or resizing a block near the bottom shifts, tilts or drops every block resting above it, because each block's position depends on the one beneath.
A CAD model behaves like the tower, and a beginner who has only used corkboard-style tools, where objects can be nudged or deleted with no consequence beyond themselves, brings exactly the wrong intuition to software built around dependency. Showing a beginner the tower before they touch the software, and asking them to predict what happens if the third block from the bottom is pulled out, gets the right instinct in place faster than any number of worked examples inside the CAD package.
A model that replays itself every time it opens
A CAD model is a recorded sequence of steps (extrude this sketch, cut this hole, add this fillet), each one built on the geometry the step before it produced. The software replays that entire sequence from the beginning every time the model is opened or changed. Editing an early step therefore changes the starting point that every later step was built from, and each of those later steps has to be recalculated against the new shape.
The discovery that one early change can ripple forward and break a dozen later features, sometimes for reasons that are far from obvious, is usually the first truly confusing moment in learning the software. Explaining that behaviour before it arrives as an unexpected error message spares a beginner the sense that the software is being unreasonable.
A wall of errors after one small edit
In a moderately complex model, a single sketch near the base of the history can sit underneath dozens of later features that depend on it directly or indirectly. Changing it forces the software to recalculate all of them in one update, and any one that fails to rebuild cleanly is reported as an error, however small and reasonable the original change was. If a hole twenty steps up the tree was positioned from an edge that the change removed, that hole fails, and so does every feature that referred to the hole. A beginner staring at a screen full of warnings is usually looking at a dependency chain doing exactly what it was designed to do.
Seeing the model this way changes how it should be built from the first lesson. Features likely to change later, such as a hole's size, a wall's thickness or a bracket's overall length, are worth placing early and deliberately, with the rest of the model built to depend on them cleanly, so that a later change ripples forward predictably instead of catching something unrelated. That shift in mental model, from the finished shape to the tree of steps underneath it, resolves more early confusion than practice with the individual tools does.
Where the tower picture overstates things
Some features in a model are independent of one another. A decorative chamfer on one edge and a hole on a separate face rarely have any real relationship, and treating every pair of features as linked invites an over-cautious paralysis that slows a beginner down without protecting anything.
The tower analogy also has a limit the model does not share. A well-built model can be organised so that unrelated groups of features sit on separate branches of the history, with a change to one branch having no effect on another, which a physical tower has no way of doing. Recognising which features are truly dependent and which merely happen to have been built one after another in the same file is a skill that develops after the basic idea has settled, and rushing a beginner towards that finer distinction too early usually causes more confusion than it resolves.