Learning to program in your second language

The problem, stated plainly

Introductory programming asks a novice to hold several new things at once: the syntax of a language, a mental model of how a machine executes it, and a problem-solving method. Cognitive load in that first course is high for everyone.

For a bilingual learner, an additional layer sits on top of all of it. The lecture is in a second language. The textbook is in a second language. Keywords, error messages, documentation, and the informal vocabulary instructors use to explain concepts are all in a second language — while the reasoning itself, the internal narration of "if this is empty then I need to…", often still happens in the first.

The result is that a learner can be translating and programming simultaneously, and the cost of the translation is invisible from the outside. It looks like slowness, or hesitation to speak in class, or reluctance to ask questions — and it is frequently misread by everyone involved, including the learner, as lack of aptitude for programming.

The cognitive-load framing, with the load made concrete

Cognitive load theory splits the demand a task places on working memory into three parts: intrinsic load, which is the irreducible difficulty of the material itself; extraneous load, which is everything the presentation adds without teaching anything; and germane load, which is the effort that actually builds a mental model. The design goal in any instruction is to cut extraneous load so that the remaining capacity goes to germane load.

Estimates of how many genuinely novel elements working memory can hold at once cluster around four. Introductory programming already spends that budget: syntax, execution model, and problem decomposition are three, and the fourth is usually the specific concept of the week. A second-language layer is not a fifth item — it is a tax on every one of the four, because each of them arrives wrapped in vocabulary that has to be resolved before it can be thought about.

What that tax looks like in the specific:

• A loop header. for item in items: reads to a native speaker as almost-English and is nearly free. For a learner who parses for, in, and the plural convention as arbitrary tokens, the same line is three lookups before the semantics start.
• An error message. TypeError: unsupported operand type(s) for + contains at least four pieces of technical vocabulary, in a compressed register, with no context sentence. It is the primary feedback channel in a first course and it is written for people who already know what it means.
• Idiom in a problem statement. "Walk the tree", "flatten the list", "running total", "roll your own", "under the hood". None are literal, none are in a dictionary in the sense that helps, and misreading one produces a correct solution to a different problem.
• Instructor speech. Lectures are delivered at conversational speed with no rewind, and the informal explanation is usually the version that would have made it click.
• The question you do not ask. Articulating a half-formed technical confusion is hard in a first language. In a second, in front of peers, the cost frequently exceeds the perceived benefit, so the confusion persists and compounds.

The critical property is that this tax is per encounter, not once. A first course exposes a student to dozens of distinct error messages, hundreds of vocabulary items, and a new problem statement every week. Individually each cost is small. Aggregated across a semester, it is the difference between a course that is difficult and a course that is exhausting.

Why the language layer matters more than it seems

• Error messages are the primary feedback channel in early programming, and they are terse, idiomatic, and entirely in English.
• Keywords carry semantic hints — while, return, continue — that help a native speaker guess behaviour and do nothing for a learner who parses them as arbitrary tokens.
• Problem statements are natural-language comprehension tasks before they are programming tasks. A misread word produces a correct solution to the wrong problem.
• Asking for help has a language cost. Articulating a half-formed technical confusion is hard in a first language and considerably harder in a second, so questions go unasked.
• Confidence is the thing that erodes first, and in introductory CS confidence predicts persistence — whether a student stays in the major at all.

What the study examined

That last point is what our study went after. The paper — "Exploring Bilingual Coding for Inclusive Computer Science Learning", published at the SIGCSE Technical Symposium 2026 (DOI 10.1145/3770761.3777339) — was conducted in Dr. Ethel Tshukudu's CS Education Research Lab at San José State University.

The mixed-methods design was not decoration. Confidence is a self-reported construct, so the quantitative side establishes that it moved and by how much, while the qualitative side — learners describing their own experience in their own words — is what indicates why, and surfaces the parts of the experience that no pre-written scale asks about.

The finding

The study reported statistically significant pre-to-post gains in learner confidence, alongside gains in computing identity, enjoyment and motivation — with inexperienced participants gaining significantly more in confidence than experienced ones. That is the headline result, and it is worth being precise about what it does and does not claim. The bilingual-versus-English-only comparison itself came out small-to-moderate in effect size and did not reach statistical significance.

The measured outcome is confidence, not a claim that bilingual support makes anyone a better programmer in the abstract. In introductory CS that distinction matters less than it sounds, because confidence is one of the stronger predictors of whether a student continues in computing at all — the students lost to CS are frequently lost before their capability was ever the binding constraint.

The mechanism the qualitative side points at is unsurprising once stated: reducing the translation overhead frees attention for the actual computational thinking, and being permitted to reason in your stronger language removes a barrier that had nothing to do with programming ability in the first place.

How confidence gets measured, and why the numbers are not enough

Confidence in CS education research is generally measured with a validated self-report instrument: a set of Likert-scale items administered before and after an intervention, with responses matched per participant so the analysis is on the change within a person rather than on a difference between two groups of people. Related constructs — computing identity, enjoyment, motivation, sense of belonging — are measured the same way, on their own item sets.

That approach is standard and it has known weaknesses, all of which point in different directions:

• Response-shift bias. As learners get better they recalibrate what a "4 out of 5" means to them. Someone who has genuinely improved may rate themselves lower afterwards because their standard rose, which suppresses measured gains rather than inflating them.
• Social desirability and demand characteristics. Participants who know the study is about a support intervention have a rough idea of the answer that pleases, which pushes the other way.
• Acquiescence and scale use. Agreement bias and cultural differences in whether people use the extremes of a scale both affect a cross-group comparison more than they affect a within-person change.
• Construct slippage. "Confidence" is not one thing. Confidence in writing a loop, in debugging, in asking a question in class, and in belonging in the major are different, and an instrument that averages them can hide movement in opposite directions.
• Self-report is not performance. A confidence gain is not a demonstrated skill gain, and treating the two as interchangeable is the most common misreading of results like these.

