SLA Insights Part 2: Input, Interaction & Output

In part one of this series, we introduced the academic discipline of Second Language Acquisition (SLA) and began looking at how engineers can apply insights from SLA research to learning programming languages. We began exploring and applying these insights through a focus on the sub-domain of language learner beliefs, with special emphasis on the ways those beliefs can help or hinder the language acquisition process.

In this second part of the series, we’ll examine another SLA sub-domain: the linguistic environment.

--Lourdes Ortega, Understanding Second Language Acquisition

Those who have studied a foreign or second language know that much of the time, we learn language with others. Teachers, classmates, tutors and native speakers all contribute to our ability to acquire a language that’s not native to us by providing additional resources to practice with and answering our questions along the way.

And just as the language-learning process isn’t a solo journey, neither is our reason for starting it in the first place. Often, we learn languages at least in part for others—perhaps to satisfy a teacher’s learning objectives, a job requirement, a relationship or to participate in a culture that interests us.

From the people involved in our linguistic pursuits to the physical spaces we study in, our unique environments can both help and hurt our ability to achieve and retain mastery of a language. 

Like many people, I was in middle school when I had my first opportunity to formally study a foreign language. In order to satisfy a school requirement, I studied French for a single school year, sitting in class for one hour daily. I had no sincere interest in learning French at that time; I had only enrolled in order to get the credit I needed to move to the next grade. 

I took this class with my closest friends, and I remember that we all approached learning the language nonchalantly. The stakes weren’t high; we goofed off during class time and teased our instructor incessantly. It was not, to say the least, an environment conducive to mastering the French language. I wasn’t studying French with or for others. I wasn’t even studying French for myself.

Later in my life, after spending a year teaching English in South Korea, I moved to Ecuador. I had the intention of staying in South America awhile, teaching English here and there, and gaining fluency in Spanish. I was enthusiastic about the language and eager to assimilate myself into Latin American culture. 

In Ecuador, I was surrounded by native Spanish speakers, and many of them were willing to chat with me. Their feedback (in Spanish, of course) allowed me to bolster my listening skills and gauge how well I was achieving my communication goals. It was an environment rich with examples and ripe for language acquisition.

Because learning to code entails learning programming languages, I believe we can make the same claim about the importance of the coding environment as we have about the importance of the linguistic environment.

For example, many of us learn computer languages for others in the sense that we are typically learning them to work with a team, product, industry, or business. And we most certainly learn those languages with others, despite the lingering myth that software engineers work alone in dank basements, noshing on Cheetos and guzzling cans of Red Bull.

The reality is that writing code is a communal effort, one that includes collaboration and knowledge-sharing and pair programming and code reviews. The communities in which we write code create the environments that either help or hinder our continued acquisition of programming languages and technologies.

Environmental influences on language learning have long been observed and documented. In the late 1980s, SLA researchers in the cognitive-interactionist domain proposed that five elements that must be present in a learner’s environment for successful language acquisition:

• Exposure to authentic, meaningful language input

• Ample opportunities for interaction with native speakers

• Frequent opportunities to produce authentic, meaningful language output

• The learner’s attention to and noticing of relevant components of the linguistic input and output

• The learner’s positive attitudes toward the target language culture

This article will examine the first three elements: input, interaction and output. We will first  focus on describing how they impact human language learning, then explore how they might impact learning programming languages.

Language input is necessary for acquiring a second language. Ortega defines input as “linguistic data produced by other competent users of the L2.” This input may take the form of spoken or written text that requires developing listening and reading skills to fully understand.

For input to help acquisition, its content and complexity must be tailored to the learner’s current state of fluency. In fact, SLA researchers have argued that comprehensible input (linguistic data slightly above the learner’s current level of understanding) is the single most important element for language learning. 

If we don’t understand most of the input, we can become overwhelmed by the sheer volume of new linguistic data to process. Unsurprisingly, feeling overwhelmed can get in the way of our language learning and acquisition.

I became hyper aware of this when I taught composition courses to non-native English speakers at Colorado State University. For many reasons, students are sometimes moved through the university system before they are linguistically ready to thrive in an academic environment. As a result, course readings, lectures and classroom discussions can become extreme sources of anxiety for ESL students, as they are unable to comprehend the linguistic input critical to their success. In fact, academic language is different enough from non-academic language that even native speakers can struggle when entering an academic environment.

I believe there are parallels in the programming world. I experience comprehensible input when I’m asked to work in an established code repository for the first time. There is a period when all parts of the project—the coding style, the organization, the purpose and the functionality—are completely new to me.

Sometimes, even the programming language itself is relatively new. When I’m first engaging with the codebase, there’s a lack of comprehensible input in the project; too many elements are new, which impedes my understanding of the project as a whole. 

Luckily, this can be amended by spending a day examining and interacting with the code. Reading the documentation, playing with the API, running the tests, looking for stylistic idiosyncrasies in the code, striving to understand how the project interacts with the larger system and chatting with the code’s primary authors can help my gradual understanding. As I move through this process, more and more of the input I consume from the repository becomes comprehensible.

Comprehensible input alone is not the only thing needed for language acquisition. Another necessary element is interaction and the negotiation for meaning that occurs as part of it. Ortega writes:

“The best kind of comprehensible input learners can hope to obtain is input that has been interactionally modified; in other words, adjusted after receiving some signal that the interlocutor needs some help in order to fully understand the message.”

According to the Interaction Hypothesis, language speakers typically strive to make meaning more clear for each other. This is referred to in SLA as negotiating for meaning. These instances typically include clarification requests and comprehension checks if one speaker thinks that the other has misunderstood their intention.

