A hash map (dict, hash table) stores key-value pairs and finds any key in roughly O(1) time. The trick is turning the key into an array index.

The core idea

1. A hash function converts your key into a number.
2. That number maps to a bucket (an index in an internal array).
3. The value gets stored in that bucket — so lookup goes straight there.

def bucket_index(key, size):
    return hash(key) % size   # turn key into an array index

# Conceptually:
buckets = [[] for _ in range(8)]
def put(key, value):
    buckets[bucket_index(key, 8)].append((key, value))

Collisions

Two keys can land in the same bucket. Maps handle this by chaining (storing a small list per bucket) or open addressing (probing for the next free slot). With a good hash function, collisions stay rare and lookups stay fast.

When it slows down

If too many keys crowd into too few buckets, lookups degrade toward O(n). Real implementations resize (rehash into a bigger array) once they get too full, keeping operations near constant time on average.

TL;DR: A hash map turns keys into array indices via a hash function, giving average O(1) lookup — collisions and resizing are the details that keep it honest.

Reach for a dict whenever you find yourself scanning a list to find one item.

How Hash Maps Work 🗺️ was originally published in The 60-Second Programmer on Medium, where people are continuing the conversation by highlighting and responding to this story.

A union (|) says a value is one of several types. A literal type narrows it to one exact value. Together they're TypeScript's superpower.

Literal types

Instead of string, accept only specific strings:

type Direction = "up" | "down" | "left" | "right";

function move(d: Direction) { /* ... */ }

move("up");   // ok
move("north"); // error: not a Direction

Narrowing

TypeScript narrows the type as you check it:

type Status = "loading" | "success" | "error";

function render(s: Status) {
  if (s === "error") {
    // s is "error" here
    return "Something broke";
  }
  return s; // s is "loading" | "success"
}

Combine with switch for exhaustive handling — every case covered, compiler-verified.

TL;DR: Unions + literals replace loose string/number with a precise set of allowed values.

Swap a stringly-typed parameter for a literal union and watch the bugs vanish.

Union & Literal Types 🔀 was originally published in The 60-Second Programmer on Medium, where people are continuing the conversation by highlighting and responding to this story.

Want to run something concurrently in Go? Put go in front of it. Done.

What is a goroutine?

A goroutine is a lightweight thread managed by the Go runtime. They start with a tiny stack (a few KB) and grow as needed, so you can spawn thousands without breaking a sweat. The scheduler multiplexes them onto OS threads for you.

Starting one

package main

import (
	"fmt"
	"sync"
)

func main() {
	var wg sync.WaitGroup
	for i := 0; i

Watch out

main returning kills every goroutine, so coordinate with sync.WaitGroup or a channel. Goroutines run independently. Use channels or mutexes to share data safely. Capture loop variables explicitly (pass i as an argument) unless you're on Go 1.22+.

TL;DR: go f() launches concurrent work; use WaitGroup or channels to wait for it.

Try spawning 1,000 goroutines and watch how fast they finish. 🐹

Goroutines Explained 🚀 was originally published in The 60-Second Programmer on Medium, where people are continuing the conversation by highlighting and responding to this story.

An LLM (Large Language Model) is a neural network trained on huge amounts of text to predict the next token. That’s it. Everything else — answering questions, writing code, summarizing — emerges from doing that one thing extremely well.

How it works

Your text is split into tokens (roughly word-fragments). The model assigns a probability to every possible next token, picks one, appends it, and repeats. A paragraph is just the model running that prediction step hundreds of times.

"The capital of France is" → [Paris: 0.92] [Lyon: 0.01] ... → "Paris"

What it is NOT

Not a database — it doesn’t “look up” facts; it predicts plausible text, so it can be wrong (a “hallucination”). Not deterministic by default — sampling makes outputs vary between runs. Not stateful — each request is independent. You resend the full conversation every time.

Calling one

import anthropic

client = anthropic.Anthropic()
resp = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Explain an LLM in one sentence."}],
)
print(resp.content[0].text)

TL;DR: An LLM is a next-token predictor trained at scale — powerful, but it generates plausible text, not verified truth.

Try one against a real prompt before you trust it for anything that matters. →

LLMs Explained 🧠 was originally published in The 60-Second Programmer on Medium, where people are continuing the conversation by highlighting and responding to this story.

Both are relative font-size units, but they measure against different things — and that difference matters.

em → relative to the parent

1em equals the parent element's font size. So em values compound as you nest.

.parent { font-size: 20px; }
.child  { font-size: 1.5em; } /* 30px */
.grandchild { font-size: 1.5em; } /* 45px — compounds! */

That cascading can surprise you when components nest deeply.

rem → relative to the root

1rem always equals the root (<html>) font size, no matter how deep you are. No compounding.

html { font-size: 16px; }
.title { font-size: 2rem;  } /* always 32px */
.body  { font-size: 1rem;  } /* always 16px */

When to use which

