As noted previously, I had to learn the hard way about how to really focus in a good writing assignment. This is the finished product, the earlier draft of which is here: Romancing the Code: The Literacy Narrative I Wanted to Write.

This is the final version of a literacy narrative, originally written for UMass Lowell (online) College Writing I, Sec. 031, Professor Richard Keating, October 15, 2018. (Note to plagiarists: This has been submitted to the TurnItIn database, <sarcasm>so, by all means, copy away</sarcasm>.)

Douglas Wilcox
Richard Keating
UML College Writing I, Sec. 031
October 15, 2018

Romancing the Code

Phase 1: Literacy Narrative

In one of several clichés employed by twentieth century science fiction, computers are autonomous problem-solvers. They are almost never seen to be programmed by humans. The idea of a computer as a tool is refocused into its metanarrative, where the computer is an autonomous yet servile agent of its human master. A query is made, and the computer—via punched paper, data cards, audible output, or screen display—provides the answer to an enormously complex problem. Although I use computers to solve a vast number of practical problems in everyday life, programming itself, begun when I was in elementary school, provides the ultimate problem-solving experience.

The same year Star Wars was released, I met my first real computer: a Digital Equipment Corporation (DEC) PDP-8, at my town’s high school. Each terminal connected to this computer was a repurposed teletype machine. There was no screen display, only a nearly-endlessly spooling roll of paper. Each keystroke from the operator or each character output from the PDP was accompanied by a wonderfully complex sound of motors and servos moving the print element and its carriage across the platen, and hammering the right letter onto the paper (262LongRunner).

I was in love.

Through another school program, I got to play on a PDP-40, a massive device that would have made the PDP-8 weep with inferiority, had it been sentient. There I discovered the text adventure “Dungeon” (nee Zork) (Anderson, Kidder).

Creating my own text adventure game became my obsession. I had grand visions. I spent hours creating maps, and working to figure out subroutines that would be able to interpret user input, track inventory, handle world descriptions and actions, and even inject some humor while tracking hunger and thirst—“You would kill for a baloney-and-cheese sandwich.” There was no way for me to do a program this large on the DEC, but the Apple IIs that the junior high had would be perfect. They even had floppy drives, so I could store this creation on my own 5¼” diskette.

Not owning my own computer, I had to work offline—truly offline. I worked in notebooks, keeping the program flow in my head, and writing the code in longhand for later entry and debugging. I had the inspiration and functional model from other, better-written software, and a clear idea of what I wanted to do. I just had to figure out how.

A text adventure needs to provide a description of each location or room, and anything that might be portable in that room. The program needs to track the player’s location, and allow the player to move through the game world. My solution for handling this was effective, but contraindicated by speed and memory limitations at the time. The key was arrays—the computer equivalent of a numbered stack of index cards. I used an array of alphanumeric variables as a container, storing the description for each of the game’s locations by element number in the array. So, if the player moved to “location 104,” the description could be displayed by returning the description in “card” 104. That system was great for things which stayed in place, but what about portable items? For that I had to push further, but was still able to use an array structure. I invented a design where each portable item would be assigned to an item number in an array, and the data for that item would be stored in a predetermined portion of a text variable that contained, among other things, the item’s description. In the metaphor of the index cards, we might imagine that specific lines on each card record a specific kind of data, such as consistently having a title on the first line of every card.

Player movement could be controlled by setting the player’s location to a particular number corresponding to the description array and item locations. Switching the location was just a matter of coding which direction’s movement would take one to which location number and using that number to access the description and item arrays.

When I finally got enough of the modules coded and debugged, I ran it. It worked! It was slow—but it worked.

Now I work full time as a programmer, as I have for more than 15 years, and every part of my workday involves applying digital literacy directly to solving programming problems. I use my store of those skills and a variety software tools to accomplish this. The problems I solve are far more complicated—although they often still involve arrays—but they apply all the digital skills and literacy that began when I was smitten by the PDP-8, in all its teletype-driven glory.

