Playing is finding joy in open-ended exploration, without being concerned with a specific outcome. Play allows ideas to be reimagined through new representations, avoids following conventional ways of thought, and uses rules and limitations as means to creativity. Used in conjunction with other imaginative skills, it leads to the transformation of ideas, by altering modes of representation or finding connections across (and above) disciplines (Root-Bernstein & Root-Bernstein, 1999).
While I initially considered play as an underutilized skill in creating algorithms, I found that it can be one of the most useful ways to be creative in problem solving, such as with my proposed activity that uses playing with a simple programming tool to introduce algorithms to elementary and middle school students. While it uses open inquiry to allow the students to freely explore how instructions are constructed, I kept some constraints and broad goals in place to promote deep or hard play. The only way to construct the algorithm was through the blocks available in Scratch, and with each of the challenges, students were given the freedom to explore but needed to apply what they learned towards increasingly complex goals.
Scratch provides an easy to use entry point for young students to create programs using natural language and drag-and-drop blocks of code. The interface uses natural language instructions that allows projects to straddle the line between algorithm and program: once the blocks have been snapped together, they describe a method to solve a problem, but Scratch encourages students to play with the algorithm through easily modification, and the results are instantaneous – the blocks can even be changed while the program is running. In my experience with Scratch, allowing young students to start with a drawing algorithm provides an introduction to the value of play when coding.
The idea of drawing through algorithms is at least half a century old. In Mindstorms: Children, computers, and powerful ideas, Seymour Papert (1980) promoted using the LOGO language to create patterns with students of all ages, and Scratch is the spiritual successor to LOGO. Papert also adapted constructivism, the idea that learners construct knowledge through experiences, into his own theory of constructionism, where learners create a meaningful product to develop new knowledge. Scratch is a great tool for use in constructionism, which is innately linked to the idea of hard play.
Hackerspaces, such as i3Detroit, are community-driven places that not only foster creativity, but also the related ability to innovate. In a previous class, I explored the relationship between creativity and innovation as seen in the graphic below. Two needed ingredients for innovation stood out to me when considering this space: resources and culture.
The initial appeal of these spaces is simply the space and tools available, both valuable resources. I joined while still living in an apartment, so some projects were simply not possible without a larger area to work within. i3Detroit is housed in a converted warehouse, with different zones such as the woodshop, electronics, welding, crafts, 3D printing and computing workplaces. Each zone is set up so that there is space for several people can collaborate and keep project materials within the area until the project is complete. For creativity to flow, barriers need to be removed, just educators try to do for their students. Tools such as laser cutter and 3D printers opened up new methods to complete projects and required developing new skills, such as becoming familiar with CAD software. The wealth of experiences that can be gained allows for new connections to be made.
To model is to gain a deep understanding of an object, a process, or idea by representing essential information by physical or virtual means. This can be done as a preliminary sketch in the act of creation, but it can also be used to represent knowledge that would otherwise be difficult to experience first-hand. Often modelling makes use of dimensional thinking, which is the translating or conceptualizing across dimensions of space, time, or any other range of related values (Root-Bernstein & Root-Bernstein, 1999).
Models of instructing computing machines to aid in problem solving have existed for over 150 years. When modelling a computer algorithm, I chose to explore its place across multiple sets of dimensions. The most obvious would be of scale and thus visibility,starting with that which can be viewed easily, such as the general solution to a problem and its implementation, then proceeded into that which is usually hidden , such as low level instructions, or microscopic in the case of transistors. This model also explores proceeding from the general to the specific, as implementing an algorithm is to use your own creativity in how to best do that, as my recipe analogy suggests. Parallel to this progression is starting with the virtual, such as an idea of how to accomplish a task, to the physical, with the actual tools being used to help complete that task.
If an algorithm is itself a model for understanding how to accomplish a task, the difficulty lies in creating a model to represent what is a model already, just as I found when trying to abstract an abstraction. Not surprisingly, the two skills of modelling and abstraction rely on each other, as a model is a useful abstraction. To accomplish this goal, I’ve decided to focus on the transition from algorithm to implementation, or in computing, creating a program based on an algorithm. Part of this process is accomplished by a person, the rest by a computer, so this lends itself well to computational thinking.
To gain a better understanding of how an algorithm is transformed into a program, I created a model that views this across physical scale, from the large to the very small; transitions from digital to physical; and demonstrates changes in logic, from the abstract to the specific. It elucidates what occurs behind the scenes when a program is executed, and shows how layers of abstraction in a computer provides human with the ability to intuitively instruct them.
As I found with many of the thinking skills for creativity presented in Sparks of Genius, algorithms and modelling are closely related. Composer Igor Stravinsky’s advice to an author encountering issues during the act of creation was to find a model, or “a predecessor what had already solved his type of narrative problem, then modify the solution to his own ends” (Root-Bernstein & Root-Bernstein, 1999, p. 230). This describes the role of an algorithm in general problem solving: an established solution to be used as reference for solving particular problems. Think of a recipe as an established way to create a dish; cooks may use it as a starting point and modify it provide their own personal interpretation. This reflects the idea idea that creativity is finding a “variation on a theme” (Henriksen, Mishra, & Deep-Play research group, 2014).
Algorithms lie on one end of the spectrum of problem solving techniques, where following step-by-step instructions can accomplish well-defined tasks, but most learning is much messier. We therefore often look for other, less rigid techniques while still keeping algorithms on hand as models of prior solutions. Moving along the spectrum into ill-defined tasks, heuristic approaches can lead to “good enough” solutions. This includes using “rules of thumb”, trial and error, and making educated guesses (Simon & Newell, 1958). On the opposite end of the spectrum lie solutions arrived at by chance. While these are by their nature unpredictable, they can be prepared for through diverse experiences and have led to discoveries ranging from penicillin to silly putty.
Embodied thinking rejects the notion that the mind exists separately from the body, but instead recognizes that an awareness of all aspects of the human body, the exertion used in movement, emotional responses, tactile understanding, and gut instinct all play important roles in the act of creation. The related skill of empathy allows one to take the place of another, attempting to feel what they feel, even for an inanimate object, to gain insight into their state of being.
I chose to integrate embodied thinking as it relates to my topic of algorithms in a way that would best serve my end goal of creating an experience that would allow museum visitors understand programming in a relatable way. For that reason, I decided not to follow the well established path of creating a kinesthetic activity that allows learners to act out how data is manipulated in an algorithm, which was my first thought and I think of limited use. Instead, I created a stage show that uses multiple levels of embodied thinking.
Programming can be intimidating, but by allowing students and museum visitors to take on roles of characters engaged in computational thinking, they can gain an understanding of how an algorithm works in a visceral way. Visitors can not only view but also participate in a stage show where they can work alongside museum staff to act out a basic understanding of computer programs. During the play, characters will use motions to reinforce what each part of the algorithm does, further embodying the concept being learned.
Programmers solve problems. They accomplish this by working with or taking inspiration from computers to find solutions to problems, but they don’t do it alone. They have a set of thinking tools that will allow them to accomplish their tasks more easily called computational thinking. The play will explore different computational thinking skills as well as basic tools available to programmers. Even the play itself is an example of computational thinking, as actors are using a simulation to gain a better understanding of algorithms, just as a computer may be used to run a simulation to better understand a problem.
Do experienced programmers achieve the ability to code instinctively or achieve a visceral understanding of a path to follow when deciding how to solve a problem? Certainly the ability to program does not rely on muscle memory other than typing or clicking a mouse, but I believe there are reflexes that are developed over time that aid with the ability to create an algorithm.
Learning to program is similar in some ways to learning a new language. There is the need to adhere to a certain syntax that can vary from language to language. Languages also have different built in structures and functions can change how the language is used. Even if you are experienced in one language, gaining a familiarity with the strengths and idiosyncrasies of a new language takes some time. Building that comfort level is in a way developing a mental muscle memory that allows the programmer to focus on higher level problem solving. Beyond programming syntax, there’s the need for software architects that can determine the shape of the the entire project or platform, and an even more intuitive sense is needed.
Abstraction is representing an understanding such that the “essence” of an idea is reached. It allows us to recognize similarities between ideas or objects that would otherwise be obscured by irrelevant details. Using multiple senses and patterning can be helpful in perceiving the topic in a focused way (Henriksen, Fahnoe, Mishra, & the Deep-Play Research Group, 2014).
When first tackling the abstraction of an algorithm, I struggled with the idea since algorithms are themselves abstractions, a way of working with generalized, reusable instructions that can be applied to many specific situations. I was encouraged to know that “abstracting is difficult for people in every discipline” (Root-Bernstein & Root-Bernstein, 1999, p.77). After many false starts and rethinking of my topic, I was able to understand that there are many ways to abstract an object or idea, and the purpose of abstracting determines what details are unnecessary to be stripped away and what lies at the heart of the matter. I tried to think how I would explain the shape or flow of a program to students or to visitors of the museum with no experiences with programming to give it that necessary context. The best abstraction could be easily understood by many people in that context and not require specific domain knowledge.