Teaching Simplicity
reading time: CURRENTLY WIP   ·   on apr 24, 2024   ·   by Jude Bondhus   ·   Visits:

This website was made for a school paper, link to the paper is here.
It's completely different to this and talks about the issues/possible solutions for teaching math in the k-12 system.

Introduction

Before this paper starts, I want to thank all of my peers who were willing to let me "teach them programming". I learned so much from this experience and I am eternally grateful for their patience.

When the average person thinks of programming, they often get the message that only smart math people can do it and that the only people who know it are college graduates or prodigy children.

But this is false, if you can solve the problem 1 + x = 2, then you can understand the foundations of programming.

This stereotype is one of the main reasons why I wanted to teach a few of my peers how to program. I believed that I could remove the stereotype of programming in 3, 6 hour long lessons.(key word believed)

The first objection that comes to mind is that, "doesn't programming take years to learn? Isn't there a reason why colleges have programs to teach computer science?" And yes, it can take years to be good at programming fast, but if you want to start creating whatever you want, you only need a few concepts to be taught within a few hours.

Within 2 days, my peers had the confidence to "read" this code.

There was 3 main things that I wanted to do, teach them the basic concepts in programming, teach them how to google, and to get them inspired to create their own ideas(the last one failed miserably)

Day One

It took me a while to decide on what to start teaching first, programming is technically an infinitely complex field, so how do you give people the tools to begin creating something interesting while also not overwhelming them?
I was able to narrow it down to 3 main concepts.

If Statements, Functions, and Variables

Explaining what they are is out of the scope of this paper, but with these tools it is possible to create pretty much anything in programming.

The benefit to this is that it prevents cognitive overload. Cognitive overload is the natural capacity of our short term memory to learn around 4 -+ 1 things at once.(Case)

3 things to teach, sounds simple right? Well when you factor in something like syntax, the amount of things to keep stored in short term memory skyrockets.

When my peers have to focus on where to put (), ;, :, "", indentations, etc. They have no more room to focus on the 3 main concepts I sought out to teach. (NOTE FOR LATER HOW DO I MAKE THAT LIST MORE CONSISE I FORGOT)

This is the same as teaching grammar in English. No one wants to learn it, so how do you sneak it in?

Well it turns out there is not many options around it, humans tend to learn brand new concepts through passive dry learning, aka word for word memorization(Case).

This counteracts the popular belief that new students can learn how to code faster by exploring code through experience such as trial and error.

In fact, according to a study done by :Felienne Hermans, students performed and learned much better when taught syntax by reading step by step vs exploring code on their own.

Ex.
for i in range(4):

for i in range, round open bracket, four, round closing bracket, colon.

This relates back to the idea of cognitive load, a student can't start writing a novel without learning how to structure a word and sentence first.(Sian)

Here is the predicament though, according to the young modulus graph, students learn best when stress levels are kept at a sweet spot.
Arousal can also mean stress level*

I wanted to teach my peers the logic of programming. But since traditional programming requires learning syntax, teaching both subjects at once would've overwhelmed them, creating high stress.

The solution?

While multimodals aren't the greatest at Teaching dry skills like syntax, they can certainly help ease students into a topic as they tend to help gain a broad understanding of a topic(Amanda 13).

To prove this point, I've created a short interactive that shows a math problem in a new light.

This is where multimodals truly shine, sure the final proof wasn't as rigourous as a step by step proof. But it explains a pattern in a quick and intuitive way.

Now wasn't the claim "boring dry topics can only be taught through passive learning?".

And yes that's true, passive learning still has it's place. But by using multimodality, you can slowly ease students into a subject in a more engaging way.

Okay, now to reveal what I used as a multimodal.(PLACEHOLDER) blockcoding

There was one big flaw with this method though, often, it would distract from the content that was meant to be taught. My peers would get stuck focusing on how to use the software itself before they could actually focus on the core concepts being taught.

Going back to the Yerkes-Dodson graph, this is my guess for where they were.

(Sounds kind of like the original problem right?)But it could've been worse, if my peers started out typing programs, they would've been even farther to the right on the graph.

Although given the time constraint, I tried my best to reduce this by creating preset files to work off of.

If there was a perfect solution, it would be to create a multimodal interactive tailored for your topic thats charming, simple and fun.

It does takes time and skill to create. So the 2nd best option is to use pre-made tools that relate to the main topic.

All in all, day one got the main message across, and surprisingly my peers even remembered some of the details.

On top of this, their stress(struggle) level almost perfectly hit the sweet spot. The goal was to not have them always know what to do, nor should they have been completely clueless. So staying in the orange zone here fits Yerkes-Dodson's graph quite well.

:Side note

This is a personal note, but I would knock each rating on the fun scale down by 3. It's most likely only rated so high because they would've felt bad.

definitely screw that person who voted 7, he prob cant make decisions lmao.

Day 2

Like mentioned earlier, the goal was to get my peers to understand how to read written code in 2 days. I didn't necessarily think I could get them to be good at programming, but I needed them to know how to teach themselves.

