Thirty Two into Sixty Four?

This unit in class, we learned about bits. How certain variables require certain amounts of space, and how bits quantify that amount of space. To most people in the classroom, those concepts seemed intuitive. Everyone nodded their head along with the presentation, and no one asked any clarifying questions. I however, was clueless. I had no idea how why mod existed. So I stumbled through the first problems of the worksheet, trying to sort things out in my head, and to make some sense out of the conflicting rules in my head. "Why could a int fit into double, but not double into int." I knew what the answers were, but it was only through a knowledge of other examples. I didn't have a rule that would help me actually understand why concepts were the way they were. I ended up scribbling some answers down (I know no one else does this), and praying that some of them were correct. If someone had asked me why I had answered what I did, I honestly would not have been able to defend my answers.

When I got the paper back, I was relieved to see that only three or four problems were marked incorrect. Mostly, I had missed the questions that had required casting. When Mr. Stephen (fake named used for anonymity) walked past with our worksheets, I asked him questions (these questions were relevant). He reexplained the box analogy, how a variable could store something, akin to a box, and how each variable was sized differently. That was why the data stored in a double (64 bit) variable couldn't fit into a int (32 bit) variable. The box example really made sense the second time around, and I appreciated the time time my teacher took to reexplain it.

To be honest, I think the best thing a student can do is to ask questions. It's a powerful tool to keep a student engaged with the lecture, and it often snatches extra knowledge for the student. All it takes is the courage to ask. That's programming with panache.