Prep tools: Explain it back to someone

certskills
By certskills June 28, 2011 07:32

A few weeks back, my daughter had a day off from school, and was sitting with me at the coffee shop while I was writing up a blog post about Frame Relay. For fun, I let her help me by typing while I dictated the post. Unknowingly, she piped in doing some active listening – essentially repeating back and questioning what I said by way of confirming and refining what I had said. By the end of the post, she had the basics of Frame Relay down, at least as much of it as a 10-year-old might care to know.

Silly, meaningless anecdote? No. I think it’s another tool that you can use to help yourself study. Today’s post in the next installment in an occasional series about study tips, specifically that you can learn a lot by preparing and giving a short presentation on the topics about which you study.

The idea is a little like Toastmasters, but with the focus on content rather than delivery. Toastmasters is a club you can join to work on your presentation skills, where you get the opportunity to practice both prepared and impromptu speeches. So, what should we call the type of exercise I suggest today? Well, help me come up with a good name! I’m thinking it’s something like toastmasters for CCNA study, but that’s obviously an unwieldy name.

Here’s the idea. Pick a topic you are studying, any topic. Then pick someone you know who’s willing to listen for say… 2 minutes. Or 1 minute, or 3, but a small amount of time. Your spouse, significant other, kid, parent friend, co-worker, online contact, whatever. Anyway who’s willing to listen.

You job? Explain the topic, with two overriding goals:

1) they understand, and

2) you are accurate.

Let’s break down those two requirements in more detail. You must make this person, someone who may not understand anything about networking, to understand the concept. That’s a challenge. During your 2 minutes, you will want to go back and explain prerequisites. But when preparing, make yourself find a way to concisely get the basics across. That process exercises your brain in ways that typical read/absorb/recite/drill activities do not. (Learning theorists sometimes call this a “connect” activity.)

Goal 2: Be accurate. Duh, right? No. You can’t simplify to the point that your explanation is no longer true. The big learning point is that when preparing, if you’re unclear about some point, it’s tempting to gloass over it and describe it generally. Don’t. You know when you get a catch in your gut that tells you that you’re unsure whether something is true. And sometimes you don’t realize it until you’re three words into a sentence, and you don’t 100% believe it yourself. Part of the point of this exercise is to recognize when you’re unsure, and dig deeper.

There are no formal rules, but here’s the basic idea:

  1. Pick a topic that can be explained, with no interruptions, in 2 minutes.
  2. Prepare to explain it any way you like. Outline, scribbles, draw, prepare examples, create analogies, whatever. You don’t have to spend a ton of time, but do prepare, because that’s part of the learning.
  3. Practice it a time or two
  4. Write down the specific terms that you plan to use, PLUS the specific technical terms hidden behind the simpler terms or descriptions you will use
  5. Get your learner to sit and listen (and time you), and go for it!

What do you think? Good idea, or bad? Have you tried something like this?

Do you want to try it? I’m swamped at work right now, but if you want to try, and say write down your outline here, I’ll pop in and comment. And you can tell me what discoveries you made through the exercise. Here’s a sample topic, 2 minutes, and the audience is your spouse/sig other/friend who can use a computer, but isn’t an IT person.

You have three PCs (A, B, and C), each connected to switch SW1. Pick one position, and explain why it’s true: “collisions can/cannot occur in this small network”.

Enjoy!

Answers: How Many Subnets/Hosts 2
Subnet Design Exercise
certskills
By certskills June 28, 2011 07:32
Write a comment

2 Comments

  1. cdowis October 16, 22:36

    Collisions can occur when you first initialize the switch, until the MAC address table is built. The packet from one port will flood the other two ports on the first packets until the switch recognizes the source address on each port. Once the MAC table is complete there will be no collisions since the switch will only send a packet to the port for which it is intended.

    Reply to this comment
  2. Wendell Odom of Certskills October 17, 15:17

    Hi cdowis,
    Thanks for playing! It’s been a while since I posted this, but I’m glad someone noticed and gave it a shot. I’ll also kick it around my fledgling Facebook page, and see if there are any takers there.

    First, I thought your explanation was clear. I don’t say that just to be nice – part of the point of the exercise is to practice how you’d word it to clearly state and make your point, so I think I understood you pretty well.

    I have two issues with what you wrote content-wise, one conceptual, and one a minor terminology point. First, there should still be no collisions in this network. I think the big idea that you maybe didn’t consider is that a switch buffers the frames to avoid collisions, which is how a switch creates a collision domain per port.

    For instance, say all 3 PCs sent a frame at around the same time. The switch might get the first frame, and think “flood this frame” (as you correctly stated). But the switch, if running half-duplex on the other ports, would choose to buffer (aka hold in memory) the frame until the port wasn’t busy. So the lack of MAC table entries, and the flooding that occurs as a result, doesn’t cause collisions down the road.

    Lastly, you used the term “packet”. This is a picky comment, but that’s the point of the exercise… when talking about the data including the Ethernet header and trailer, which is what the LAN switch cares about when forwarding, it’s more typically called a “frame”. If referring to the entity that begins with the IP header, conceptually omitting the Ethernet header/trailer, we use the term packet. Again, I know what you meant, just making that as a suggestion.

    Thanks for playing! Try again, follow up, or someone else ready to take a try?
    Wendell

    Reply to this comment
View comments

Write a comment

Comment; Identify w/ Social Media or Email

Subscribe

Subscribe to our mailing list and get interesting stuff and updates to your email inbox.

Thank you for subscribing.

Something went wrong.

Search

Categories