Technical English vocabulary for developers

Technical English for Programmers: Error Messages, API Docs, Code Comments, and Jargon

A practical vocabulary guide for Spanish-speaking developers who read error messages, API documentation, and code comments every day in English.

Key Takeaways

Error messages have three parts: type, description, and location. Copy only the description when searching.
API doc vocabulary (deprecated, nullable, throws, idempotent) is the same across all languages and frameworks.
TODO means a task. FIXME means a known bug. HACK means ugly-but-working. NOTE means important context.
English naming conventions (camelCase, snake_case, PascalCase) are mandatory in open-source projects.
Technical jargon like 'yak shaving', 'footgun', and 'bikeshedding' is everywhere in developer communication.

The English you read every day as a developer

El inglés que lees todos los días como developer

You are not reading a novel. You are reading a stack trace, a GitHub README, a JSDoc comment, or a Stripe API reference. This kind of English has its own patterns, its own vocabulary, and its own conventions.

This guide covers the technical English that lives inside your tools: how to read and search error messages, what words like `deprecated`, `nullable`, and `throws` mean in API docs, what `TODO`, `FIXME`, and `HACK` signal in code comments, why naming conventions in English matter for open-source work, and a glossary of 16 high-frequency jargon terms you will encounter in every team that works in English.

This is not a general English guide. It complements the workflow guide at /ingles-para-programadores, which covers standups, meetings, pull requests, and interviews. This one is about the vocabulary inside the code.

What is in this guide

1. Error messages: how to read and search them
2. API documentation vocabulary: deprecated, returns, throws, nullable
3. Code comment conventions: TODO, FIXME, HACK, NOTE
4. Naming conventions in English: why they matter in open-source
5. Technical jargon glossary: 16 terms every developer needs

Error Messages: How to Read and Search Them

Mensajes de error: cómo leerlos y buscarlos

Error messages follow a pattern. Once you recognize the pattern, you can extract the information you need in seconds, even if you do not understand every word.

A typical error message has three parts: the error type, a human-readable description, and a location (file, line number, column). Here is a Node.js example:

TypeError: Cannot read properties of undefined (reading 'map')
    at UserList (/app/components/UserList.jsx:12:22)
    at renderWithHooks (/app/node_modules/react-dom/cjs/react-dom.development.js:14985:18)

TypeError

The error type. In JavaScript: TypeError, ReferenceError, SyntaxError, RangeError. Each type tells you the category of problem.

Cannot read properties of undefined (reading 'map')

The human-readable description. This is what you paste into Google. Always copy the description, not the full stack trace.

at UserList (/app/components/UserList.jsx:12:22)

The location. File path, line 12, column 22. This is where your code is.

When you search for an error, paste only the message, not the file paths. File paths are specific to your project and will return no results. The message is what other developers have seen before.

Traceback (most recent call last):
  File "main.py", line 8, in <module>
    result = divide(10, 0)
  File "main.py", line 4, in divide
    return a / b
ZeroDivisionError: division by zero

Python shows a traceback, which is the call stack in reverse order. Read from the bottom up: the last line is the error, and the lines above it show you how the code got there.

Tips for searching error messages

1.Remove the parts specific to your project (file names, variable names).
2.Add the language or framework: "Python ZeroDivisionError", "React TypeError cannot read properties".
3.Add the library version if the error is in a dependency.
4.If Google returns nothing, try Stack Overflow directly with the exact error message in quotes.

API Documentation Vocabulary

Vocabulario de documentación de APIs

API documentation follows conventions. Once you know the vocabulary, you can read any API reference, whether it is Stripe, GitHub, AWS, or a library you have never used before.