Day 2 consisted of teaching the same exact thing as last time but in a new perspective, rather than writing in block code they would move into actual written code. This was once again intimidating as they had to learn a completely new software again while learning how to write code at the same time.

This time around it was about the same thing, lots of pre made projects and puzzles made for my peers to go through. each one focused on a specific concept in programming so they can experience a usefulness to programming.

There was one major difference between this course and the last one though. Near the encoding we did something different and unplanned. We decided to go back to the original chunk of code that seemed to be impossibly complex.

Rather than just spitting out what this code did, with a definite answer in mind I simply asked my peers to infer about what this is. Even though they never learned what the code did specifically, they understood that all they need to know was variables, functions and if statements.

The magic in this is that it gave them confidence to actually start having a discussion.

Sure by the end of the discussion they didn't fully understand what the code was, and to be honest even I didn't full understand what I wrote in that code. But the point is, they started to use critical thinking to think of their own interpretations. Which in the end, logical thinking is what programming is all about.
Ps. :here is an example of one of my peers going through the mental process of figuring out what this code is

This is honestly something that I wish would've happened more, but this'll be talked about more in day 3.

Day 3

Day 3 was a catastrophe, but because it was so horrible I learned a lot.

I had a lot of ambitions for the final day, and a lot of experimental ideas that I thought would work but failed miserably. My ideas for the course were so experimental to the point where it's hard to put into words in this paper.
Here is a summary of the ambitions for the final day

  1. Cover how hard or easy it can be to create games
  2. Explain how easy it is to create games with the help of software
  3. How to create unique and engaging ideas for games
  4. Inspire my peers to learn and create games on their own

At this point, I felt like I taught the most important things about programming. If I were to teach anything more it would've been specific tools and techniques that my peers would be better off learning through experimentation and googling.

As it was mentioned before, complete beginners learn best through passive learning, but since my peers had basic knowledge the first assumption was that they could start coding using active learning. After all, active learning is more fun right?

Well it turns out they were not ready to start creating code on their own. Which should've been obvious but a theory that I wanted to test was if someone was there to guide them through the process to give them the tools that they need maybe it could've been possible?

And to be honest, I still think that this method of teaching could've been great, to help them create what they are inspired to do. There was just one big thing that they lacked, which was a reason.

Because if my peers didn't have a reason to create programs, they might end up asking the terrifying question "when will I use this".

My answer to this question would most likely be, to help them to dip their toes into a new field that could help them create "things". Which was partly the reason for why I started to learn programming. But I never actually got interested in programming until I learn how to make cool things like video games.

So here was my solution, teach them how to create a cool idea!

This was an egotistical idea, but maybe if I didn't think about that aspect it could've worked.

here's how it went.

They are a multitude of reasons for why I almost blacked out; barely any sleep, food and no water. But the main reason for this happening was a realization that this wasn't gonna work.

I realized that I wasn't actually teaching them anything. At the point where I was, I was trying to explain how to create ideas, it felt disjointed and unrelated.

Embarrassingly enough, it was an egotistical mindset to think that I could create a reason for them to create games, let alone programming.

I thought, if I could help them create an idea, then they would be inspired to create on their own and that I could let them go from there. This was clearly not the case.

This mindset is as useless as telling someone to "follow their passions".

Sure, reasons and inspiration can help. But there is a more universal solution to helping them be inspired.

The programming itself.

Remember at day 2 when my peers were figuring out this?

I've pondered this for a while, it doesn't make sense. Why would my peers be engaged in discussion about something seeming less and random?

The theory that applies here is once again, the Yerkes-Dodson theory. Being able to write in syntax is overwhelming and hard, often taking some people weeks or months to master.

Since there was no goal of memorizing and writing syntax. My peers were able to focus on something that wasn't too hard or easy.

My peers were allowed to compare and contrast ideas on an equal level of skill, no one really could've gotten it right but since they had the confidence to solve the problem they got curious, and actually put thought into understanding the problem.

It might not have been as riveting as binge watching a tv show, but in the words of one of my peers

"We were actually able to apply what we learned, we recognized big functions and realized that we could become programmers too"

What I did by trying to distract with creating ideas was covering the broccoli in chocolate. There was raw interest that my peers got out of learning to program.

"I need to season & roast those veggies, to bring out the natural tastiness that's already in the broccoli."(Case).

Inspiration is earned when people find out they learned something and can apply it to something else.

This inspiration leads to motivation to learn, and learning leads to inspiration.

Summary

Going forward, this seems to be the best strategy.

  1. Take 4+-1 related topics to teach at once.
  2. Start by explaining the broad idea of the topic(preferably multimodal)
  3. Use passive learning and direct hand holding to teach the topic.
  4. move into puzzles to give experience.(For the love of God not homework packet assignments)
  5. With the newfound confidence in learned topics, start discussion.

is loading comments...

: Works Cited