Phase 2: Analysis

The rapid development of digital technologies in the digital era presents individuals in the emerging information society with situations that require them to employ a growing assortment of cognitive skills in order to perform and solve problems in digital environments. These skills are often referred to as “digital literacy” (Gilster, 1997; Inoue et al., 1997; Lanham, 1995; Pool, 1997), which is presented as a special kind of mindset that enables users to perform intuitively in digital environments, and to easily and effectively access the wide range of knowledge embedded in these environments (Gilster, 1997; Tapscott, 1998; EshetAlkalai, 2004; 2005) (Aviram and EshetAlkalai 1, emphasis mine).

The experience described in this narrative pertains to the phrase: “to perform and solve problems.” Problem-solving is the aspect of digital literacy that is most important in my life and career.

My first digital literacy skills were not very impressive, and many are now accessible by toddlers in today’s world of icons and GUIs: reading a directory, loading a program, running that program, and interacting with its prompts and output. Looking back over my computer literacy from childhood through the early days of my computer career, it is clear that my very meanest skills were a foundation of understanding that lasted for decades.

I worked in notebooks, keeping the program flow in my head, and writing the code in longhand for later entry and debugging.

Although the problems I solve are now more complex, the instant availability of explanations, sample code, and often complete example projects available online can make the level of problem solving significantly different. Given my skill level at the time, my limited access to computers, the nonexistence of the Internet, and a lack of established patterns, there was more room for innovation at a basic level. Innovation is still significant, but it tends to occur 

I spent hours creating maps, and working to figure out subroutines that would be able to interpret user input, track inventory, handle world descriptions and actions, and even inject some humor while tracking hunger and thirst….

It was somewhat surprising to explore this time period, and to renew my awareness of just how exhilarating computer tasks were. I was able to continually improve programming concepts and problem-solving by my sometimes weak attempts to replicate things I had seen. Writing my own text adventure was a wonderfully motivating force for improving my programming and the problem-solving that went along with it. I still advise those who want to learn a new platform on language to think of something that they really want to build as a first project.

That system was great for things which stayed in place, but what about portable items? For that I had to push further.

Although it is true that I knew far less, I was also working with a programming language that was more limited in its abilities, and accomplishing what I wanted often required a finer-grained ingenuity.  

The “growing assortment of cognitive skills” (Aviram and EshetAlkalai) is particularly evident in the development of problem-solving. Like any cognitive skill practice, problem-solving begets even more refined problem-solving, leading to gains in the complexity of problems that can be solved, and the ease with which they can be solved.

Works Cited

262LongRunner. “Teletype Model 33 ASR.wmv.” YouTube, YouTube, 16 Apr. 2012, www.youtube.com/watch?v=ObgXrIYKQjc. Online video.

Aharon Aviram and Yoram EshetAlkalai, “Towards a Theory of Digital Literacy: Three Scenarios for the Next Steps.” European Journal of Open, Distance and E-Learning. 2006. Retrieved from https://pdfs.semanticscholar.org/c680/679dc70baf4727cfd5f97b8535d62137914e.pdf?_ga=2.58484906.1842711008.1538448028-1659923920.1538448028. Document download.

Anderson, Tim. “The History of Zork.” The Wayback Machine, 1985, web.archive.org/web/20060427000213/http://www.csd.uwo.ca/Infocom/Articles/NZT/zorkhist.html. Web page.

Kidder, Tracy. The Soul of a New Machine. Little, Brown and Company, 2000. Print.

Feedback

Professor Keating’s Final Response:

Hi Doug,

As I read the final version of this exceptionally well revised essay, I reflect on how the vast majority of my students see digital literacy in terms of language, or a lexicon of terms common to a discipline. You see it in terms of a numerical logic, a binary code of understanding. That’s just as applicable, different cognition, same result!

Fine start to the semester, RSK