Term	What it means	Example from docs
deprecated	This feature still works but will be removed in a future version. Do not use it in new code.	@deprecated Use `getUserById` instead. This method will be removed in v4.0.
returns	What the function gives back. Always followed by the type and a description.	@returns {Promise<User>} The user object, or null if not found.
throws	What error the function raises if something goes wrong. Important for error handling.	@throws {AuthError} If the token is expired or invalid.
nullable	The value can be null. You must check for null before using it.	user.avatarUrl: string \| null: nullable. Check before rendering.
optional	The parameter does not have to be provided. Has a default value or can be undefined.	function createUser(name: string, role?: string): role is optional.
idempotent	Calling this endpoint multiple times with the same input has the same effect as calling it once. Safe to retry.	DELETE /users/:id is idempotent: deleting a user twice leaves the user deleted.
paginated	The response returns a subset of results. Use cursor or page parameters to get the rest.	GET /orders returns 20 results by default. Use ?page=2 to get the next 20.
rate limited	The API limits how many requests you can make in a time window. Exceeding it returns a 429 error.	This endpoint is rate limited to 100 requests per minute per API key.

JSDoc is the most common format for JavaScript/TypeScript API documentation. You will also see OpenAPI (for REST APIs), rustdoc (Rust), and godoc (Go). The vocabulary above applies to all of them.

Code Comment Conventions: TODO, FIXME, HACK, NOTE

Convenciones de comentarios en código: TODO, FIXME, HACK, NOTE

These tags are not official syntax, they are conventions that every developer on every team uses. Your editor highlights them. GitHub search can find them. They communicate intent and urgency.

TODOurgency: low to medium

Something that needs to be done but is not done yet. Not a bug. Often left during a sprint when you know you will come back to it.

// TODO: add pagination once the dataset grows beyond 1000 records

FIXMEurgency: medium to high

There is a known bug here. The code works for now but will break under certain conditions. Higher urgency than TODO.

// FIXME: this breaks if the user has no address: null check needed

HACKurgency: varies

This works but the implementation is ugly, brittle, or relies on something it should not. A technical debt marker.

// HACK: the API returns dates as strings in 'DD/MM/YYYY' format: parse manually until we migrate to ISO 8601

NOTEurgency: informational

Important context for anyone reading this code. Not a bug, not a task, just something you need to know.

// NOTE: this endpoint is called by the mobile app: do not change the response shape without coordinating with the mobile team

When you leave a TODO or FIXME, add your name and the date if your team does not use a ticket tracker: `// TODO(alex, 2024-03): move this to a background job`. This helps future developers understand whether the comment is still relevant.

Naming Conventions in English

Convenciones de nomenclatura en inglés

In open-source and international teams, English naming conventions are not optional. A function named `obtenerUsuario` in a Python project that the whole world contributes to will not get merged. Here is what you need to know.

Convention	Used in	Examples	Note
camelCase	JavaScript/TypeScript: variables, functions, methods	getUserById, isAuthenticated, maxRetries	Starts with a lowercase letter. Each new word starts with uppercase.
PascalCase	JavaScript/TypeScript: classes, React components, types, interfaces	UserService, AuthProvider, HttpError	Starts with uppercase. Each new word starts with uppercase.
snake_case	Python: variables, functions, module names. Also: SQL columns, environment variables.	get_user_by_id, is_authenticated, max_retries	All lowercase. Words separated by underscores.
SCREAMING_SNAKE_CASE	Constants in most languages, environment variables	MAX_RETRY_COUNT, DATABASE_URL, API_KEY	All uppercase. Words separated by underscores.
kebab-case	URLs, CSS class names, file names (in many projects)	user-profile, login-button, get-started.tsx	All lowercase. Words separated by hyphens.

Naming principles

Name things in English, even in private projects. You will thank yourself when you share the code.
Use full words, not abbreviations: `getUserById` not `getUsrById`. `response` not `res` (unless it is a well-known abbreviation in the framework).
Boolean variables and functions should read like a question: `isLoggedIn`, `hasPermission`, `canDelete`.
Functions that return values should start with a verb: `getUser`, `fetchOrders`, `calculateTotal`.
Avoid generic names: `data`, `info`, `thing`, `stuff`. Be specific: `userProfile`, `orderItems`, `errorMessage`.