Beilock, Sian L., and Daniel T. Willingham. “Ask the Cognitive Scientist.” Math Anxiety: Can Teachers Help Students Reduce It?, vol. 38, no. American Educator, 2014, pp. 28-32. Math Anxiety: Can Teachers Help Students Reduce It? Ask the Cognitive Scientist, https://files.eric.ed.gov/fulltext/EJ1043398.pdf. Accessed 16 3 2024.

Boaler, Jo. “Fluency Without Fear.” YouCubed, 28 01 2015, https://www.youcubed.org/evidence/fluency-without-fear/. Accessed 16 March 2024.

Case, Nicky. “Curse of the Chocolate-Covered Broccoli (or: Emotion in Learning).” Nicky's Blog, 5 December 2019, https://blog.ncase.me/curse-of-the-chocolate-covered-broccoli-or-emotion-in-learning/. Accessed 16 March 2024.

Finkel, Dan (2017, Feb) Five Principles of Extraordinary Math Teaching [Video] TED. https://www.youtube.com/watch?v=ytVneQUA5-c&pp=ygUNdGVhY2hpbmcgbWF0aA%3D%3D

Gonzalez, Jennifer. “Frickin' Packets.” Cult of Pedagogy, 26 March 2018, https://www.cultofpedagogy.com/busysheets/. Accessed 8 April 2024.

Hermans, Felienne "How to teach programming (and other things)?", “Strange Loop Conference”, 14 September 2019, youtube, https://www.youtube.com/watch?v=g1ib43q3uXQ Accessed 2 April, 24

Muller, Derek A. Khan Academy and the Effectiveness of Science Videos. 2011. youtube, https://www.youtube.com/watch?v=eVtCO84MDj8&t=258s. "I need a counterclaim from a hostile audience for the following claim: (claim) Students should be able to use AI software because they will need to use it in their future careers." prompt. ChatGPT, ChatGPT 3.5, OpenAI, 6 Feb. 2024, chat.openai.com/chat.

"I need a counterclaim from a hostile audience for the following claim: (claim) Students should be able to use AI software because they will need to use it in their future careers." prompt. ChatGPT, ChatGPT 3.5, OpenAI, 6 Feb. 2024, chat.openai.com/chat.

"I need a counterclaim from a hostile audience for the following claim: (claim) Students should be able to use AI software because they will need to use it in their future careers." prompt. ChatGPT, ChatGPT 3.5, OpenAI, 6 Feb. 2024, chat.openai.com/chat.

"I need a counterclaim from a hostile audience for the following claim: (claim) Students should be able to use AI software because they will need to use it in their future careers." prompt. ChatGPT, ChatGPT 3.5, OpenAI, 6 Feb. 2024, chat.openai.com/chat.

"I need a counterclaim from a neutral audience for the following claim: (claim) Students should be able to use AI software because they will need to use it in their future careers." prompt. ChatGPT, ChatGPT 3.5, OpenAI, 6 Feb. 2024, chat.openai.com/chat.

"I need a counterclaim from a neutral audience for the following claim: (claim) Students should be able to use AI software because they will need to use it in their future careers." prompt. ChatGPT, ChatGPT 3.5, OpenAI, 6 Feb. 2024, chat.openai.com/chat.

"I need a counterclaim from a neutral audience for the following claim: (claim) Students should be able to use AI software because they will need to use it in their future careers." prompt. ChatGPT, ChatGPT 3.5, OpenAI, 6 Feb. 2024, chat.openai.com/chat.

"I need a counterclaim from a neutral audience for the following claim: (claim) Students should be able to use AI software because they will need to use it in their future careers." prompt. ChatGPT, ChatGPT 3.5, OpenAI, 6 Feb. 2024, chat.openai.com/chat.

Meyer, Dan. “If Math Is The Aspirin, Then How Do You Create The Headache?” dy/dan, 17 June 2015, https://blog.mrmeyer.com/2015/if-math-is-the-aspirin-then-how-do-you-create-the-headache/. Accessed 16 March 2024.

Kartak, Amanda. Real World Reboot: Multimodality. 2022. Saint Mary's University of Minnesota, Masters of Education in Teaching and Learning.

Lockhart, Paul. A Mathematician's Lament. Illustrated edition ed., Bellevue Literary Press, 2009.

Sanderson, Grant. When do programmatic visuals help in understanding math? 14 Oct 2021. youtube, https://www.youtube.com/watch?v=gvck7ssg9dE.

Shoenfeld, Alan H. “When Good Teaching Leads to Bad Results: The Disasters of "Well Taught" Mathematics Courses.” Educational Psychologist, vol. 23, no. 2, 1988, p. 22. researchgate, https://www.researchgate.net/profile/Alan-Schoenfeld-2/publication/239027194_When_Good_Teaching_Leads_to_Bad_Results_The_Disasters_of_%27Well-Taught%27_Mathematics_Courses/links/02e7e528dae5f8984d000000/When-Good-Teaching-Leads-to-Bad-Results-The-Disasters. multimodal image from wikipedia