I thought an app designed to develop programming skills in elementary aged children would not pose a challenge to someone twenty years older. Yet once I reached levels in LightBot that required you to create loops or make function calls with limited memory, I couldn’t mindlessly drag and drop instructions to have the bot behave correctly. I had to identify what movements the bot would take repeatedly or how to break the instructions into meaningful chunks. LightBot was already testing my computational thinking in several ways with these challenges.
From the very start, I had to think abstractly, which Grover and Pea (2013) identify as the “keystone” of CT, that which differentiates it from skills in other disciplines. My first problem was figuring out how to give instructions to the robot. The app confined the problem, requiring that I drag and drop predefined instructions such as movement and lighting up a square. This showed me that the designers already had to think abstractly on what tools to provide in order to solve give instructions, and I would have to think along the same lines. If I could define my own instructions, such as teleporting several blocks away or duplicating myself, this would be an application of my ability to abstract.
Abstraction allows you to deal with increasingly complex scenarios (Wing, 2011). As I progressed through the levels, my abstract thinking was challenged further since I had the basics down of working within this setting. Now the problems I had to face included: how do I provide instructions when I have little memory to do so? How can I save myself time instead of writing the same instructions over and over? How can I do this in the most efficient way possible? By using considering those problems abstractly, I was able to (with guidance) using loops and function calls, and apply those patterns to further challenges.
Problem decomposition, which Barr and Stephenson (2011) refer to as “breaking problems down into smaller parts that may be more easily solved” (p. 52), allowed me to tackle harder levels. I could take the big problem of getting all the specified squares lit up and break it down into manageable tasks, such as getting the robot to the next square to light up, getting it over obstacles, and keeping it within the square playing field. I would find myself creating a partial solution, then hitting play to see where the robot ends up, in order to test each component as I went.
Grove and Pea (2013) also identify debugging as an element of CT, which was certainly necessary as I would find my robot trying to walk off the edges of the field on more than one occasion. While each instruction would be highlighted as the robot executed it, it was not slow enough to follow in order to find the errors in logic. I ended up either modelling what was going on in my head, or rolling back to a previous state that I knew was working. This skill is certainly transferable to other fields, as I would find myself doing the same when figuring out why a circuit might not work or just getting the TV to turn on.
I think programs like LightBot provides an easy entry point for simple programming, but could be extended further. Posing complex problems that would require significantly more planning and use of algorithms, decomposition, and abstraction would certainly be possible. Other computer games such as Spacechem or the boardgame RoboRally have demonstrated the complexity that can be achieved using this format. LightBot does not have flexibility built into it that puts it at the level of LOGO or Scratch, what Grover and Pea (2013) refer to as “low floor, high ceiling” (p.40), but it is not really intended to, given its introductory nature.
Anyone could pick up LightBot or similar programs and get a taste of the thinking skills required to solve problems with the aid of computers. This app did help me understand Wing’s (2006) statement that CT is for “everyone, everywhere” (p.35).
Barr, V., & Stephenson, C. (2011). Bringing computational thinking to K-12: what is Involved and what is the role of the computer science education community?. ACM Inroads, 2(1), 48-54.
Grover, S., & Pea, R. (2013). Computational Thinking in K–12 A Review of the State of the Field. Educational Researcher, 42(1), 38-43.
Wing, J. M. (2006). Computational thinking. Communications of the ACM, 49(3), 33-35.
Wing, J. (2011). Research notebook: Computational thinking—What and why? The Link Magazine, Spring. Carnegie Mellon University, Pittsburgh. Retrieved from http://www.cs.cmu.edu/link/research-notebook-computational-thinking-what-and-why