rem for font sizes and most layout — predictable and accessibility-friendly (it respects the user's browser font setting). em for spacing that should scale with its own text, like button padding:

.btn {
  font-size: 1.25rem;
  padding: 0.5em 1em; /* scales with the button's text */
}

TL;DR: Use rem for consistent, accessible sizing; reach for em when you want a value to scale with its local font size.

Set padding in em on a button, then bump its font-size — the padding scales right along with it.

em vs rem Explained 📏 was originally published in The 60-Second Programmer on Medium, where people are continuing the conversation by highlighting and responding to this story.

NULL means “unknown,” not zero or empty string. Treat it like a value and your filters quietly drop rows.

NULL breaks equality

Comparisons with NULL return unknown, never true:

-- These NEVER match, even when the column is NULL:
WHERE status = NULL      -- wrong
WHERE status != 'active' -- silently skips NULL rows!

-- Use IS NULL / IS NOT NULL instead:
WHERE status IS NULL
WHERE status IS NOT NULL;

Because status != 'active' is unknown for NULL rows, they get excluded. Add OR status IS NULL if you want them.

COALESCE picks the first non-NULL

Supply a fallback so NULLs don’t poison your output or math:

SELECT
  name,
  COALESCE(nickname, name)        AS display_name,
  COALESCE(discount, 0) * price   AS amount_off
FROM users;

COALESCE(discount, 0) turns a NULL discount into 0, so the multiplication stays a number instead of becoming NULL.

Gotchas

NULL + 5 is NULL. Any arithmetic with NULL is NULL. COUNT(col) skips NULLs; COUNT(*) counts every row. NULL = NULL is unknown. Use IS NOT DISTINCT FROM to treat two NULLs as equal.

TL;DR: Use IS NULL / IS NOT NULL to test for NULL, and COALESCE to supply a default.

👉 Scan your WHERE clauses for != — they’re probably hiding NULL rows.

Handling NULL in SQL 🕳️ was originally published in The 60-Second Programmer on Medium, where people are continuing the conversation by highlighting and responding to this story.

They sound similar but solve opposite problems. Encryption is reversible. Hashing is not. That one difference decides which to use.

Encryption — two-way

Encryption scrambles data with a key so it can be decrypted back with that key. Use it when you genuinely need the original value later: credit card numbers, private messages, data at rest.

Hashing — one-way

A hash turns input into a fixed-length fingerprint that can’t be reversed back to the original. Same input always gives the same hash. Use it to verify a value without storing the value itself.

Why passwords get hashed

You never need to know a user’s actual password — only whether the one they typed matches. So you store a hash. If your database leaks, attackers get fingerprints, not passwords.

Use a slow, salted password hash like bcrypt or argon2 (not fast hashes like MD5 or SHA-256). The salt makes every hash unique, and the slowness makes brute-forcing impractical.

import bcrypt

# On signup — store this hash, never the password
hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt())

# On login — compare, don't decrypt
ok = bcrypt.checkpw(attempt.encode(), hashed)

bcrypt builds the salt in and verifies by re-hashing the attempt — there's no "decrypt" step, by design.

TL;DR: Encrypt data you need to read back. Hash data you only need to verify — and hash passwords with bcrypt or argon2.

Open your auth code: if a password is encrypted (or worse, plaintext), switch it to a salted bcrypt/argon2 hash.

Hashing vs Encryption 🔐 was originally published in The 60-Second Programmer on Medium, where people are continuing the conversation by highlighting and responding to this story.

Both hold data a component renders. The difference is who controls it.

Props: passed in, read-only

A parent passes props down. The child reads them but never reassigns them.

function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
}

<Greeting name="Ada" />;

State: owned, changeable

State lives inside a component and changes over time via its setter.

function Toggle() {
  const [on, setOn] = useState(false);
  return <button onClick={() => setOn((o) => !o)}>{on ? "ON" : "OFF"}</button>;
}

The mental model

Props flow down from parent to child. Immutable to the receiver.
State is local and mutable through its setter.
Need to share state? Lift it to the closest common parent and pass it down as props.

TL;DR: Props come from above and are read-only; state is owned locally and changes over time.

Look at a component you wrote — is that data really state, or could it just be a prop? 🤔

Props vs State ⚛️ was originally published in The 60-Second Programmer on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dicts do far more than d[key]. Here are four habits that remove boilerplate.

1. .get() — no more KeyError

user = {"name": "Ada"}
user.get("age")          # None (no crash)
user.get("age", 0)       # 0 (default)

2. .setdefault() — read-or-initialize

Great for grouping into lists:

groups = {}
for word in ["apple", "ant", "bee"]:
    groups.setdefault(word[0], []).append(word)
# {"a": ["apple", "ant"], "b": ["bee"]}

3. Dict comprehensions

squares = {n: n * n for n in range(4)}
# {0: 0, 1: 1, 2: 4, 3: 9}

4. Merge with | (Python 3.9+)

defaults = {"color": "red", "size": "M"}
custom = {"size": "L"}
merged = defaults | custom
# {"color": "red", "size": "L"}  -> right side wins

TL;DR: get avoids KeyErrors, setdefault initializes-and-appends, comprehensions build dicts inline, and | merges them.

Follow for more 60-second Python breakdowns. 🐍

Dictionary Tricks Explained 🗙️ was originally published in The 60-Second Programmer on Medium, where people are continuing the conversation by highlighting and responding to this story.

null is a silent landmine. Optional<T> turns "this might be missing" into part of your method's signature, so callers can't ignore it.

Why it matters

The return type screams “could be empty.”
No more reflexive if (x != null) everywhere.
Chain transformations without NPEs.

The idioms that matter

Optional.of(x) for non-null, Optional.ofNullable(x) when it might be null.
Use map/filter to transform, orElse/orElseThrow to exit.
Never call .get() blindly — that just trades NPE for NoSuchElementException.

public Optional<User> findByEmail(String email) {
    return repository.lookup(email); // returns Optional<User>
}

String name = findByEmail("a@b.com")
        .map(User::getName)
        .filter(n -> !n.isBlank())
        .orElse("Anonymous");

User user = findByEmail("a@b.com")
        .orElseThrow(() -> new UserNotFoundException(email));

One rule: use Optional for return types, not for fields or method parameters.

TL;DR: Return Optional<T> instead of null so absence is impossible to overlook.

Got a method that returns null today? Refactor it to Optional and watch the null-checks disappear.

Optional: Stop Returning Null ☔ was originally published in The 60-Second Programmer on Medium, where people are continuing the conversation by highlighting and responding to this story.