This is precisely why the qualitative side is load-bearing rather than decorative. Interviews and open responses catch the participant who says the number went up because the class got easier, or that it went down because they finally understood how much they did not know — neither of which any scale would have recorded, and both of which change what the number means.

Threats to validity, stated honestly

A study with 60 participants at one institution has real limits, and the useful move is to state them rather than to let a reader assume they are absent.

• The pre-post design has no counterfactual. Confidence tends to rise across any introductory course as students simply gain exposure, so a significant within-person gain cannot be attributed to the bilingual element on its own. Maturation, instruction, and practice are all uncontrolled alternative explanations.
• The between-condition comparison was underpowered — see the arithmetic below. That is the specific reason the bilingual-versus-English-only contrast came out non-significant, and it is a fact about the study's resolution rather than about the world.
• Single institution, single context. One university's student population, one set of instructors, one course structure. Generalisation to other institutions, other first languages, or other course designs is a hypothesis and not a finding.
• Self-selection. Participants in an education study are volunteers, and volunteers for a study about language support are unlikely to be a random sample of bilingual learners.
• Attrition and matching. Any pre-post design loses participants between the two measurements, and who leaves is rarely random.
• Ceiling and floor effects. Participants already at the top of a five-point scale cannot register a gain, which compresses exactly the group you would expect to gain least.

The power arithmetic

The bilingual-versus-English-only comparison produced an effect size in the range of Cohen's d 0.25 to 0.40 and did not reach statistical significance. The standard sample-size approximation for a two-group comparison at 80% power and a 5% significance level shows why that is unsurprising:

n per group ≈ 2 · (z_alpha/2 + z_beta)² / d² = 2 · (1.96 + 0.84)² / d² = 15.7 / d² d = 0.25 → 15.7 / 0.0625 ≈ 251 per group d = 0.30 → 15.7 / 0.0900 ≈ 175 per group d = 0.40 → 15.7 / 0.1600 ≈ 98 per group A 60-participant study split across conditions is well below every one of those thresholds. At this size, a true effect in that range would be expected to come out non-significant most of the time.

That calculation is the honest reading of the result. A non-significant comparison in an underpowered design is uninformative about whether the effect exists, in either direction. It is the statistical equivalent of failing to see something with the wrong instrument, and it is a mistake to report it as evidence of no difference.

What the non-significant comparison does and does not license

The rule that keeps a small study honest is to report the effect size and the interval alongside the significance test, and to describe a null result as "we did not detect a difference at this sample size" rather than as "there is no difference". The two sentences sound similar and mean completely different things.

What instructors can actually do

The practical implications are cheap to act on, which is the useful property of this line of work — none of it requires a new curriculum or a budget. What follows is separated deliberately into what the study speaks to and what is general practice, because conflating the two is how a modest finding turns into an overclaim.

Note the shape of that table. Most of these cost nothing and risk nothing, which is the reason the significance question matters less for deciding whether to do them than it would for a costly change. A zero-cost intervention with a plausible small benefit and no downside is worth adopting on expected value alone; a semester of faculty time spent rewriting a curriculum is not justified by this evidence and should wait for a better-powered result.

Implications for curriculum design

1. Separate language difficulty from problem difficulty on purpose. If an assessment is meant to test loops, the prose describing the task should be the simplest possible English, otherwise you are partly measuring reading comprehension and reporting it as programming ability.
2. Treat error messages as taught content. Put five real messages on a slide, decode them line by line, and name the vocabulary. It is fifteen minutes and it improves the channel students use most.
3. Build the low-stakes question route before week one, not after the first student disappears. The spoken channel has the highest language cost and it is the default in most classrooms.
4. Design assessment so first-language planning is legitimate. If comments, pseudocode, and pair discussion can happen in any language, the extraneous load drops with no effect on what is being assessed.
5. Collect the data while you change things. A pre-post instrument costs a few minutes of class time per administration, and a department that runs one gets a real answer about its own population rather than importing one from a study at a different institution.
6. Scope the claim to the evidence. A department can adopt every item above without asserting that any of them is proven, and should say so — overclaiming is how good pedagogy gets discredited when a replication comes back flat.

Why this is a research area at all

Global CS enrolment is substantially bilingual, and the field's introductory materials are overwhelmingly English-language. Any factor that pushes capable students out of computing before their capability is the constraint is a retention problem worth measuring, and language is one of the few such factors that is both large and inexpensive to address.

What a better-powered follow-up would look like is not mysterious: multiple institutions, several hundred participants per condition, pre-registered hypotheses and analysis plan, a behavioural or performance outcome alongside the self-report, and enough qualitative depth to explain whatever the numbers do. That is a considerably larger project than a single lab's study, which is exactly why the small one has to be reported precisely enough to justify the large one.

The full paper is at doi.org/10.1145/3770761.3777339. How undergraduates get into work like this in the first place is covered in the undergraduate research guide, CODESWITCH is the bilingual intro-CS programme built out of this line of work, and the current project list is on the research page. Terminology used across these guides is defined in the glossary.

Tools referenced in this guide

• Undergraduate research guide — how to find a lab, email a professor, and reach authorship.
• About — the lab, the papers, and current projects.
• Apps — the tools I build outside the research work.