You write a script, save it, and try to run it:

$ ./deploy.sh
-bash: ./deploy.sh: Permission denied

The file is definitely there. cat deploy.sh prints it out fine. Nothing about the content is wrong. But the shell won't run it, and "Permission denied" sounds like something is badly broken — like the file itself is corrupted or off-limits. It isn't. It's missing one specific, easy-to-forget permission bit, and nothing else.

What's actually happening

Every file on a Linux (or macOS) system carries three separate permissions for three separate groups: the owner, the group, and everyone else. Each group can independently have read, write, and execute permission. ls -l shows this as a ten-character string:

$ ls -l deploy.sh
-rw-r--r-- 1 you staff 214 Sep 12 09:03 deploy.sh

Read that as three sets of three: rw- (owner: read, write, no execute), r-- (group: read only), r-- (everyone else: read only). Notice what's missing — there's no x anywhere in that string. The file is fully readable, which is why cat works and why the script's contents display just fine in an editor. But readable and executable are two completely different permissions, and creating a new file — via a text editor, touch, or copying one — doesn't grant execute permission by default. Nothing you did was wrong; that's simply not part of a new file's starting permissions.

Permission denied here isn't the system protecting something sensitive. It's the system accurately reporting that you haven't yet told it this particular file is meant to be run as a program.

The fix, step by step

1. Confirm this is actually the problem. Run ls -l on the file and look for an x in the owner's permission set (the first three letters after the leading -). If it's not there, this is exactly what's happening.

2. Add execute permission:

   chmod +x deploy.sh
   

   This adds execute permission for everyone the file's other permissions already allow — for a typical personal script, that's enough. Confirm it worked:

   $ ls -l deploy.sh
   -rwxr--r-- 1 you staff 214 Sep 12 09:03 deploy.sh
   

   Now there's an x in the owner's set.

3. Run it again the same way you did before:

   ./deploy.sh
   

   No other change needed — the script's content was never the issue.

Two mistakes worth knowing about ahead of time

Reaching for sudo because "permission" sounds like an authority problem. sudo ./deploy.sh will not fix this — it re-runs the same command as another user, but the file still has no execute bit for anyone, so it fails the same way. sudo solves "you don't have rights to do this," not "this file hasn't been marked runnable yet." Those are genuinely different problems that happen to share the word "permission."

Forgetting the ./ and typing just deploy.sh. This produces a different error entirely — usually command not found — because the shell only searches directories listed in PATH for bare command names, and your current directory almost never is one of them. ./ explicitly means "run the file right here," which is what actually triggers the execute-permission check in the first place. If you're troubleshooting "permission denied" and you're not seeing that exact message, double check you're invoking the file the same way.

A habit that prevents the confusion entirely

Any time you write a new script you intend to run directly, chmod +x it in the same breath as saving it — before you ever try to run it the first time. Treat it as part of "finishing the script," not a fix you reach for after an error. Scripts you download or copy from elsewhere often already have execute permission preserved (or explicitly need it added once, on purpose) — but anything you create fresh with an editor starts without it, every time, and that's expected behavior, not a bug to work around.

If you'd like more posts like this sent straight to your inbox, subscribe to the newsletter.

Prefer to dig in yourself? The Command Line Essentials repo on GitHub has more free examples and exercises.

You created a virtual environment, activated it, installed your packages — and VS Code still can't find them. Or the opposite: IntelliSense recognizes everything perfectly, but running the file in the terminal throws ModuleNotFoundError for a package you know is installed. Either way, it feels like VS Code is lying to you about something as basic as which Python it's using.

It isn't lying. It's just tracking two separate things that happen to look like one.

What's actually happening

VS Code has two independent ideas of "your Python," and they don't automatically sync:

The selected interpreter is what the Python extension uses for IntelliSense, linting, and Go to Definition. It's set explicitly — via the Status Bar or the Python: Select Interpreter command — and it sticks until you change it, regardless of what else happens in your project.

The terminal's active environment is whatever shell state is in effect when a terminal panel opens — usually whichever python resolves to on your PATH at that moment, or whatever a venv's activation script last set.

These can drift apart easily. Selecting an interpreter in the Python extension doesn't retroactively fix terminals you already had open. Opening a new terminal after switching interpreters usually auto-activates the matching environment — but "usually" is doing a lot of work in that sentence, and older terminal panels never get updated at all. The result: IntelliSense and the terminal can each be confidently, independently wrong about which Python is "the" Python, and neither one will tell you the other disagrees.

The fix, step by step

