SLA Insights Part 3: Noticing and Attitudes

In part one of this series, we introduced the academic discipline of Second Language Acquisition (SLA) and began examining the ways in which insights from the study of learning human languages can be applied to learning programming languages. We began this exploration with a focus on the sub-domain of language learner beliefs, looking at how learner beliefs can help or hinder the language acquisition process.

In part two, we introduced the linguistic environment and went in-depth on three elements that SLA researchers consider necessary for successful language learning: authentic language input, interaction with native speakers and meaningful language output. This article will focus on the two remaining elements: noticing and attitudes.

Many SLA researchers believe explicit noticing is necessary to language acquisition.

Lourdes Ortega writes:

In other words, we must consciously register the language element that is new to us in order to learn and ultimately acquire it. Consider the following English sentences:

I made dinner when she called.

I was making dinner when she called.

I had been making dinner when she called.

Each utilizes English’s time and aspect system in order to create sentences with unique meanings. These unique meanings (semantics) are achieved through verbal inflections and auxiliaries (syntax) like the ones bolded above. Without explicitly noticing the syntactic elements that create these sentences’ semantic differences, English language learners are unlikely to develop fluency in these language elements.

A common technique used in classroom materials and language learning textbooks is to utilize the same bolding method that I used above in order to call explicit attention to these language elements. This visual cue allows the learner to more easily notice whatever language feature is the focus of instruction.

As a software engineer, I have seen the importance of noticing very clearly in certain activities that engineers often engage in. Take code reviews, for example. As programmers, an important part of our job is to review and provide feedback on our teammates’ code. These code reviews present rich opportunities for learning — each of us engineers, after all, have a unique set of knowledge around the languages we know, and not a single one of us knows everything. I would argue that in any code review, there is some new element of the programming language to notice and learn.

Many reviewers, however, breeze through these reviews, hardly scrutinizing, sometimes not even fully understanding what they’re reading before approving the code. To be fair, we often don’t have time to fully scrutinize every line and character of these code changes. However, if we reviewers approach reviewing code as an opportunity to engage in concentrated learning — if we take some time to analyze, and thus notice the details — we can actually enhance and accelerate our own mastery of the language.

I view a successful code review as one in which I’ve learned something new about the language or technologies that I’m working with. When I first began learning Python and Django, I was already embedded on a team and scrutinizing the elements of that language and framework through the code of my teammates’ was how I narrowed down the scope of my learning. If I had taken the approach of simply perusing the official Python or Django documentation, I would have gotten lost in the weeds. Noticing specific elements of authentic code samples helped me learn what I needed to learn first.

Another benefit of this approach is that the authors of the code I was analyzing were a mere Slack message or impromptu Zoom call away. I could ask for clarification on a choice he or she had made very easily. 

One exercise that engineers can (and I daresay should) engage in is to identify a code mentor on another team, and ask if that mentor is willing to include the engineer as a reviewer on any pull requests the mentor submits. Spend even an hour of time reviewing part or all of the pull request in detail, taking care to notice those elements that are new, or unique strategies applied to common problems. You won’t have time to do this with every pull request, of course, but even just one a week will provide rich, authentic input for you to focus your noticing.

Positive attitudes toward the target language culture is the fifth environmental element important to language acquisition. According to Ortega:

In other words, having a positive attitude about the language and its native speakers is thought to be crucial for developing advanced fluency in that language.

Likewise, having a negative attitude towards the native-speaker community can remove motivation to learn that language. The experience of many migrant workers across the globe provides a poignant example of this effect. These workers are sometimes disparaged by a nation’s citizens for “refusing” to learn that nation’s official language; and yet, why would one want to learn a language that represents a community that confers hate onto members of your own culture and community?

Another sad example involves first-generation children of immigrants choosing not to learn their parents’ native language out of a strong desire to dissociate with the culture from which their parents immigrated.

How do we see attitudes toward target language communities manifest in the coding world? One example I’ve observed stems from the fact that many programming languages come bundled with a respective community. I’ve often heard phrases like the Java community. The Kotlin community. The Python community.

