When you've worked with a concept long enough, there's a gap that can quietly open up between "I know how this works" and "I can explain exactly why this works, including the edge cases that trip people up." Writing a tutorial closes that gap fast — readers will hit exactly those edge cases, and a good article needs to anticipate them.
Before publishing the article on Swift function parameters — external vs internal names, the _ underscore, default values — I ran a quick exercise: a batch of small function snippets, some valid and some subtly broken, each one checked line by line. The goal wasn't to test whether I understood parameters — it was to stress-test the explanations themselves, and make sure they'd hold up against exactly the kind of "looks right but isn't" code a learner might write. 🍥
Why Bother With This, If the Concept Is Already Familiar
Knowing a rule and being able to anticipate every way someone might misapply it are different things. Parameter labels are a great example — the rules themselves are short, but the ways they interact (single name vs two names, _ vs labeled, what happens at the call site vs inside the function) create a surprising number of combinations. Going through deliberately-broken snippets is a fast way to make sure an explanation covers the combinations that actually confuse people, not just the ones that are easy to describe.
