Crawl. Walk. Run.

When I was teaching my son to drive, there were moments when I just said, "Do it this way. Trust me." Not because I didn't have a reason. I had plenty of reasons. But explaining reaction time, blind spots, braking distance, and the fact that half the drivers on the road are texting while eating a taco is not what you do while a brand-new driver is merging onto a busy road. Sometimes the lesson isn't a lecture. Sometimes the lesson is, "Keep both hands at 9 and 3. Start braking sooner than you think. Trust me."

I used to run into the same thing when I taught piano years ago. I'd tell a beginner, "Start with your right thumb on middle C." Why? Because just do it. There are theoretical reasons. Hand positioning. Muscle memory. Efficient movement across the keyboard. But on Day One, they don't need a dissertation on biomechanics and music theory. They need a starting point that works. Later, when they've played a few songs, the why becomes obvious.

That's exactly what happens in my beginner Access classes.

Sometimes I say, "This is the way we're going to do it. Trust me." And occasionally someone thinks I'm being mysterious or holding something back. I'm not. I'm compressing thirty years of experience into a simple rule so we can keep moving forward without falling into a rabbit hole.

Take field names. I tell beginners: no spaces in your field names. Could I explain how [Order Total] turns into a bracket jungle in SQL and VBA? Could I show you how forgetting those brackets breaks your code and how dynamic SQL strings become a pain in the butt to debug? Absolutely. But if I stop in Beginner 1 to unpack parsing rules and name resolution, I'll lose half the class before we even build our first form. So the rule is simple: no spaces. Later, when you're writing advanced queries, you'll suddenly think, "Ohhhh. That's why."

Same thing with Lookup fields in tables. Access makes them look friendly. Helpful, even. But they hide what's really going on under the hood and can cause confusion when you start building queries. Explaining that properly requires understanding relationships, joins, and how Access stores the underlying key value. So early on, I just say, "Don't use Lookup fields in tables. We'll handle that with proper relationships and combo boxes." Trust me.

Every table gets a primary key. Yes, even your tiny two-table database. The deeper conversation involves indexing, performance, referential integrity, and updatable recordsets. That's not Day One material. Day One material is: every table gets a primary key. Period.

And don't name your field Date. Or Name. Or any other reserved word that seems harmless until Access decides to interpret it as something else and your query starts acting like it's possessed by a mischievous tribble.

This is all part of how I teach. Most reference books are depth-first. They'll give you everything there is to know about tables in one giant chapter. Every property. Every data type. Every obscure option you may never use. Then they move on to queries and do the same thing. That's great if you're using it as a reference manual. It's not great if you're brand new and just trying to build something that works.

I prefer a breadth-first approach. A little bit about tables. Then a little about queries. Then a form. Then a report. Then we circle back and go deeper. Crawl. Walk. Run. You can't appreciate composite keys until you've actually built something simple and felt the limitations. You can't understand why I'm picky about naming conventions until you've written enough code to see how small decisions ripple outward.

Even Starfleet works this way. They don't hand a brand-new ensign the warp core schematics and say, "Here, memorize every plasma conduit." They teach fundamentals. Procedures. Protocol. Later, when Geordi starts talking about phase variance in the EPS grid, it makes sense because the foundation is there. If Captain Picard says, "Make it so," you don't demand a 20-minute explanation while the Romulans are decloaking. You execute, and you understand the nuance later.

When I say, "We'll cover that in a future lesson," I'm not dangling an apple in front of you. I'm building scaffolding. Your brain needs structure before it can handle the details. If I try to teach every nuance of field-level properties for long integers in the first hour, you won't retain it. You'll just be overwhelmed.

So yes, sometimes you'll hear me say, "This is the way we're doing it. Trust me." That's not ego. That's pattern recognition earned over decades of building databases, fixing broken ones, and answering the same painful mistakes over and over again.

There's a time for nuance. There's a time for deep dives. And there's a time to keep your hands on the wheel, your thumb on middle C, and just follow the process.

Crawl. Walk. Run.

And I promise, we'll get to the warp core later.

LLAP
RR

P.S. See also: Covered in a Future Lesson