Technical Jargon Glossary

Glosario de jerga técnica

These are the terms you will hear in code reviews, architecture discussions, and Slack threads. They are not in standard English dictionaries. Spanish-speaking developers often encounter them without context.

Term	Spanish	Example sentence	Note
legacy	código heredado / antiguo	We cannot refactor that module: it is legacy code that three other services depend on.	Often used to mean old code that is hard to change, not necessarily bad.
edge case	caso borde / caso extremo	What happens if the user has no email address? That is an edge case we need to handle.	An input or condition at the boundary of what the system is designed to handle.
race condition	condición de carrera	If two requests hit this endpoint at the same time, you get a race condition and duplicate records.	A bug that only occurs when two operations run in parallel and their order matters.
footgun	trampa / arma contra uno mismo	Mutable default arguments in Python are a classic footgun.	A feature of a language or tool that makes it easy to accidentally shoot yourself in the foot (cause a bug).
idempotent	idempotente	Make sure the migration script is idempotent so we can run it multiple times without side effects.	An operation you can perform multiple times and get the same result as doing it once.
backfill	rellenar / retroalimentar datos	We need to backfill the `created_at` column for existing users.	To fill in missing historical data, usually in a database migration or analytics pipeline.
shim	adaptador / capa de compatibilidad	We added a shim so the old API clients still work after the endpoint change.	A thin layer of code that makes one interface compatible with another.
bikeshedding	debatir trivialidades / perder el tiempo en lo irrelevante	We spent an hour bikeshedding over the button color instead of reviewing the architecture.	Spending disproportionate time on trivial decisions while ignoring important ones. From Parkinson's Law of Triviality.
yak shaving	hacer tareas previas interminables para llegar al objetivo real	I started by adding a feature, ended up yak shaving: upgrading Node, fixing the build, updating types.	A chain of prerequisite tasks you have to complete before you can do the original task.
rubber duck debugging	depurar explicando el problema en voz alta	I explained the bug to a rubber duck and realized the problem myself before asking for help.	The technique of explaining your code out loud to an inanimate object (traditionally a rubber duck) to find the bug.
DRY	No te repitas (Do Not Repeat Yourself)	Extract that logic into a helper function. DRY principle.	Every piece of knowledge should have a single, unambiguous representation in the system.
YAGNI	No lo vas a necesitar (You Are Not Gonna Need It)	Do not build that abstraction yet. YAGNI: we will add it when we actually need it.	Do not add functionality until it is necessary. Prevents over-engineering.
KISS	Mantenlo simple, estúpido (Keep It Simple, Stupid)	This could be a simple if-else. KISS. Do not over-engineer it.	Prefer the simplest solution that works. Complexity is a liability.
tech debt	deuda técnica	We shipped fast but we took on tech debt. We need a sprint to pay it down.	The implied cost of future rework caused by choosing a fast, easy solution now instead of a better approach that would take longer.
greenfield	proyecto nuevo / desde cero	This is a greenfield project. We chose the stack ourselves with no legacy constraints.	A project built from scratch with no existing codebase to work around.
brownfield	proyecto con código heredado / existente	It is a brownfield project. Every change has to be backward compatible.	A project built on top of existing code, with the constraints that come with it.

Ready to practice your English at work?

Lingua-e has interactive exercises built around real developer conversations: standups, code reviews, retrospectives, and more. Practice until it comes naturally.

Try Lingua-e for free

Written by

Roxana Lafuente

Lingua-e's founder

Roxana Lafuente is a software engineer with 8+ years of experience. At the beginning of her career, even though she had already passed the First Certificate in English, she still froze every time she had to speak up in the daily standup. That was a gap nobody was fixing. After 2,000+ standups, she figured out what actually builds fluency: practice that looks like your real work. She built Lingua-e so other developers wouldn't have to take the long road to feel confident working in an international development environment.