Software Development

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. ...

What a decorator actually does to your function You want to time every function that calls a slow external API. You can paste time.perf_counter() calls into each one, or write the measurement once and apply it everywhere. A decorator is the second option. It is a function that takes another function, wraps it in extra behavior, and returns the wrapped version under the original name. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 import time def timed(func): def wrapper(*args, **kwargs): start = time.perf_counter() result = func(*args, **kwargs) elapsed = time.perf_counter() - start print(f"{func.__name__} took {elapsed:.3f}s") return result return wrapper @timed def fetch_price(ticker): time.sleep(0.2) # stand-in for a network call return 142.50 fetch_price("AAPL") # fetch_price took 0.201s @timed above def fetch_price is shorthand for fetch_price = timed(fetch_price). Python calls timed once, right after fetch_price is defined, and rebinds the name fetch_price to whatever timed returns. That’s all the @ does. ...

Run 0.1 + 0.2 in a Python shell and it does not return 0.3. It returns 0.30000000000000004. Try it in JavaScript, Java, Go, C, or Rust and you get the same sixteen-digit tail. Every one of those languages is doing exactly what the hardware standard tells it to. A number that needs infinitely many binary digits is being squeezed into 64 bits, and something has to give. Why 0.1 can’t be stored exactly in binary Computers store floating-point numbers in base 2. In base 2, the fraction 1/10 is a repeating expansion, the same way 1/3 repeats forever in base 10 (0.3333...). Written out, 0.1 in binary starts: ...

A Python dictionary lookup takes about 100 nanoseconds whether the dict holds 1,000 keys or 1,000,000. A nested loop that checks a list for duplicates takes half a millisecond on 200 items and 136 milliseconds on 3,200. Sixteen times the input, nearly 280 times the wait. Same machine, same Python. Big O notation is the name for that difference. What Big O notation measures Big O describes how the running time (or memory use) of a piece of code grows as the input gets larger. It is not a stopwatch reading, and it does not care whether your laptop is fast or slow. It cares about the shape of the growth curve: when you double the input, does the time double, quadruple, or barely move? ...

Run git reset --hard on a commit your team already pulled and you’ve just made your history disagree with theirs. Run git revert on a typo you haven’t pushed and you’ve added a pointless commit to the log. Git has four undo commands, restore, reset, commit --amend and revert, and they are not interchangeable. Pick the wrong one and it either does nothing or does far more than you wanted. ...

Here is a class you cannot unit test without a live database and a working SMTP server: 1 2 3 4 5 6 7 8 9 10 11 public class OrderService { private readonly SqlOrderRepository _repository = new SqlOrderRepository("Server=prod-db;Database=Orders;..."); private readonly SmtpEmailSender _emailSender = new SmtpEmailSender("smtp.company.com"); public void PlaceOrder(Order order) { _repository.Save(order); _emailSender.Send(order.CustomerEmail, "Order confirmed"); } } OrderService builds its own SqlOrderRepository and SmtpEmailSender with new, connection string and all. Every test that touches PlaceOrder needs a real Orders database and a real mail server, or it fails before your assertion runs. The logic you want to test is two lines: save the order, send the confirmation. It’s welded to two concrete classes you can’t swap out. ...

A function can have 100% unit test coverage and the page that calls it can still return a 500 in production. That is not a contradiction. Unit tests, integration tests, and end-to-end tests check different things, and a suite that’s heavy on one and light on another has a specific, predictable hole in it. What unit, integration, and end-to-end tests each check Take a sign-up feature: a function validates the input, writes a row to a database, and sends a welcome email. Three tests can cover it, and each one answers a different question. ...

Run this in Node or a browser console: 1 2 3 4 console.log("1"); setTimeout(() => console.log("2"), 0); Promise.resolve().then(() => console.log("3")); console.log("4"); The output is 1 4 3 2. A setTimeout with a 0ms delay still runs after the promise callback, and both wait for every line of synchronous code below them. async/await is built on this ordering, not on something new. Most of the surprising behavior in async JavaScript comes from writing await as if it paused the whole program, when it only pauses the function it’s in. ...

Your frontend runs on http://localhost:5173, your API on http://localhost:4000, and the fetch call that worked fine in Postman fails in the browser with a wall of red text: Access to fetch at 'http://localhost:4000/api/users' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Your server may well have handled that request and returned a 200. The browser refused to hand the response to your JavaScript. ...