Run npm install on a project, then pnpm install against the same package.json, and you get two different node_modules trees and two different lockfiles. Add a teammate who reaches for Yarn and the repo can end up with three lockfiles in its history, each describing a slightly different dependency tree. All three tools read the same package.json and pull from the same npm registry. They disagree about what to put on disk. ...

Log a user out of a session-based app and the server forgets them on the next request. Log them out of a JWT-based app and, unless you built extra machinery for it, the token they’re holding stays valid until it expires. That difference is the real decision behind “JWT vs session”. The rest follows from it. What a session actually stores A session keeps the user’s state on the server and hands the browser only a lookup key. ...

Search for “puppy” in a system that only matches keywords and a document about “dog training” will not show up, even though anyone reading both would call them closely related. Keyword search compares strings. It has no idea that “puppy” and “dog” mean nearly the same thing. Embeddings fix that. They turn a piece of text into a list of numbers, a vector, placed so that text with similar meaning lands near other text with similar meaning, whatever words it happens to use. ...

Wrap a fetch() call in try/catch, hit an endpoint that answers with a 404, and the catch block never runs. The promise resolves. res.json() parses whatever body the server sent back, often an error payload like {"error": "user not found"}, and the rest of the function treats it as the record it asked for. No exception and no console warning. The bad data moves downstream until something else breaks on it. ...

A function that calls itself has a maximum depth, and it is smaller than most people expect: 1,000 calls in CPython by default, roughly 10,000-15,000 in Node and browser engines depending on how much each frame holds. Go past it and the program does not slow down gracefully. It crashes. Python raises RecursionError: maximum recursion depth exceeded; JavaScript raises RangeError: Maximum call stack size exceeded. Both errors have the same cause, and once you see it you will know when recursion is the right tool and when it is a liability. ...

You’re building a dashboard: a header, a sidebar, a main content area, a footer. You reach for Flexbox because that’s the layout tool you know, and twenty minutes later you’ve got three nested display: flex containers, a sidebar that won’t hold its width without a magic number, and a footer that floats halfway up the page when the content is short. None of that is a Flexbox bug. You’re using a one-dimensional tool on a two-dimensional problem. ...

Put go in front of a function call and it runs concurrently with the rest of your program, scheduled by the Go runtime instead of the OS. Starting one is the easy part. The hard part is getting two goroutines to hand off a result without stepping on each other’s state, and that’s the job channels do. What is a goroutine? A goroutine is a function running independently of the one that started it, managed by Go’s runtime rather than the operating system. An OS thread reserves a megabyte or more of stack and costs the kernel real time to schedule. A goroutine starts with a stack of about 2KB that grows as needed, and the runtime multiplexes many goroutines onto a handful of OS threads. Starting thousands of them is normal. ...

A class that saves a user to the database, sends them a welcome email, and formats a receipt is one change away from breaking two features it has nothing to do with. Touch the email template and you risk the database write. Touch the receipt layout and you risk the email. SOLID is five rules aimed at that kind of entanglement, each from a different angle, and they share one idea: a class should change for one reason, and the rest of the code should depend on what something promises to do rather than how it does it. ...

Two requests hit the same “withdraw $100” endpoint half a millisecond apart. The account has $150. Both requests read that balance, both see enough funds, both approve, both subtract $100. The account ends at -$50, and no branch in the code should have allowed it. That is a race condition: the output depends on which operation happens to finish first, and “first” was never something the code decided. What causes a race condition? You need two ingredients at once: shared mutable state, and more than one path of execution touching it without coordination. The paths can be threads, async tasks, processes, or two servers hitting the same database row. Take away either ingredient and the bug disappears. A single thread can’t race against itself, and immutable state can’t be corrupted by being read twice. ...

A search box that fires a network request on every keystroke sends five requests for “redis”, and four of them are stale before the response comes back. A scroll handler that recalculates layout runs hundreds of times a second and makes the page stutter. Same problem in both cases: the DOM event fires far more often than the handler needs to run. Debounce and throttle fix it in two different ways. ...