1. Check what IntelliSense thinks first. Look at the Status Bar at the bottom of the window — it shows the currently selected interpreter (something like Python 3.11.4 ('venv': venv)). If this is wrong, run:

   Python: Select Interpreter
   

   and pick the correct one. This fixes IntelliSense, linting, and autocomplete — but not yet the terminal.

2. Check what the terminal thinks, separately. In an actual terminal panel, run:

   which python    # macOS/Linux
   where python    # Windows
   

   Compare that path against the interpreter shown in the Status Bar. If they don't match, that's the whole problem — you have two different Pythons active in two different places.

3. Open a fresh terminal after fixing the interpreter. Close the old terminal panel and open a new one (Ctrl+Shift+`). A new terminal typically auto-activates the environment matching the currently selected interpreter — an already-open one will not retroactively update.

4. If the new terminal still doesn't auto-activate, activate the environment manually, the same way you would outside VS Code:

   source venv/bin/activate    # macOS/Linux
   venv\Scripts\activate       # Windows
   

Two mistakes worth knowing about ahead of time

Assuming "it works when I hover over the import" means the whole file will run correctly. IntelliSense resolving a package tells you the selected interpreter can see it — it says nothing about what a terminal's python file.py will use. These are genuinely separate checks, and passing one is not evidence for the other.

Installing a package a second time because "it's still not found." If pip install in a terminal reports success but the error persists, the terminal and the interpreter installing packages may not be the same Python. Check which python / where python before reinstalling anything — you may be about to install into an environment nothing is actually reading from.

A habit that prevents the confusion entirely

Whenever a project stops finding a package it should have, check both sides before touching anything: the Status Bar for what IntelliSense is using, and which python / where python in the terminal you're about to run code in. If those two don't match, you've found the entire bug already — no reinstalling, no deleting node_modules-style folders, no guessing. Open a new terminal, confirm it matches, and move on.

If you'd like more posts like this sent straight to your inbox, subscribe to the newsletter.

Prefer to dig in yourself? The VS Code Essentials repo on GitHub has more free examples and exercises.

You add one more column to a GROUP BY query, run it, and get this instead of results:

ERROR: column "products.name" must appear in the GROUP BY clause
or be used in an aggregate function

The query looked reasonable. Nothing is misspelled. But SQL is refusing to run it at all — not returning wrong data, just flatly declining. That refusal is the whole story: SQL isn't confused about syntax, it's telling you the question you asked doesn't have a single correct answer.

What's actually happening

SELECT category, name, COUNT(*) FROM products
GROUP BY category;

GROUP BY category collapses every row into one row per category. That's the point of grouping — dozens of individual product rows become a handful of category rows. But name is a per-row value, and each category groups together many different products, each with its own name. Once those rows are collapsed into one, which product's name is supposed to show up in the result?

There's no good answer, and SQL doesn't guess. Every column in the SELECT list has to be something that still makes sense after the collapse: either a column named in GROUP BY (one value per group, by definition), or the output of an aggregate function like COUNT(), SUM(), or MAX() (a value computed from the whole group, so it's well-defined no matter how many rows are in it). name is neither — it's a leftover from before the grouping happened, and the database won't silently pick one at random on your behalf.

The fix, step by step

1. Decide what you actually want name to mean in a grouped result. There are two real answers, and the fix depends on which one you meant:

2. If you wanted one row per product, not per category — you probably don't want to group by category at all, or you need category and name to define the group together:

   SELECT category, name, COUNT(*) FROM products
   GROUP BY category, name;
   

   Now each group is one specific product within one category, so name has exactly one value per group.

3. If you genuinely only want one row per category, drop the column that doesn't belong at that level:

   SELECT category, COUNT(*) FROM products
   GROUP BY category;
   

4. If you wanted some representative name, not every name, wrap it in an aggregate that resolves the ambiguity on purpose — MIN(name), MAX(name), or, on databases that support it, STRING_AGG(name, ', ') to list all of them:

   SELECT category, STRING_AGG(name, ', ') AS product_names, COUNT(*)
   FROM products
   GROUP BY category;
   

Two mistakes worth knowing about ahead of time

Reaching for MAX() or MIN() just to make the error disappear. It works — the query runs — but if you didn't actually mean "the alphabetically last name," you've just replaced a clear error with a quietly wrong result. MAX()/MIN() are the right tool when you deliberately want a representative value, not a reflexive fix for an error you haven't read.

Assuming this error means the query is broken. It's the opposite: this is one of the few SQL errors that catches a real logical mistake before it produces bad data instead of after. A query that ran without complaint and silently picked one arbitrary name per group (which is what some databases, like older MySQL configurations, actually did before enforcing this rule) is far more dangerous than one that stops and asks you to clarify.

A habit that prevents the confusion entirely

Before adding any column to a GROUP BY query's SELECT list, ask what it's supposed to represent once rows collapse into groups: one value per group (put it in GROUP BY), a computed summary across the group (wrap it in an aggregate), or something else — in which case it probably means you're grouping by the wrong thing, or trying to answer two different questions in one query. The error isn't the database being pedantic. It's the one moment SQL forces you to answer a question you'd otherwise skip past.

If you'd like more posts like this sent straight to your inbox, subscribe to the newsletter.

Prefer to dig in yourself? The SQL Essentials repo on GitHub has more free examples and exercises.

You check out a specific commit to look at some old code, and Git prints this:

Note: switching to 'a3f92c1'.

You are in 'detached HEAD' state...

HEAD is now at a3f92c1 Fix login redirect

Nothing crashed. There's no red text, no error:, no fatal:. But "detached HEAD" sounds like something broke, so the instinct is to back out immediately and hope nothing was damaged. Nothing was.

What's actually happening

Normally, HEAD — Git's pointer to "where you currently are" — points at a branch, and that branch points at a commit. When you commit, the branch moves forward and HEAD moves with it, because HEAD is really just following the branch.

Checking out a specific commit directly (instead of a branch name) breaks that chain on purpose. HEAD now points straight at the commit, with no branch in between — "detached" from any branch. Git isn't warning you about damage. It's telling you, accurately, that if you commit right now, those commits won't belong to any branch — and will be effectively orphaned the moment you check out something else.

That's the entire risk: not corruption, just the possibility of doing new work in a spot Git won't automatically keep track of.

The fix, step by step

1. If you're just looking around — reading old code, checking what a file looked like at that commit — you don't need to do anything. Look, then check out main (or whatever branch you were on) when you're done:

   git checkout main
   

   Nothing you did in detached HEAD state affects your branches at all.

2. If you started making changes and want to keep them, don't switch branches yet — that's the one action that can strand your work. Instead, turn your current position into a real branch:

   git checkout -b recovery-branch
   

   This creates a new branch pointed at exactly where you are, commits and all, and reattaches HEAD to it. Nothing is lost.

3. If you made commits, switched away, and now can't find them, they're almost certainly still there — just unreferenced by any branch. git reflog shows every position HEAD has recently been at, including ones no branch points to:

   git reflog
   git checkout - recovery-branch <commit-hash>
   

Two mistakes worth knowing about ahead of time

Panicking and running something destructive. Detached HEAD state is not an error state — it's a completely normal, intentional part of how Git works, used constantly for things like checking out a tag or reviewing history. Running git reset --hard or anything else "just to be safe" is far more likely to lose work than the detached state itself ever was.

Making real changes without realizing you're still detached. This is the only version of this situation that can actually bite you — writing several commits' worth of work while detached, then checking out main without first branching off, which leaves those commits reachable only through git reflog (and reflog entries eventually expire). If you're not sure whether you're attached to a branch, git status tells you immediately — it says HEAD detached at <commit> right at the top when you're in this state, and names your branch when you're not.

A habit that prevents the scary version entirely

Before doing any real work after a git checkout <commit-hash>, get in the habit of checking git status first. If it says detached, branch off with git checkout -b before writing a single line — that one habit turns "I might have lost my commits" into "I never could have lost my commits" every time.

If you'd like more posts like this sent straight to your inbox, subscribe to the newsletter.

Prefer to dig in yourself? The Git & GitHub repo on GitHub has more free examples and exercises.

You write a loop that should print 0, 1, and 2, one second apart. Instead you get three 3s.

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 1000);
}
// 3
// 3
// 3

Nothing crashed. No error. The values just aren't what the loop clearly seems to promise. The first instinct is usually to suspect setTimeout itself — some kind of timing quirk, a race condition, maybe the callbacks are firing out of order. None of that is what's happening.

What's actually happening

var is function-scoped, not block-scoped. That means every single pass through the loop isn't creating a new i — there's exactly one i for the entire loop, shared by all three setTimeout callbacks. By the time any of those callbacks actually runs (a full second later, long after the loop has already finished all three iterations), i has already reached its final value: 3. All three callbacks look up the same variable, at the same moment, after the loop is long done — so they all see the same thing.

This isn't a bug in setTimeout, and it isn't a race condition. The loop runs to completion essentially instantly; the callbacks are what's delayed, and they're all reading from a single shared box that's already empty of the values you wanted by the time they check it.

The fix, step by step

1. Recognize the signature: a loop paired with a callback or setTimeout, where every output is identical — and it's always the final value the loop variable reached, never the first or the middle ones.
2. Change var to let:

   for (let i = 0; i < 3; i++) {
     setTimeout(() => console.log(i), 1000);
   }
   // 0
   // 1
   // 2
   

3. Understand why that one-word change works: unlike var, let is block-scoped — it creates a new i, freshly bound, for every single iteration of the loop. Each setTimeout callback closes over its own separate i, not one shared variable, so each one remembers the value it was handed at that specific point in the loop.
4. Confirm the fix conceptually, not just empirically — if you're not sure why swapping the keyword fixed it, you'll hit the same shape of bug again the next time it shows up somewhere let isn't the obvious first move (a closure inside a function, for example, not just a loop).

Two mistakes worth knowing about ahead of time

Assuming it's a setTimeout or async timing problem. This bug shows up identically with any deferred callback — event listeners, promises, array method callbacks assigned to run later — not just setTimeout. If you find yourself trying to "fix" it by reordering code or adding delays, that's a sign you're debugging the wrong layer. The loop already finished; nothing about timing changes what value is left behind.

Reaching for the old IIFE trick out of habit, without knowing why let alone is now enough. Before let existed, the standard fix was wrapping the loop body in an immediately-invoked function expression to force a new scope by hand. That still works, but it's solving a problem let already solves natively — if you're writing new code in 2026 and still reaching for an IIFE here, it's worth understanding that let's per-iteration binding was specifically designed to make that pattern unnecessary.

A debugging habit that works

Whenever a loop-plus-callback combination prints the same value repeatedly, don't start by investigating the callback's logic — check the loop variable's declaration first. var shared across every iteration versus let scoped fresh to each one explains this entire category of bug, and recognizing that signature immediately turns a confusing multi-minute debugging session into a one-word fix.

If you'd like more posts like this sent straight to your inbox, subscribe to the newsletter.

Prefer to dig in yourself? The JavaScript Essentials repo on GitHub has more free examples and exercises.

Autocomplete was working an hour ago. Now you type a method name and nothing shows up — no suggestions, no parameter hints, no little popup confirming you spelled it right. Nothing crashed. No error appeared. VS Code just quietly stopped helping.

The usual response is to reinstall the language extension, or VS Code itself, and hope. That fixes it by accident sometimes, which is exactly what makes it a bad habit — it works often enough to seem right, so the actual cause never gets identified, and the same thing happens again next week.

What's actually happening

IntelliSense (VS Code's name for autocomplete, parameter hints, and inline suggestions together) isn't a single feature — it's the output of a language server running in the background, analyzing your code. When it goes quiet, there are exactly three places that chain can break:

1. The language extension isn't installed or is disabled. No extension, no language server, no IntelliSense for that file type — full stop.
2. VS Code is pointed at the wrong interpreter or runtime. For Python, Node, and similar languages, the language server needs to know which environment you're actually working in. Point it at the wrong one (or none), and it can't analyze anything correctly.
3. The language server itself has stalled, usually after a large refactor, a dependency change, or the project just being open a long time. The extension is fine, the interpreter is fine, the background process just needs a restart.

Reinstalling only ever addresses cause 1. If your real problem is 2 or 3, reinstalling changes nothing — which is why it "randomly" doesn't work half the time people try it.

The fix, step by step

1. Check the Extensions view for the language you're working in. Missing or disabled — that's cause 1, solved by installing or re-enabling it.
2. Check the Status Bar for the interpreter or runtime VS Code is currently using. If it's wrong, or blank, open the Command Palette (Ctrl+Shift+P / Cmd+Shift+P) and run:

   Python: Select Interpreter
   

   (or the equivalent for your language) and point it at the right one.
3. Restart the language server before assuming anything is actually broken:

   Developer: Reload Window
   

   This alone resolves a surprising share of "IntelliSense stopped working" reports — it's a stalled background process, not a misconfiguration.

Two mistakes worth knowing about ahead of time

Blaming VS Code for what's actually a project problem. A large, uninitialized project — missing dependencies, no virtual environment set up — can leave the language server with nothing to analyze. It's not a VS Code bug at that point; it's the language server correctly reporting that it can't see what it needs to see. If reloading the window doesn't help, check whether the project itself is fully set up before troubleshooting the editor further.

Not realizing Go to Definition and Rename Symbol break for the same reason. Both features rely on the exact same language server IntelliSense uses. If autocomplete is silent, don't troubleshoot those separately — fixing the language server fixes all three at once, and troubleshooting them as unrelated problems just means solving the same root cause three times.

A debugging habit that works

When IntelliSense goes quiet, resist the pull toward the drastic fix first. Check the Extensions view, check the Status Bar for the active interpreter, then reload the window — in that order, before anything more invasive. All three take under a minute combined, and between them they cover the actual three causes instead of gambling on a reinstall that only fixes one of them.

If you'd like more posts like this sent straight to your inbox, subscribe to the newsletter.

Prefer to dig in yourself? The VS Code Essentials repo on GitHub has more free examples and exercises.

You install something, open a fresh terminal, type the command, and get bash: python3: command not found — or on Windows, 'python3' is not recognized as an internal or external command. The installer said it finished successfully. You can probably even find the program in your applications folder. And yet the terminal insists it doesn't exist.

The instinct at this point is usually to reinstall, or install a second copy from somewhere else, hoping one of them "takes." That almost never fixes it, because reinstalling doesn't address what's actually wrong.

What the error is actually telling you

When you type a command, the shell doesn't scan your whole computer looking for it. It checks a specific, ordered list of directories — stored in an environment variable called PATH — and stops at the first match it finds. command not found doesn't mean the program doesn't exist anywhere on your machine. It means none of the directories in that list happen to contain it.

That distinction matters, because it splits into three genuinely different problems:

1. A typo. gerp isn't a command; grep is. This is the most common cause by a wide margin, and the easiest to rule out first.
2. It isn't installed at all. The program genuinely doesn't exist on this machine yet.
3. It's installed, but not somewhere the shell is looking. This is the one that catches people off guard — the software is sitting on disk, correctly installed, just outside every directory PATH currently checks.

Reinstalling only ever fixes cause 2. If your actual problem is 1 or 3, a second install just gives you a second copy of a program that was never the issue.

The fix, step by step

1. Check for a typo first. Read the command back character by character. It sounds too simple to be worth a step, but it resolves this error more often than everything else combined.
2. Confirm whether it's installed at all, independent of whether the shell can currently find it:

   which python3
   

   If which prints a path, it's installed and the shell can find it — so the error was probably a typo or a stale terminal (see below). If which prints nothing, move to step 3.
3. Check what the shell is actually searching:

   echo $PATH
   

   This prints the exact list of directories, in the exact order they're checked. If the folder containing your program isn't in that list, you've found the real cause — not a broken install, just an incomplete search path.
4. If it needs to be added, add it — and make the change permanent by putting it in your shell's startup file (~/.bashrc, ~/.zshrc, or equivalent), not just typing it into the current session, or it'll be gone the next time you open a terminal.

Two mistakes worth knowing about ahead of time

Editing your startup file and expecting it to take effect immediately. A change to ~/.bashrc only applies to new terminal sessions. The terminal you already have open won't see it until you either close and reopen it, or explicitly reload the file:

source ~/.bashrc

This is one of the most common "I fixed it and it's still broken" moments in terminal use — the fix worked, the current session just hasn't picked it up yet.

Assuming "not found" and "not installed" are the same thing. They frequently aren't. Running which <command> before doing anything else tells you immediately which situation you're actually in, so you're not troubleshooting a PATH problem as if it were a missing install, or reinstalling software that was never the problem.

A debugging habit that works

Before changing anything, ask which of the three causes you're actually looking at: typo, not installed, or not on PATH. which <command> answers that in one line — present it's a PATH problem, absent it's genuinely missing (or the name really is wrong). Fixing the right one of those three takes seconds. Guessing between them, and reinstalling on a hunch, is how a two-minute problem turns into a twenty-minute one.

If you'd like more posts like this sent straight to your inbox, subscribe to the newsletter.

Prefer to dig in yourself? The Command Line Essentials repo on GitHub has more free examples and exercises.

You write a query to find every customer with no phone number on file. WHERE phone = NULL looks obviously correct — and it returns zero rows, even though you can see NULL sitting right there in the column. Nothing crashes. No error. The query just quietly lies to you about what's in the table.

This isn't SQL being broken. It's SQL being consistent about something most languages don't force you to think about: NULL doesn't mean "nothing," it means "unknown." And you can't compare something to unknown with = and expect a real answer.

What's actually happening

Take this table:

-- customers
| id | name        | phone      |
|----|-------------|------------|
| 1  | Jordan Lee  | 555-0142   |
| 2  | Sam Rivera  | NULL       |
| 3  | Alex Chen   | 555-0198   |

SELECT name FROM customers WHERE phone = NULL;
-- returns 0 rows

SQL doesn't evaluate conditions as just true or false — it has a third result: unknown. phone = NULL asks "does this unknown value equal this other unknown value?" There's no way to answer that, so SQL returns UNKNOWN for every single row, including Sam Rivera's. And WHERE only keeps rows where the condition is TRUE. UNKNOWN doesn't qualify, so the row gets filtered out — the exact same as if it had evaluated to FALSE.

This is true even for the row that "should" match. NULL = NULL isn't TRUE — it's also UNKNOWN. NULL never equals anything, not even another NULL. That's the whole rule, and it applies uniformly, which is why = can't be patched into working here — it's not almost right, it's answering a different question than the one you're asking.

The fix, step by step

1. Recognize the symptom: a query that runs cleanly but returns fewer rows than it should — especially zero rows when you can see matching data — with a NULL column somewhere in the WHERE clause.
2. Swap = for IS NULL (or != for IS NOT NULL). These are dedicated operators built specifically to test for absence, not comparison operators being asked to do something they can't.
3. Rewrite the query: WHERE phone IS NULL instead of WHERE phone = NULL.
4. Check compound conditions too. WHERE phone = NULL OR phone = '' has the same bug hiding in it — the OR doesn't rescue the broken half.
5. Confirm with a plain SELECT * on the table first, so you know what you're actually expecting to match before trusting the filtered result.

Two mistakes worth knowing about ahead of time

Assuming != is the correct opposite. WHERE phone != NULL doesn't return "everyone with a phone number" — it returns nothing, for the identical reason: != is still a comparison, and comparing anything to NULL is still UNKNOWN, still filtered out. If you want "has a value," the operator is IS NOT NULL, not !=.

Trusting COUNT(*) to tell you the same thing as COUNT(column). COUNT(*) counts rows. COUNT(phone) counts only the rows where phone isn't NULL — the two numbers can legitimately be different, and the gap between them is often the fastest way to notice you have more missing data than you thought, before it silently breaks a filter somewhere else.

A debugging habit that works

When a query returns fewer rows than expected, don't start by rewriting the logic — start by running SELECT * FROM table with no WHERE clause at all, and look for NULL in any column your filter touches. If it's there, the fix is almost always mechanical: swap the comparison operator for IS NULL or IS NOT NULL and rerun.

The habit worth keeping past this one query: before writing = NULL anywhere, ask whether the column can be NULL in the first place. If a column is genuinely required to always have a value, enforce that with a NOT NULL constraint at the schema level — the same instinct as tracing an undefined back to its source in JavaScript or a None back to a missing return in Python. Missing data is either expected and worth handling deliberately, or it's a sign something upstream should never have let the row in empty to begin with.

If you'd like more posts like this sent straight to your inbox, subscribe to the newsletter.

Prefer to dig in yourself? The SQL Essentials repo on GitHub has more free examples and exercises.

As featured in PyCoder's Weekly, Issue #751.

Your script crashes, and near the bottom of the traceback sits AttributeError: 'NoneType' object has no attribute 'name'. It reads like Python is being deliberately unhelpful — but it's actually telling you something precise. You just tried to use a variable that turned out to be None, and it's telling you exactly which one and where.

The error isn't saying your program is fundamentally broken. It's saying: at this exact line, you reached for an attribute on a value that was None instead of the object you expected. That's a narrow claim, and once you know how to read it, tracking down why it was None is usually mechanical.

What the error is actually telling you

Take this code:

class User:
    def __init__(self, id, name):
        self.id = id
        self.name = name

def find_user(users, user_id):
    for u in users:
        if u.id == user_id:
            return u
    return None

user = find_user(users, target_id)
print(user.name)
# AttributeError: 'NoneType' object has no attribute 'name'

Read the message in two parts. 'NoneType' object has no attribute 'name' tells you the object you called .name on wasn't a User — it was None. has no attribute 'name' tells you which access failed. Put together: whatever user was pointing to when you hit that line wasn't what you expected — it was nothing at all.

The message never claims .name is the problem. .name is just where the crash became visible. The real question is one step earlier: why was user None? Here, find_user() falls through its loop without a match and explicitly returns None — so either target_id is wrong, or that user genuinely isn't in the list yet.

The fix, step by step

1. Read the attribute name in the error ('name' here) — that tells you which line and which access failed, nothing more.

2. Trace back to where the None value came from. Find the line that assigned, returned, or fetched it.

3. Ask why it's None there, specifically. The most common causes: a lookup function that found nothing and returned None, a dict.get() call that didn't find the key, or — easy to miss — a function with a code path that falls off the end without hitting a return at all. Python returns None implicitly in that case, silently.

4. Fix the actual cause, not just the crash site. If the value can legitimately be missing, check for None deliberately before using it. If it should never be missing, the bug is upstream — a typo in the lookup key, a branch that forgot to return, or a wrong assumption about what the data contains.

5. Confirm with print() and type() on the variable itself, right before the crashing line, before you change anything.

Two mistakes worth knowing about ahead of time

Reaching for getattr(user, "name", None) as a reflex instead of a decision. It's Python's version of the same instinct that reaches for ?. in JavaScript — it makes the crash go away without answering why user was None in the first place. Sometimes that's correct, because the data really is optional. Other times it quietly papers over a real bug, and the missing value just surfaces somewhere else later, harder to trace.

Assuming the crash line is where the bug lives. user was already None before print(user.name) ever ran — the crash just shows up wherever the property access happens, not wherever the value went wrong. A version of this that catches people off guard: a function with an early if branch that returns a value, and a later path that falls off the end with no return at all. That path doesn't error where the bug is — it errors wherever the caller next tries to use the result.

A debugging habit that works

Before changing anything, print() the variable itself, one line above the crash — not the attribute, the whole object — and check its type(). If it's None, walk backward: where was it supposed to be set, and does every path through that function actually return something? A missing return on one branch is the single most common real-world cause behind this exact error, and it's invisible until you go looking for it, because Python never complains at the point you forgot to write it.

Once you know why it's None, the fix is one of two things: guard for it on purpose, with a clear fallback or an explicit "not found" path, or fix the function that's silently swallowing a code path it should have returned from. Both are valid — just make sure you know which one you're doing before you reach for getattr() and move on.

If you'd like more posts like this sent straight to your inbox, subscribe to the newsletter.

Prefer to dig in yourself? The Python Essentials repo on GitHub has more free examples and exercises.

The error isn't saying your program is broken. It's saying: at this exact line, you tried to read a property off a value that turned out to be undefined. That's a narrow, specific claim — and once you know how to read it, the fix is usually mechanical.

What the error is actually telling you

Take this code:

const user = users.find(u => u.id === targetId);
console.log(user.name);
// TypeError: Cannot read properties of undefined (reading 'name')

Read the message right to left. (reading 'name') tells you which property access failed — .name. Cannot read properties of undefined tells you what it was trying to read .name off of — something that was undefined. Put together: whatever sits to the left of .name in your code — here, user — wasn't what you expected it to be.

The message never claims .name itself is the problem. .name is just where the crash became visible. The real question is always one step earlier: why was user undefined in the first place? In this example, .find() returns undefined when nothing matches — so either targetId is wrong, or the user genuinely isn't in the list yet.

The fix, step by step

1. Read the property name in the error ('name' in this case) — that tells you which line and which access failed, nothing more.

2. Trace back to where the undefined value came from. Find the line that assigned, returned, or fetched it.

3. Ask why it's undefined there, specifically. Common causes: an array method (.find, .pop, array indexing) that found nothing, a destructured key that doesn't match the actual object shape, or code that runs before an async fetch has resolved.

4. Fix the actual cause, not just the crash site. If the value can legitimately be missing sometimes, guard for it deliberately. If it should never be missing, the bug is upstream — a typo, a wrong assumption about timing, or a mismatched API response shape.

5. Confirm with a console.log right before the crashing line before you touch anything — print the variable itself, not just the property, so you can see exactly what you're working with.

Two mistakes worth knowing about ahead of time

Reaching for ?. as a reflex instead of a decision. Optional chaining (user?.name) makes the error go away, but it doesn't answer why user was undefined. Sometimes that's the right call — the data is genuinely optional. Other times it quietly hides a real bug, the same way a bare except: in Python swallows errors you actually needed to see. Use ?. when missing data is expected and handled; don't use it just to make red text disappear.

Assuming the crash line is where the bug lives. The value was usually already wrong several lines — or several files — earlier. A common version of this: reading props.data.items before an API call has actually resolved, because the component rendered on the very first pass with no data yet. The crash shows up wherever the property access happens, not wherever the value went wrong.

A debugging habit that works

Before changing anything, console.log() the variable itself, one line above the crash — not the property, the whole thing. If it's undefined, walk backward: where was it supposed to be set, and did that code actually run before this line did? Async timing is the single most common root cause behind this error in real apps — check whether you're reading data before a fetch, await, or state update has actually completed.

Once you know why it's undefined, the fix is usually one of two things: guard for it on purpose with ?. and a sensible fallback (user?.name ?? "Unknown"), or fix whatever upstream logic is producing an empty value when it shouldn't be. Both are valid — just make sure you know which one you're doing, rather than reaching for ?. and moving on before you find out.

This post is adapted from the JavaScript Essentials Companion Guide — a practical, no-fluff guide to JavaScript for developers who want to understand it, not just copy it.

A traceback isn't Python telling you that you've broken something beyond repair. It's Python telling you exactly where execution stopped and why, in more detail than almost any other language bothers to give you. The trick is reading it in the right order.

Read it bottom to top

Take this traceback:

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

Start at the last line — that's the actual error: ZeroDivisionError: division by zero. That alone tells you what kind of problem you're dealing with.

The line right above it shows exactly where inside the code that error was raised — here, the return a / b line inside divide().

Working further upward traces the chain of calls that got you there, oldest call at the top. For a short traceback like this one, you don't need much more than the bottom two lines: the exception type and message, and the exact line that raised it. Everything above that is just context for how execution arrived there — useful when the bug isn't obvious, skippable when it is.

The most common way people make it worse

There's a real temptation, especially under a deadline, to wrap the crashing line in a bare except: and move on:

try:
    risky_operation()
except:               # catches everything, including real bugs
    pass

Don't. A bare except catches everything — typos, keyboard interrupts, bugs you don't know exist yet — and silently hides all of them. Catch the specific exception you're actually expecting instead:

try:
    risky_operation()
except ValueError:
    handle_bad_input()

Now anything you didn't anticipate still surfaces as a real, readable traceback instead of vanishing.

Two mistakes worth knowing about ahead of time

Assuming the error is where the traceback "feels" like it should be. Often the actual bug happened several lines earlier — a variable got set incorrectly, and the crash is just where that bad value finally caused a visible problem. The traceback tells you where things stopped, not necessarily where they went wrong.

Fixing the symptom instead of the cause. Wrapping a crashing line in try/except and moving on makes the error message go away, but the bad state that caused it is usually still there — it just surfaces somewhere else, later, and harder to trace back.

A debugging habit that actually works

Read the full error message and the exact line it points to before changing anything. Reproduce the bug with the smallest input that still triggers it. Add a print() — or drop a breakpoint() right before things go wrong — and check your assumptions about a variable's type and value directly with type(x) and print(x) rather than guessing. Change one thing at a time; resist fixing five suspected causes simultaneously, because when it works you won't know which one mattered.

And when you're genuinely stuck: explain the problem out loud, line by line, as if to someone else. Naming your assumptions explicitly is often enough to spot the one that's wrong.

This post is adapted from the Python Essentials Companion Guide — a practical, no-fluff guide to Python for developers who want to understand it, not just copy it.

A merge conflict means two branches changed the same part of a file, and Git isn't willing to guess which version you want. That's it. It's not a sign you did something wrong; it's Git asking a question only a human can answer.

What a conflict actually looks like

Open the flagged file and you'll see something like this dropped right into your code:

<<<<<<< HEAD
const timeout = 3000;
=======
const timeout = 5000;
>>>>>>> feature/update-timeout

Three markers, three jobs:

• <<<<<<< HEAD marks the start of your current branch's version.

• ======= is the dividing line between the two.

• >>>>>>> feature/update-timeout marks the end of the incoming branch's version.

Everything between the first two markers is what you have. Everything between the second two is what's coming in. Your job is to replace the whole block — markers included — with whatever the correct final code should be.

The fix, step by step

1. Run git status to see which files are conflicted. Work through them one at a time, not all at once.

2. Open the file and read both versions carefully before touching anything.

3. Decide the correct outcome. You've got three options: keep yours, keep theirs, or combine both into something new that reflects what actually needs to happen.

4. Delete the conflict markers entirely. The file should read exactly as it should in production — no <<<<<<<, no =======, no >>>>>>> left behind anywhere.

5. Stage it: git add filename.ext

6. Finish the merge: git commit -m "Resolve merge conflict in filename.ext"

That's the whole mechanical process. The part that actually takes judgment is step 3.

The two rules that matter most

Never guess. If you're not sure which version is correct, a two-minute conversation with whoever wrote the other change is faster — and safer — than assuming and shipping the wrong one.

Never default to keeping your own version. It's tempting when you're in a hurry, but the incoming change might contain real work you'd be silently throwing away. Read both sides before you decide.

And always test after resolving — confirm the code still builds and runs correctly before you commit. A conflict resolved incorrectly is often worse than one left open, because a bad resolution can quietly discard someone's work or introduce a bug nobody notices until much later.

The best conflict is the one you never have

A few habits go a long way: pull from main frequently while you're on a feature branch, keep branches short-lived, and say something when you know you're working in the same area of code as a teammate. git pull origin main run regularly keeps your branch close enough to main that conflicts, when they do happen, stay small.

If a conflict lands in code you didn't write and don't fully understand, that's the moment to stop and ask, not guess. There's no shame in "I've got a conflict in code I'm not familiar with — can you help me sort it out?" It's a two-minute question that saves everyone a much worse afternoon.

This post is adapted from the Git & GitHub Companion Guide — a practical, no-fluff guide to Git for developers who want to understand it, not just survive it.