By: At Digital Adventures, Scratch is one of the many hardware and software platforms we leverage to teach kids how to build with technology. Yet, when some students come in they already have preconceived notions about the utility of this powerful language. They either say, I’ve already done Scratch or can we do a more challenging language?
As an education technology platform, our goal is to make sure we’re using the most useful platforms to accomplish a positive outcome for our students. When it comes to teaching programming, Scratch is one of the best. So, why do so many students have an issue with this programming language?
Poor Introductory Experience
Oftentimes, when you dig into a student’s resistance to Scratch, one will discover that their first couple of experiences weren’t that great. Either because the instructor wasn’t super knowledgeable or the project they were building wasn’t that great.
Some students have said that they just learned how to move Scratchy the Cat around the screen with basic commands or when they wanted to do more, their instructor was unable to progress beyond the basics.
As a result, they thought that Scratch wasn’t powerful enough to do anything beyond just basic character movement or simple animations.
Whenever we hear this, we are pretty disappointed. While it’s great that someone stretched themselves to introduce a new language to a student; if the introduction wasn’t great, it creates a big barrier for future growth as students will do anything to avoid a similar experience.
To counterbalance this, we usually take students through a project that has many different parts that work together to show off the full potential of this simple yet powerful language.
Limited Opportunity to Develop Skills
On the other hand, there are experiences where the instructor has developed knowledge on a core set of projects at such a high level that they tightly control the project building. Students are naturally curious about everything. In fact, if you’ve ever been around students for any period of time, they love to ask questions.
And, while they are generally happy to build a project that works; they are much more excited when they can take something that has been built and make it their own either through customization or personalization.
Many times instructors who are simply teaching pre-built projects get uncomfortable with letting students get too far outside of the boundaries of the original project because they aren’t sure what might happen or if they will be able to get students unstuck if things go sideways.
However, that is an antiquated model of the role of the teacher as single source of knowledge. Instead, an evolved thinking that we would suggest is to consider that both teacher and student can learn from each other. And, given the many forks that projects can go in, it is nearly impossible for an instructor to know exactly how to implement each and every student’s idea.
But, there is a generalizable framework for how one might remake a project and by going through that process with students, everyone’s knowledge base will grow.
Misconceptions with text-based languages
Let’s face it, most projects are built using text-based languages. Whether it’s Ruby on Rails or Javascript, students have the expectation that they will eventually transition from a visual based language to one that is text-based.
However, it is important for educators to reframe this journey so that students understand the need to develop mastery over time without unnecessary distractions.
Text-based languages have their own syntax and structure in addition to a fundamental understanding of logic.
For example, if every student in their 1st math class told their teacher they wanted to only solve problems using calculus, a good teacher would push back and refocus their energy on learning their numbers and then their basic mathematical operations (addition, subtraction, multiplication and division). Only after these basics were mastered would an instructor even consider providing a high level overview of calculus as a motivation to keep developing their foundational skills.
Or, if a student came into their first language arts class and said they only wanted to write novels, a good teacher would push back and have their eager student focus on learning the alphabet and then move on to words, sentences and grammar.
In a similar way with programming, students must be given an opportunity to learn the logic behind computer programming before they can successfully progress to text-based languages. With a solid understanding of logic that is easier to understand with a programming language like Scratch, students are better prepared to take that knowledge and build useful projects independently.
On the other hand, a rapid introduction to a text-based language may gain them an understanding of the language from a syntax & structural standpoint. However, they may not fully appreciate that certain languages are better for specific applications.
Conclusion
The team at MIT invented an amazing programming language with Scratch. However, because of it’s accessibility, students aren’t always given the best introductory and developmental experiences with this language.
As a result, there can be significant resistance to additional instruction with this language. However, when one is just getting started, it’s best to focus on skill development in the area that most people find difficult. For programming, this is often the logic and algorithm design not the syntax and language structure of a specific language.
If the goal is to learn the logic of programming, Scratch is an excellent choice. Let’s hope that it sheds its undeserved bad rap among students.