Both move data over IP, but they make opposite trade-offs. Pick based on whether you’d rather lose a packet or wait for it.

TCP — reliable & ordered

Connection-based: a handshake (SYN, SYN-ACK, ACK) sets things up first. Guarantees delivery and order; lost packets are retransmitted. Flow & congestion control built in. Cost: more overhead and latency. Used by HTTP, SSH, SMTP, database connections.

UDP — fast & fire-and-forget

Connectionless: just send datagrams, no handshake. No retransmission, no ordering, no congestion control. Tiny header, minimal latency. Used by DNS, video/voice calls, gaming, QUIC/HTTP3.

TCP:  A --SYN-->  B
      A <-SYN/ACK- B   (then ordered, acked data)
      A --ACK-->  B

UDP:  A --datagram--> B   (no reply expected)

A quick way to see TCP setup in action:

curl -v https://example.com   # watch "Connected to" before any data

TL;DR: TCP trades speed for reliability; UDP trades reliability for speed.

Next time you design an API or stream, ask: can I tolerate a dropped packet?

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

Vue’s data flow is one-way: parents pass props down, children send emits up. Props are read-only inside the child.

Defining props

Use defineProps — no import needed in <script setup>.

<script setup>
const props = defineProps({
  title: { type: String, required: true },
  count: { type: Number, default: 0 }
})
</script>

<template>
  <h2>{{ props.title }} ({{ count }})</h2>
</template>

Emitting events

Declare events with defineEmits, then call the emitter. The parent listens with @event.

<script setup>
const emit = defineEmits(['increment'])

function add() {
  emit('increment', 1) // send a payload up
}
</script>

<template>
  <button @click="add">+</button>
</template>

The parent wires it together:

<Counter :title="'Score'" @increment="score += $event" />

Why one-way?

Never mutate a prop directly. If a child needs to change a value, it emits an event and lets the parent own the update. This keeps state predictable and easy to trace.

TL;DR: Props flow data down (read-only); emits send events up so the parent can update state.

Build a tiny counter component and pass its value entirely through props and emits — no shared state needed!

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

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.