For the first six months of my career, I treated CSS layout as a kind of dark art — a discipline where you tried combinations of properties until something worked, then immediately committed the result before it could break. Flexbox was the worst offender, because the documentation described properties like `justify-content` and `align-items` in terms that assumed you already understood the flex model, which I didn't. I could center a div by following a recipe, but I couldn't explain why the recipe worked, and that meant I couldn't adapt it when the layout requirements changed even slightly.

The breakthrough came when someone drew the flex container as a row of boxes on a whiteboard and showed me that `justify-content` distributes space along the main axis and `align-items` distributes space along the cross axis, and that which axis is "main" depends on `flex-direction`. That single distinction — main axis versus cross axis, and the recognition that `flex-direction` swaps them — collapsed months of confusion into five minutes of clarity. Everything else about flexbox is a variation on that one idea, and once I had the mental model, the property names stopped feeling arbitrary and started feeling descriptive.

The lesson I took from that experience is that conceptual models matter more than property references. A cheat sheet of flex properties is useful once you understand the model; before that, it's just a list of magic words. When I mentor junior developers now and they're struggling with a technology, I try to identify the conceptual model first — the one insight that makes everything else make sense — before diving into syntax or properties. It's harder to do than to describe, but the payoff is the difference between someone who can use a technology and someone who understands it.