Consider the following exchange between a native (NS) and non-native (NNS) speaker of English, and observe how both speakers work together to achieve mutual comprehension:

NNS: What do the weekend?

NS: Excuse me?

NNS: What...what did...uh, do the weekend?

NS: What did I do this weekend?

NNS: Yes! Uh, what did you do...uh, the weekend?

NS: I went on a hike with my family. How about you?

In situations of interaction and negotiation for meaning with another person or group of people, native speakers can adapt to the language learner’s current ability to understand and transform their message into comprehensible input for the learner.

I remember many exchanges like this during my time in Ecuador, particularly in a coffee shop I frequented. The woman who owned the shop was extremely affable (and patient!), and often started conversations with me about topics like politics and philosophy. These conversations stretched my Spanish proficiency; in order to understand her and express my own thoughts, I was pushed toward more sophisticated word choice and grammar constructions.

In the programming world, interaction and negotiation for meaning are crucial for skill development and acquisition, particularly in the case of junior and mid-level developers looking to become senior-level engineers and architects. This negotiation for meaning unfolds clearly during pair and mob programming sessions, when developers type and record what others dictate. Code reviews, both synchronous or asynchronous, are also rich environments for programming language acquisition, as is the interaction that occurs between software developers as they try to understand and communicate around why certain strategies were used to solve a problem.

Learner output is another element necessary for language acquisition. In the early days of SLA, researchers thought a learner’s language production (through speaking or writing) was a sign that acquisition had already taken place; they didn’t believe output served an important role in the process of acquiring the language. 

In 1995, Merrill Swain proposed the Pushed Output Hypothesis to respond to this assumption. Swain argued that while receiving input in the form of reading and listening requires only semantic processing (or processing for meaning), producing language output in the form of speaking and writing requires syntactic processing (processing for form). The psycholinguistic demands of creating messages forces speakers to process language at a syntactic level beyond simply hearing those messages.

As a language teacher and traveler, I’ve often heard people qualify their foreign language ability in the following way: “I can understand German, but I can’t speak it very well.” If this self-assessment is true, it’s most likely because a person has been exposed to more input opportunities than to output opportunities. 

I experienced this imbalance while living in South Korea. Every day, I was overwhelmed with opportunities to listen to and read Korean, both through moving about the country in daily life, and in independently studying the language. However, I didn’t find many opportunities to practice speaking and writing in the language, much less opportunities for interaction and negotiation for meaning. 

Most Koreans I interacted with wished to practice their English with me, the English teacher. And who could blame them? That was why I was in the country, after all. But because of this, my speaking and writing proficiency were far lower than my receptive skills.

In the programming world, we see this concept play out when programmers immerse themselves in documentation, source code, and tutorials but never create anything with the target language or technologies. I’ve watched hours upon hours of Python tutorials, but that receptive practice is only going to get me half-way to being a functioning software engineer. In order to acquire Python programming skills, I need to produce output in the language. In other words, I need to actually sit down and write code.

This analogy can even be extended to speaking code. Programming languages are not traditionally spoken, but because writing code is a communal activity, we programmers have to be ready to confidently talk about our code and the technologies we’re utilizing with colleagues in many situations.

SLA researchers have spent decades trying to understand what environmental factors are necessary and sufficient for language learning. To date, no single factor has been found to be sufficient, but the powerful combination of input, interaction and output have long been recognized as necessary for language acquisition.

Of course, these research findings offer insight into only a mere sliver of a language learner’s situation. Ultimately, as Ortega notes:

“What matters in the linguistic environment is not simply ‘what’s out there’ physically or even socially surrounding learners, but rather what learners make of it, how they process (or not) the linguistic data and how they live and experience that environment.”

In other words, we as engineers have the responsibility to make the most of the environments we find ourselves in to learn and hone our software skills. If we can consciously take advantage of the learning opportunities those environments give us, then we might just be able to learn those programming languages and technologies even faster.

• Take some time to reflect on your coding environment. How do the factors of input, interaction and output manifest in that environment? Are these manifestations—and the ways you’re taking advantage of them—helping or hurting your learning?

• Take advantage of the ample input in your environment through activities like exploring parts of the codebase unfamiliar to you, participating in code reviews and seeking interactions with teammates both less and more experienced than you.

• Seek as many opportunities as possible to create output in the target language or technology, and create opportunities for interaction around this output by asking for feedback from multiple teammates.

• When asking programmers to learn a new technology or language or contribute to a code repository that is new to them, give them enough time to engage in focused learning. This means offering ample input through reading code to help them understand its form and function, as well as giving them opportunities to interact with the codebase’s primary authors and ask them clarifying questions before they’re asked to produce substantial output.

• Encourage your junior and mid-level engineers to seek formal or informal mentorship with senior engineers and architects. This sort of interaction will allow negotiation for meaning, clarification opportunities and comprehension checks that are crucial for learners.

• Create opportunities for pair programming and meaningful code reviews. These activities are rich in opportunities for input, interaction and output.

Lightbown, Patsy, Spada, Nina Margaret (2013). How languages are learned. Oxford: Oxford University Press.

Merrill Swain, Sharon Lapkin (1995). Problems in Output and the Cognitive Processes They Generate: A Step Towards Second Language Learning, Applied Linguistics, Volume 16, Issue 3.

Ortega, L. (2009). Understanding second language acquisition. Hodder Education.

Shinichi, Izumi (2003). Comprehension and Production Processes in Second Language Learning: In Search of the Psycholinguistic Rationale of the Output Hypothesis. Applied Linguistics, Volume 24, Issue 2.