Many of these communities have reputations cultivated from within and outside the community itself. For example, I’ve heard Python programmers gush about the welcoming nature of the Python community, and Javascript developers highlight the Javascript community’s ingenuity. I’ve also seen and heard practitioners of one language openly disparage the practitioners of another language. The result is that programmers both new and experienced might be eager or resistant to learning a particular language because of general perceptions of that language’s community and a resultant desire to be associated with its practitioners, or not.

This is a fairly innocuous example, though. I believe that the demographic composition of the programming profession provides a more serious example of the negative effects of attitudes in the world of software engineering. Programming continues to be a male-dominated profession, both in the academic and business domains. This is especially true in certain business sectors and geographic regions.

When this demography leads to things like toxic masculinity, sexism and/or misogyny, it creates an environment hostile to folks outside this culture. For example, the fraternity-like culture of some startup teams has been off-putting, unwelcoming and — at its worst — openly hostile to non-male programmers. 

Imagine the collection of freshman women who decide not to pursue careers in computer science because they (rightly) have no desire to insert themselves into that culture, or the slew of engineers who ultimately decide to leave jobs or even the profession because the working environments they find themselves in are openly misogynstic. I recently heard a story from a female coworker about a time she was not invited to lunch by her male co-workers (she was the only female engineer at the company). The reason she wasn’t invited? They were headed to a strip club.

This sort of exclusion from the target community can be implicit, too. I’ve been fortunate to avoid extreme, blatant misogyny on the engineering teams to which I’ve belonged, but I have been linguistically excluded from the set of engineers on my team in ways that have — to be perfectly blunt — been demoralizing and discouraging. 

For example, I’ve often witnessed folks of all genders referring to a group of engineers to which I belong as “the guys.” As in, “Let’s get the guys to take a look at this bug,” or, “The guys did a great job of getting this deployed.” This always leaves me exasperated, wanting to raise my hand and say, “Um, hello? I actually built the backend for that particular feature.”

This is just part of why it’s so important that we work toward making under-represented groups feel welcome and heard in the tech community, and why it’s of utmost importance that managers hire diverse candidates who don’t look, act or sound like them. Not doing so might just be repelling a pool of excellent, capable engineers who don’t see themselves fitting into a company or on a team that is culturally homogenous.

• Increase your engagement with code reviews and speed up your acquisition by noticing unfamiliar code features and doing follow-up research, whether that be in the form of engaging with the code author, reading technical documentation or playing with the language feature in a sandbox.

• Noticing takes time and intention. Don’t burden yourself with the expectation that you can or will notice every new language element you encounter. You will not have time for this. Commit to noticing and recording a single new item once a day, for example. At the end of the week — on Friday — spend some dedicated time with each of those elements you’ve collected throughout the week to reinforce and broaden your understanding.

• Find a code mentor whom you admire or trust (ideally on another team, as you’ll have ample opportunity to review the code of people within your team) and ask if they’d be willing to include you as an optional reviewer on their pull requests. You’ll likely notice language features or elements that aren’t being used on your own team. Take time to understand these, and utilize your mentor for discussion around these items.

• Be aware of how you’re representing the coding communities to which you belong, and how your actions, behaviors and words might discourage folks new to that community from joining.

• Create opportunities for pair programming and meaningful code reviews. These activities are inherently rich in opportunities for noticing new language elements.

• Encourage your engineers to find a mentor on another team whose pull requests they can shadow. Emphasize that the goal is not necessarily to provide meaningful feedback on those pull requests (although this will likely be a side effect), but rather to expose the mentee to new language elements to be noticed.

• If your programmers are resistant to learning a new language or technology, understand how environmental influences like attitude toward the target language culture may play a role. This is especially important if you’re training members of your non-coding workforce to become programmers.

Address any cultural toxicities that exist in your engineering organization, especially if they result in the implicit or explicit exclusion of certain demographics. Be a positive force toward creating an engineering culture that is inclusive and celebratory of all engineers, no matter their demographic attributes.