Course Notes

What I Actually Mean When I Say 'Welcome'

The thinking behind a course that keeps changing, and why I show up on camera to say so myself

A short welcome message can carry more weight than it looks like it does. Here's what I'm really promising when I tell new students the course covers both the essentials and the bigger picture — and why I never treat the material as finished.

Two promises, not one

Every time someone opens the app for the first time, I'm making two promises at once, and I think it's worth separating them because they pull in different directions.

The first promise is narrow and practical: you will get what you need to pass the test. That sounds obvious, almost too obvious to say out loud, but I say it anyway because it's easy for a course to drift away from it. Content creators — myself included — get excited about tangents, interesting edge cases, historical context, the stuff that makes a subject fun to teach. None of that matters if a student walks into an exam room and doesn't have the specific tools they need in front of them. So the first promise is a floor. It's non-negotiable. If a piece of content doesn't help you clear that bar, it doesn't belong in the course, or it belongs somewhere clearly labeled as optional.

The second promise is broader and harder to measure: you'll come away with an actual understanding of the subject, not just a memorized checklist. I call this the 'big picture' because that's genuinely how I think about it — not as a nice-to-have, but as the thing that makes the first promise durable. Memorized checklists decay. They fall apart the moment a question is phrased slightly differently than you expected, or the moment you need to apply the material outside the test itself, in whatever comes after it. Understanding doesn't decay the same way. It bends instead of breaking.

The reason I open with both of these, right at the start, is that I want you calibrating your expectations correctly from lesson one. If you came here purely to cram, you'll get that, but you'll also get more than that whether you asked for it or not. And if you came here for a deeper understanding of the subject, you don't have to worry that the exam-focused material is going to feel like a distraction — it's built to serve the same goal.

Why I refuse to call this course finished

I don't think of this course as a fixed product that got shipped once and now just sits there. I think of it as something closer to a living document — it changes based on what I hear from the people actually using it.

That might sound like a hedge, like I'm leaving myself room to fix things later instead of getting them right the first time. It's not that. It's an acknowledgment of something true about teaching any subject that has a real test attached to it: the test changes, the way people struggle with the material changes, and my own understanding of how to explain something changes the more times I explain it. A course that never updates is quietly calcifying even if nothing about it looks different on the surface.

So when community discussion surfaces a place where an explanation didn't land, or a topic that needs more depth, or a question that keeps coming up because I didn't cover it clearly enough the first time, that's not noise to be filtered out — that's the input the course is designed to respond to. I'd rather have a course that's a little rougher around the edges today and demonstrably getting sharper over time than one that's polished once and then frozen.

There's a practical implication of this for you as a student: what you're watching and reading right now is not necessarily identical to what someone using this course a few months from now will see. That's by design. It also means your own feedback, if you choose to give it, isn't going into a void — it's one of the actual inputs that shapes what gets added, cut, or rewritten. I'd genuinely rather hear that something confused you than have you quietly struggle through it and assume that's just how the material is.

The test is the floor, not the ceiling

I mentioned this earlier, but it's worth sitting with a bit longer because I think it's the single most important framing decision in how this course is built.

It would be easier, in a lot of ways, to build a course that only targets the test. Narrower scope, more predictable structure, easier to measure success — did you pass or not. But I've found that courses built exclusively around test mechanics tend to produce a specific kind of fragile competence: people who can answer the questions they've been drilled on but freeze when a problem is framed unfamiliarly, or who pass and then realize a month later that very little of it actually stuck.

The big-picture material isn't extra credit sitting on top of exam prep. It's structured to be the thing that makes the exam prep actually work. When you understand why something is true, rather than just that it's true, you stop needing to memorize as much, because you can reconstruct the answer from first principles when your memory doesn't serve up the exact fact you crammed. That's a more resilient way to walk into a test, and it's also the only version of 'knowing the material' that's worth anything once the test is behind you.

I want to be honest that this approach asks a little more of you upfront. It's tempting, especially early on, to want the fastest possible path to the specific facts that show up on the test. If that's genuinely all you need, the essentials are there and clearly identifiable as such. But I'd encourage you not to skip past the conceptual material just because it doesn't look like it's going to be on the test directly. In my experience, it usually is on the test — just not in the form you'd expect.

Why I show up and say my name

It would be simple enough to open this course with a title card and some onboarding copy instead of a person talking directly to camera. I chose not to do that, and it's worth explaining why, because it's not just a stylistic preference.

A course is only as good as the trust a student is willing to extend to it, especially in the early lessons before there's any track record to point to. That trust is easier to build with a person than with an interface. When I introduce myself by name at the start, it's partly just practical — you should know who's talking to you — but it's also me putting my name on the material in a way that a faceless app doesn't. If something in this course is wrong, unclear, or out of date, that's on me, not on some anonymous content pipeline. I think that accountability matters, and I'd rather you know from the first minute who's responsible for what you're about to spend your time on.

It also sets the tone for everything that follows. This isn't meant to feel like a static reference manual you're working through alone. It's meant to feel like being walked through the material by someone who's thought carefully about how to teach it, who's actively paying attention to how it's landing, and who's reachable if something isn't working. That's a different relationship than the one you have with a textbook, and I think it changes how people actually engage with the content — you're more likely to ask questions, flag confusion, and stick with it when there's a person on the other end of it rather than a black box.

What feedback actually changes

I want to be specific about what 'community feedback shapes the course' means in practice, because it's the kind of line that's easy to say and easy to gloss over.

It means that when enough people flag the same sticking point — a lesson that consistently confuses people, an explanation that technically covers the material but doesn't actually click — that's a signal to rework it, not just annotate it with an addendum. It means that questions that keep coming up in discussion are a pretty reliable indicator of gaps in the course itself, not just gaps in any one person's preparation. And it means the order in which topics get expanded or deepened isn't purely my own judgment about what's interesting — it's informed by where real students are actually getting stuck.

This only works, though, if people actually participate in it. A course that's designed to evolve with feedback but never receives any feedback just ends up evolving on my assumptions alone, which defeats a lot of the point. So if something in a lesson doesn't make sense, or if you find yourself needing to look up an explanation elsewhere because the one here didn't land, that's worth saying somewhere I can see it. You're not just asking for help for yourself in that moment — you're contributing to what the next student sees.

I'd also gently push back on the instinct to assume your confusion is a personal failing rather than a course problem. Sometimes it is just a matter of needing to sit with something longer. But often, if you're confused, other people are quietly confused in exactly the same place and just haven't said anything. Speaking up closes that gap faster than anything else I can do from my end.

Conclusion

None of this matters much as a philosophy on its own — it only matters once you're actually inside the material. So the natural next step is simple: open the first lesson in the app and get started. And whenever something along the way feels off, unclear, or worth flagging, drop it into the community discussion. That's not a formality — it's genuinely part of how this course gets better.

KEEP PRACTICING THE DECISION

Learn the concept, then test the edge case.

The Solutions Architect Associate course in TutorialRepo combines guided lessons, scenario questions, review, and course-aware explanations.

  All articles