This site is devoted to a discovery of how we learn, how knowledge, skills, and behaviors are transmitted from person to person.
Direct instruction has been taking some friendly fire lately from constructionism, embodied cognition, and other learning theories. But rather than discard instruction as an antiquated mechanism of facilitating learning, let’s increase its value beyond repute. Back when I was teaching math and science to high schoolers, I came up with a brilliant idea. OK “brilliant” may be a bit of a stretch. Let’s say it was a good idea. An idea that, when put into practice, yielded excellent results. And I’ve been applying this idea ever since.
Whenever I have to teach a skill, host a discussion, or provide direct instruction, I start with a presentation of the material. Perhaps it’s a specific type of problem solving technique applied to a set of algebra problems, or a programming concept like for loops, or even a debate on the existence of learning styles. I would start with a demonstration, a walk-through, or a presentation of both sides of the argument. This is step one.
Step 1: Be the star. Be the guide that shows your learners the way. Be the trailblazer that lets them know what’s possible or the set the direction along which you want them to travel.
I will follow this by creating groups of 4. I have each group continue from where I left off. Maybe it’s a similar problem I have them solve together. Maybe it’s taking sides in the debate. In any case a group of four can help individuals generate their own line of thinking as well as give them an opportunity to absorb and interpret the thinking I just demonstrated. That’s step two.
Step 2: Form groups of four. Stimulate conversation, the exchange of ideas, and learner collaboration. Give the quiet ones a chance to listen a little longer. Give the vocal ones a chance to talk their thoughts out in a more intimate setting.
Now it’s time to shrink the groups. Give Vygotsky’s ZPD a chance to really take effect, and the quieter learners a chance to ask some questions or explain their understanding. Step three is all about the power of two.
Step 3: Create pairs of two. In pairs, the learners have one more chance to work through a problem or solidify their thinking. More experienced learners can lead less experienced ones to a deeper understanding and achieve one of their own along the way. Pairs also help learners identify their shared points of confusion and articulate them to the facilitator. It can also be a great way to help those in confusion not feel like they are the “only ones who don’t get it.”
In order to give learners the chance to establish confidence and independence in the skill they are working on or the conversation they have been engaged in, we end with solo work.
Step 4: Establish the power of one. Have learners solve a problem on their own. Have them write down their opinions. Have them do any activity that gets them to reflect on their group work and the facilitator’s instruction. Make sure it’s an exercise they can keep working on if they need more time, one whose completion provides a clear indication to everyone (including themselves) that they have learned what you attempted to instruct them on.
That’s it. Start with a “sage on the stage,” move to groups of four, then two, then one. I call it *421, and it works for almost any topic, giving learners access to information, and a chance to practice applying that information multiple times. Use instruction to promote practice, and you’ll never have to worry about droning on while your audience tunes out.
**For bonus points, try *421 in reverse and let a learner be the star. Mix it up. Have fun. Just remember to dial *421.
Sorry, I just couldn’t help myself.
Recently I had an “unpacking session” with an expert web developer. An unpacking session is when a learning expert and a domain expert get together and try to unpack the hard-wired skills and strategies that the domain expert does without even thinking about. The idea is to tease apart the steps of a process that is not obvious to beginners and has become a nearly invisible routine for the domain expert. Through dialogue, diagram, and concrete examples, the process is made more accessible to novices, in other words more “learnable.”
Now other would-be web developers can study and practice the craft of troubleshooting and debugging web development code. And it all starts with three little questions.
Question 1: What do I know?
Ask yourself this question to get started. As novice coders when we get an error message or we see a bit of code that doesn’t make sense, we have the tendency to gloss over it, quickly hacking at a potential solution (without even diagnosing the problem), performing a GCP (google, copy, paste) or skipping it altogether and moving on to the lines of code we do understand. The problem with this strategy is it does not help us form connection between what we do know and the mysterious new method, message, or syntax.
We must pause and ask ourselves: What do I know about this line of code or error message? What references do I understand, what syntax is familiar?
Question 2: What don’t I know?
On the other end of the spectrum, we sometimes have the tendency to gloss over unfamiliar code and seek out only that which we understand. We slip past strange syntax and try to guess at what’s going on from the keystrokes we actually understand. Unfortunately, this too can keep us from making connections that help us build on our learning. In an effort to learn from context rather than content, we find ourselves not truly understanding how a piece of code works very deeply or being able to replicate it on our own.
The point of clearly articulating to ourselves what we know and what we don’t know is to make a distinction between the two. We want to ADD distance in our knowledge gap so we can spend a little time forming a connection that bridges that gap. Like building a real life bridge, it helps to know where you’re starting and where you’re going, in fact, it’s required! Give your brain two endpoints. Point A: what you know. Point B: what you don’t. Then you’re ready for question three.
Question 3: How can I connect what I don’t know to what I know?
Once you have two points of knowledge (a known and an unknown), you can start working on connecting them. This is where we have to get super specific to the resources available to us and our particular domain of study. For the web dev expert I was unpacking with (@JeffCohen), the sub-domain (Ruby on Rails) was also important to his process. Here’s what he offered…
Step 1: Default to IRB (Interactive Ruby Shell) Most lines of Ruby code can be toyed with using IRB and the learning experience (knowledge bridge) is much stronger than a random google search might yeild.
Step 2: If the unknown is Rails specific, try playing around in console. IRB won’t help with Rails, but console will. Try inputting your mystery code and seeing what happens.
Step 3: If it’s an unknown (or unfamiliar) method, Go to the guides. Ruby and Rails both have extensive online documentation. Other resources to investigate include gem documentation, gem code, your coding peers and community, and Uncle Bob.
Only after exhausting steps 1-3 does he then go to Google or try to find something on Stack Overflow. So for those out there who are going straight to Google, you’re missing all the valuable bridge-building, knowledge-making learning opportunities that an expert uses to improve his practice. Try making Google your LAST resort and see what connections you can construct between what you know and what you don’t.
And for those of you who aren’t studying Ruby on Rails, or even programming, try applying the three questions to whatever you’re learning and let me know how it goes. For more on this type of learning check out Piaget’s work on Assimilation.
WARNING: After reading this blog post you will have no more excuses not to blog. DISCLAIMER: I’m writing this blog post so that I will have no more excuses not to blog.
OK now that that’s out of the way…
The purpose of this blog post is to give you an understanding of what the science has to say about the value of blogging in the learning process.
The knowledge needed to understand this post:
First, what is a blog?
Let’s say a blog is a modern day version of a diary or journal. You write down your thoughts, you read them over again, you store them, you share them with others (or not). The difference between a blog and a journal is that with a blog, you’re using computer software to keep track of certain attributes of your entries (called “posts”) like the time, date, and the thematic elements (called “tags”).
Second, if you haven’t read some blogs, go read some now.
Notice that you can skip around, read a post, read another post. Some blogs let you search by tag, others let you do a word search that will look at every post and return only the ones that contain that word. These features are critical to understanding some of the learning values of keeping a blog.
So why blog?
Well, whenever you’re learning something new, (and if you ask a Learning Scientist like me, you’re ALWAYS learning something new, whether you’re trying to or not) blogging offers you the following advantages:
A blog represents your own personal learning map.
A blog can serve as a representation of the work you’ve done and the knowledge you’ve practiced using. It’s like the ancient explorers who made the first maps. When you’re learning something new, you’re charting unknown territory, and writing a blog can give you, and others, an understanding of the landmarks, the features, and the terrain of the new world you’re exploring. And, as mentioned above, you can search for these features on your learning map by simply typing a related word or phrase into your search bar. Like having a google for your own brain!
A blog makes a great memory trigger.
Have you ever looked at a calendar and realized it’s someone’s birthday. You end up thinking about that person, maybe you send them a card or email, maybe you just reminisce about the last time you saw them. Suddenly you’re feeling connected to them without even having seen them or talked to them. Re-reading your blog posts can trigger a reconnection between you and what you’ve learned. It can remind you of the things that you know and help you avoid forgetting them. If you read through your past blog posts every couple weeks, months, or even years, you can be instantly connected to the thoughts and feelings you had when you wrote those posts. The beauty about this is that you wrote it, so you’re speaking to yourself. You don’t have to try to interpret someone else’s thoughts because you’ve already done the work to interpret your own. It’s like keeping a calendar with the birth dates of your thoughts, all you have to do is scan through it and those thoughts are yours again to remember, reflect on, revel in, and build upon.
Articulation cultivates conceptual growth.
Have you ever thought you’ve understood something, then tried to explain it to someone else, only to get tongue tied and start feeling like maybe you don’t really know it at all? Blogging saves you having to go through that while someone’s watching. Instead you just do it on your own time as you try writing your blog. By trying to explain what you know and what you’ve learned, you will build a better understanding of it as you are forced to convert the thoughts in your head to words on the web. Forcing yourself to articulate what you’re working on will also help you identify what you thought you knew but really don’t.
Keeping a blog improves your ability to communicate with others in a new domain.
Just as articulating your thoughts helps you refine and build on them, it also helps you learn how to communicate those thoughts with others. As you begin to hear a new vernacular (or jargon) that has meaning within a certain context (or domain) you at first will feel unsure about the full meaning of some of these unfamiliar or altered words. For example, when you first hear about arrays, hashes, and persistence in software development, your depth of understanding is small and you may not use those words appropriately. However, as you begin to form sentences in which you put those words in context, often defining them in your own natural language, you become more skilled and confident in their use. Conversations with experts start becoming intelligible to you, and you can even start chiming in without fear of sounding foolish.
Writing blog posts help you identify effective strategies.
As you reflect on your learning process as well as the content of what your are learning, you will discover that the actions you take are appropriate under certain conditions and not in others. Looking back, you will begin to notice when a certain strategy was effective and when it wasn’t. You may even be inspired to think up new strategies that you can apply going forward. In other words, by writing your blog you’re becoming a wiser practitioner of your craft.
Keeping a blog helps you identify areas for growth and motivates you to pursue them.
Writing about what you’re learning is bound to fill you with desire. New questions arise, sticking points become more obvious, and your goals for learning what you’re learning are pushed to the forefront of your mind. This is your opportunity to inspire yourself to continue your development. Use your blog to seek out what your want to focus on and why you want to focus on it. The more you do this, the more you customize your learning path and reap the benefits of your own natural curiosity and insight.
So there it is. Six reasons to blog. Now I’m inspired. I think I’ll start on my next post. How bout you?
ps. If you’re reading this, and you don’t yet have a blog, it’s really easy to start one. Just click on the button on the top right of this page, the one that says “join tumblr.” (I don’t work for them, I just like their blogging service, and it’s really easy to get started with.) Happy blogging!
One thing I wasn’t prepared for when I took up learning how to code, was how confusing one simple letter would end up being. When defining a set of rules for the processor to carry out (referred to as a “method”) whether you use the plural or the singular of your method title can make all the difference. Who knew that keeping track of that one little “s” would be so tricky.
What I discovered is that the computer trying to interpret your code sometimes understands the relationship between a singular and a plural instance of a word, and sometimes it doesn’t recognize their relationship at all. This makes it very confusing for a human like myself who ALWAYS will connect a singular with a plural in meaning if not context.
Take for instance the crafting of a list of train stations. If I define the singular “station” as one of my variables, then I have to be consistent within anywhere from 4 lines of code to 4 different files of code depending on what kind of variable I’m defining. However, if I then type the plural “stations” somewhere in the same code then I might think I’m telling the computer to simply consider all my stations, but most likely I’m simply defining a completely knew variable. The computer will not relate “station” with “stations” no matter how similar they seem to me. I might as well have used the words “station” and “weasels.”
So if you’re ever learning to code and you find yourself struggling to match the labels you’re assigning to each of your variables, remember NOT to think of two things as similar just because they share every letter except that pesky little ‘s.’
One thing you might try is making the s at the end a different color in your text editor, or capitalizing it, or making it a different size font. Basically anything you can do to visually remind yourself that the plural is not the same as the singular (and often not even interpretable as similar by the computer you’re talking to), the better your chances of managing your errorS.
Whenever you’re learning something new, it’s not just about picking up new knowledge, new skills, or new mentors. There’s also a subtle, but important shift in how you process words.
Take the word: “class”
The first time you heard this word it might have been in reference to a classroom. You may have even been sitting in one when you learned it. As you got older, you discovered other meanings of the word class. There are plenty. Economic class is different than Econ class is different than Kingdom, Phylum, Class,…, which is different than the stylish, polite kind of class a gentlemen shows when he opens a door for a lady. And all of these are different than the class of stars in Stellar Evolution class.
When learning to program in Ruby, there is apparently a new definition of “class” that one must now learn in context. As far as I can tell, it’s a type of container for instructions (called “methods”) and is meant to give programmers the power to make up their own sets of instructions to assign to a computer processor.
So why do I bring up all these classes? To talk about context.
Learning is not always about discovering something new. In fact more often than not it’s about reshaping something old. Like adding to the multiple contexts in which the word “class” has meaning for you, learning is about taking what you already know and reworking it until you can comprehend something you didn’t.
Our brains are designed to “build” (programmers might say “stack”) content, context, cognition, and understanding on top of what we’ve already learned. We can help ourselves with this process by using analogies, stories, and abstractions to take what we understand and reframe it to understand even more. It’s like building a house, then adding another wing, then adding a roof deck, then a patio, etc. And just like that ever-expanding house offers increasingly varied opportunities to entertain and shelter people, one’s ever expanding learning offers increasingly varied opportunities to entertain and shelter thoughts.
So now I’m in class with the rest of my class, learning about how to construct a class to help me develop a new class of web application.
No matter what happens, this won’t be the first or the last time I reconstruct what I know to lay the foundations for what I want to learn. Nor will this be the first or the last time I use a lot of words to say something relatively simple. But in this context, I’m sure you’ll agree it’s sometimes better to be talkative than terse.
The world of academia is often considered by outside observers as “heady,” pretentious, disconnected, argumentative, venerable, and powerful. It remains America’s last competitive advantage over other rising national powers, yet these words hardly describe its people or its communities of practice.
Now that I’ve had the opportunity to become a participant in Northwestern University’s founding program in the Learning Sciences, I have witnessed many communication structures that may at first seem to elicit descriptions like the ones above, but upon further consideration serve to illustrate a thoughtful, respectful, and locally involved culture. Let me explain.
When you attend your first lunchtime guest speaker session (referred to as a “brown bag”), you immediately notice that the front row is reserved for professors, and students sit mostly with their “cohorts” (composed of fellow students who started in the same academic year).
There are no markings to indicate these reservations or guide students to “clump” in this manner. It is simply unspoken and observed.
Then the talk starts, and everyone is quiet. Questions rarely get asked during a visiting speaker’s presentation. If there are clarifying queries, they are not voiced. In fact everyone is quiet and attentive (except for the occasional smart phone glance or laptop email check). It’s when the speaker finishes that the real interesting participation phenomenon occurs.
First comes applause, then comes a torrent of question/comments. If the speaker came across as knowledgeable and their research detailed a majority of the audience participants will phrase their utterances as questions. If the speaker did not leave a lastingly positive impression, they are more likely to receive statements disguised as questions.
In some cases an audience member will speak for 3-4 minutes before yielding back to the guest presenter. Often the resulting conversation will involve deep analysis and discourse about the subtleties of the topic being discussed, sometimes resulting in shakey hands and barely controlled emotions.
At first I thought this was an example of contentiousness and disrespect. But it turns out that academicians are just as passionate and heartfelt as the people who would consider them “heady.” When someone comes in with a theory or some “findings,” the immediate reaction is to challenge, to test, to probe and see how deep, dense, and deliberate those findings and theories are.
To demonstrate their diligence as a scientist, speakers will use phrases like “tease apart,” “interrater reliability,” “in situ,” and “prompting further study.” When the way they combine and orchestrate these phrases seems reasonable and well thought out to the audience, speakers receive thoughtful suggestions for how to improve upon their research. When they do not “hold up” to scientific scrutiny, they are dismissed with kind words and the occasional “thank you.”
As I continue to meld with the community I find myself seeking out constructive criticism more than praise, for the critical eye seems to be the true social reward shared among equals. Whereas simple praise is often the reward given to peripheral participants (first year students, visitors from Kellogg or Mccormick, and second year PhD candidates whose research goals are not fully articulated).
I find this practice of reserving scientific argumentation for those who earn it to be the ultimate form of acceptance into the Learning Sciences community. But don’t just take my word for it. Berland and Reiser (2009), a graduate of the program and one of its esteemed professors (respectively) have this to say about the practice: “it is through the act of attempting to convince others—of proposing and defending claims—that ideas are questioned, challenged, and ultimately improved upon.” (p. 6).
They call this the “definition of success” and describe it as the communal goal structure of all participants in a scientific community. So for those who consider academia to be argumentative, the department of the Learning Sciences (and I would hazard to guess many other social science departments) give a pretty powerful rationale as to how argumentation is the ultimate form of respect.
Those who would call them pretentious or heady have failed to observe the passion with which they doggedly pursue each others findings and chase after grants. If you doubt their thoughtfulness, their tenacity, or their heart, just watch a PhD student in the 36th straight hour of working on their first proposal.
I have yet to be involved in a project that aims to serve the local community. But I’ve heard about several projects conducted by the members of the Learning Sciences in support of local museums, schools, students, teachers, and learners of all ages. Next quarter, I will engage in such research, supporting the Chicago-area tech-ed startup Code Academy, and I will have more to say about the practice then.
If I’m really lucky, whatever I say will be questioned, challenged, and ultimately improved upon by a group of compassionate critics and shrewd scientists whom I am starting to consider my friends.