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.

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 CS Learning", presented 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.

What this implies for teaching

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.

1. Let learners reason in their first language. Pair work, comments, notes, and planning do not have to happen in English for the code to be correct.
2. Provide a glossary of terms, not just of keywords. The informal vocabulary — "loop through", "pass in", "call", "return" — is the part that quietly excludes.
3. Explain error messages explicitly as a teachable text genre rather than assuming they are self-evident.
4. Separate language comprehension from problem difficulty in problem statements: short sentences, no idiom, no culturally specific framing.
5. Give a low-stakes route to ask questions — written, asynchronous, or anonymous — because the spoken channel carries the highest language cost.
6. Do not read hesitation as inability. It is the single most consequential misreading in an introductory classroom.

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.

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.

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.