DEV Community: Mohamed Idris

"Concurrency" vs "Parallelism": One Cook Juggling vs Two Cooks Cooking

Mohamed Idris — Mon, 08 Jun 2026 09:30:00 +0000

Everyone uses these two words like they mean the same thing. They don't, and the
difference is actually kind of beautiful once it clicks. Let's make it click.

The idea in one line

Concurrency = dealing with many things at once by switching between them.
Parallelism = doing many things at once, truly at the same instant.

The metaphor: the kitchen

CONCURRENCY                         PARALLELISM
one cook, many dishes               two cooks, two dishes
stirs soup, then chops, then        each cooking at the same
back to the soup...                 real moment
= juggling, fast switching          = literally simultaneous

One cook can handle three dishes by switching: stir the soup, while it
simmers go chop veggies, pop back to the soup. They're never doing two things in
the same instant, but they keep all three moving. That's concurrency.

Two cooks each working a dish at the very same moment? That's
parallelism. Real simultaneous work, which needs more than one worker.

So: concurrency is about structure (juggling many tasks), parallelism is
about execution (more than one happening at the literal same time).

How it shows up in code

JavaScript is famous for being a single cook (one main thread) that is great
at concurrency. While it waits on a slow thing, it goes does other work.

// Concurrency: one thread, but it doesn't freeze while waiting
const [user, posts] = await Promise.all([
  fetch("/user"),    // start this...
  fetch("/posts"),   // ...and this, without waiting for the first to finish
])
// While the network is busy, the one thread is free to handle other stuff.

The single cook fired off both orders, then handled other things while waiting.
That's concurrency without parallelism: one worker, no freezing.

True parallelism needs more workers. In the browser that's Web Workers; on a
server it's multiple threads or processes running on multiple CPU cores at once.

CPU core 1:  [ resize image A ]      <- these two really run
CPU core 2:  [ resize image B ]         at the same instant = parallel

A real case

Waiting on slow stuff (network, disk, database)? You want concurrency. One worker stays busy instead of freezing. This is most web code.
Heavy number crunching (resize 1000 images, crunch big math)? You want parallelism, real extra workers on extra CPU cores.

A useful line: concurrency is great for waiting, parallelism is great for
working.

Gotchas juniors hit

1. Thinking async/await makes things parallel.
It doesn't. It makes them concurrent. One thread, not frozen while waiting. Real
parallel work needs more workers.

2. Awaiting things one by one when they could overlap.
Two await fetch() lines run one after the other. Promise.all lets them
overlap. Same single cook, but smarter juggling.

3. Assuming more workers always means faster.
Coordinating many cooks has its own cost (and shared data brings race
conditions). Sometimes one well-organized cook wins.

Recap

Concurrency = juggling many tasks by switching (one cook, no freezing).
Parallelism = truly doing many at once (multiple cooks, multiple cores).
JS is a single cook that's great at concurrency.
Concurrency shines for waiting; parallelism shines for heavy work.

Your turn

Look at code where you await two slow calls back to back. Could they overlap
with Promise.all? That tiny change is concurrency working for you. Then explain
"one cook juggling vs two cooks cooking" to a friend.

"Declarative" vs "Imperative": Ordering a Pizza vs Making It Yourself

Mohamed Idris — Sun, 07 Jun 2026 09:28:00 +0000

You want a pizza. You have two choices. Call the shop and say "one large
pepperoni, please." Or roll up your sleeves: make the dough, spread the sauce,
slice the pepperoni, set the oven, watch it bake.

Same pizza. Totally different style. That gap is the difference between
declarative and imperative code, two words you'll hear constantly.

The idea in one line

Imperative = you spell out how to do it, step by step. Declarative =
you say what you want, and let something else handle the how.

The metaphor: ordering vs cooking

IMPERATIVE (cook it yourself)        DECLARATIVE (order it)
1. make dough                        "one large pepperoni, please"
2. add sauce
3. add pepperoni                     ...the kitchen figures out the steps
4. bake 12 min

Neither is "better" in general. But declarative is shorter, easier to read, and
lets you skip details you don't care about.

How it looks in code

Say you want only the even numbers from a list.

// Imperative: you manage every step yourself
const evens = []
for (let i = 0; i < nums.length; i++) {   // set up a counter
  if (nums[i] % 2 === 0) {                 // check each one
    evens.push(nums[i])                    // collect the keepers
  }
}

// Declarative: say WHAT you want, skip the how
const evens = nums.filter(n => n % 2 === 0)  // "give me the even ones"

Both give the same evens. But the second one reads almost like English. You
don't see the counter, the index, or the pushing. You just declared the goal:
"keep the even ones."

A real case: HTML and React

HTML is declarative. You write <button>Buy</button> and say what you want on
the page. You never write the steps to draw pixels on the screen. The browser
does the how.

React works the same way. You describe what the UI should look like for a given
state, and React figures out the steps to make the screen match.

// Declarative: "when isLoading, show a spinner; otherwise show the list"
return isLoading ? <Spinner /> : <List items={items} />
// You never write "find the old spinner, remove it, insert the list..." React does that.

SQL is declarative too. SELECT name FROM users WHERE age > 18 says what rows
you want. The database decides how to find them fast.

Gotchas juniors hit

1. Thinking declarative is always better.
It's usually cleaner, but when you need fine control or top speed, imperative
steps can be the right tool. Use the one that fits.

2. Mixing the two in a confusing soup.
A .map() with a giant pile of imperative logic crammed inside often wants to be
split up or rethought. Keep each piece clear.

3. Forgetting that declarative still runs steps.
.filter() still loops under the hood. You just don't have to write or babysit
the loop. The how didn't vanish; someone else handles it.

Recap

Imperative = the recipe, every step (a for loop you manage).
Declarative = the order, just the goal (.filter(), HTML, SQL, React).
Declarative code is usually shorter and easier to read.
Pick the style that makes the goal clearest for the job.

Your turn

Find a for loop in your code that builds up a list. Can you rewrite it with
.map(), .filter(), or .reduce() so it says what you want instead of how?
Try it, then explain "ordering a pizza vs cooking it" to a friend.

"Pure Function" and "Side Effect": The Tidy Cook vs the Messy One

Mohamed Idris — Sat, 06 Jun 2026 09:28:00 +0000

Two cooks make you the same soup. Cook A uses only what's on the cutting board
and leaves the kitchen spotless. Cook B grabs random spices off the shelf, and on
the way out, somehow sets the curtains on fire.

Both made soup. But you trust Cook A way more. In code, Cook A writes pure
functions, and Cook B leaves side effects everywhere.

The idea in one line

A pure function only uses its inputs and only returns an output. A side
effect is anything it touches outside of that, like changing a global,
writing a file, or hitting the network.

The metaphor: the tidy cook

A pure function is the tidy cook:

Uses only the ingredients you hand it (its inputs).
Gives back only the dish (its return value).
Changes nothing else in the kitchen.

Hand it the same ingredients, get the same dish. Every time. (Yes, that means
pure functions are also deterministic.)

PURE                          IMPURE (has side effects)
in -> [ function ] -> out     in -> [ function ] -> out
nothing else moves                  ...and also: writes a file,
                                    changes a global, logs, fetches

How it looks in code

// Pure: depends only on input, returns only output, touches nothing else
function add(a, b) {
  return a + b
}

// Impure: reaches outside itself (a side effect)
let total = 0
function addToTotal(n) {
  total += n          // changes a global. now the outside world moved.
  console.log(total)  // also writes to the console. another side effect.
}

add is a dream to test: add(2, 3) is always 5. addToTotal is trickier,
because its result depends on what total was before, and it messes with the
world on its way out.

Wait, aren't side effects necessary?

Yes! A program with zero side effects does nothing useful. Saving data, showing a
page, calling an API: those are all side effects, and you need them.

The goal is not "no side effects." The goal is to keep them in their own
corner, so most of your code stays pure and easy to trust.

// Keep the thinking pure...
function nextCount(count) {
  return count + 1        // pure: easy to test
}

// ...and do the messy stuff at the edge
function handleClick() {
  setCount(nextCount(count))  // the side effect (updating the screen) lives here
}

A real case

This is why utility and helper functions are usually pure: format a price,
calculate a total, validate an email. They're easy to test because you just feed
inputs and check outputs. No database, no clock, no mocking circus.

The messy parts (saving to a database, sending an email) get pushed to the edges
where they're easy to spot.

Gotchas juniors hit

1. Calling logging or console.log "harmless."
It's still a side effect. Usually fine, but it means the function isn't pure.

2. Secretly mutating an input.
A function that does arr.push(x) to an array you passed in changed your data.
That's a side effect hiding in plain sight. Return a new value instead.

3. Thinking pure functions are useless because they "just return stuff."
That "just returning stuff" is exactly why they're easy to test, reuse, and
trust. That's the win.

Recap

Pure function = uses only its inputs, returns only an output, touches nothing else. The tidy cook.
Side effect = touching the outside world (globals, files, network, screen, even logs).
You need side effects, just keep them at the edges.
Pure code is easy to test and reuse. That's the whole point.

Your turn

Pick one function in your project. Ask: does it touch anything besides its inputs
and return value? If yes, can you pull that messy part out and leave a clean,
pure core? Try it, then explain "the tidy cook vs the messy cook" to a friend.

"Mutable" vs "Immutable": Can You Change It After You Make It?

Mohamed Idris — Fri, 05 Jun 2026 09:27:00 +0000

You copy an array to be "safe," tweak the copy, and somehow the original
changes too. You stare at the screen. You didn't touch the original. Did the
computer just lie to you?

Welcome to the world of mutable and immutable. Two words that explain a
ton of "wait, why did that change?" bugs.

The idea in one line

Mutable means "can be changed after it's made." Immutable means "locked
forever once it's made."

The metaphor: a whiteboard vs a printed photo

WHITEBOARD (mutable)            PRINTED PHOTO (immutable)
wipe it, rewrite it             can't edit it
same board, new content         want a change? print a NEW photo

A whiteboard is mutable. You change what's on it, but it's still the same
board. A printed photo is immutable. You can't change it. If you want a
different picture, you make a brand new print and keep (or toss) the old one.

How it bites you in code

const original = [1, 2, 3]
const copy = original        // NOT a copy! both names point to the SAME array
copy.push(4)
console.log(original)        // [1, 2, 3, 4]  <- surprise! the original changed too

copy = original did not make a new array. It just gave the same whiteboard
a second name. Writing through one name shows up under the other. Arrays and
objects in JavaScript are mutable, so this trap is everywhere.

// The fix: make a real new array (a fresh print), then change that
const original = [1, 2, 3]
const copy = [...original]   // new array with the same items
copy.push(4)
console.log(original)        // [1, 2, 3]  <- safe!
console.log(copy)            // [1, 2, 3, 4]

A real case: React state

React leans hard on immutability. If you change state in place, React often
can't tell anything changed, so your screen doesn't update.

// Wrong: mutating the same array. React may not re-render.
todos.push(newTodo)
setTodos(todos)

// Right: hand React a brand new array
setTodos([...todos, newTodo])

The rule "don't mutate state, replace it" is this exact idea. Treat state like a
printed photo: make a new one instead of scribbling on the old.

Gotchas juniors hit

1. Thinking = copies.
For arrays and objects, = copies the reference (the name), not the contents.
Both names share one thing.

2. const does not mean immutable.
const arr = [1,2] just means you can't point arr at something else. You can
still arr.push(3). The box is locked; the contents are not.

3. Shallow copies only go one level deep.
[...arr] copies the top level. Nested objects inside are still shared. Deep
data needs deeper copying.

Recap

Mutable = changeable after creation (a whiteboard).
Immutable = locked after creation (a printed photo).
In JS, = shares the same thing; it does not copy it.
For safe updates (especially React state), make a new value instead of changing the old one.

Your turn

Run the const copy = original; copy.push(4) example yourself and watch the
original change. Then fix it with [...original]. Once that "aha" lands, explain
"whiteboard vs printed photo" to a friend.

"Deterministic": Same Question, Same Answer, Every Time

Mohamed Idris — Thu, 04 Jun 2026 09:27:00 +0000

You run your tests. Green. You run them again, changing nothing. Red. You run a
third time. Green again. You haven't touched a thing, but the result keeps
flipping. Spooky, right?

That flickering test is not deterministic, and that one word explains a
whole family of frustrating bugs.

The idea in one line

Something is deterministic if the same input always gives the same output,
every single time.

The metaphor: a vending machine vs a slot machine

VENDING MACHINE                 SLOT MACHINE
press B4 -> always a cola       pull lever -> who knows?
   = DETERMINISTIC                 = NOT deterministic

Press B4 on a vending machine and you get a cola. Always. Press it a thousand
times, a thousand colas. That's deterministic: predictable, repeatable, trustable.

A slot machine takes the same pull and gives you a different result each time.
Fun for gambling. Terrible for code you need to trust.

How it shows up in code

// NOT deterministic: depends on the clock and a dice roll
function makeId() {
  return Date.now() + "-" + Math.random()  // different every call
}

// Deterministic: same input -> same output, forever
function double(n) {
  return n * 2   // double(5) is 10. today, tomorrow, on any machine.
}

double(5) is 10 and will be 10 until the end of time. But makeId() gives
you something new each call, because it leans on Date.now() and Math.random(),
two classic sources of "it depends."

A real case: flaky tests

The number one place juniors meet this word is flaky tests. A test that
passes and fails for no clear reason is usually leaning on something
non-deterministic:

The current time or date.
Random values.
The order results come back from an API or database.
Another test that ran first and left junk behind.

// Flaky: "today" changes, so this test rots over time
expect(formatDate(new Date())).toBe("2026-05-31")

// Stable: feed in a fixed input, get a fixed output
expect(formatDate(new Date("2026-05-31"))).toBe("2026-05-31")

The fix is almost always the same: stop depending on the unpredictable thing.
Pass the date in. Lock the random seed. Sort the list before checking it.

Gotchas juniors hit

1. Hidden inputs.
A function can look pure but secretly read the clock, a global, or a file. Those
hidden inputs make it non-deterministic. Hunt them down.

2. Relying on order you were never promised.
"The database gives rows back in insert order" is not guaranteed unless you
ORDER BY. Don't trust luck.

3. Thinking random is bad.
It's not! You want randomness for IDs, salts, and shuffles. Just keep it out of
the parts you need to test and trust.

Recap

Deterministic = same input, same output, every time. Like a vending machine.
Non-deterministic = results that change on their own. Like a slot machine.
The usual culprits: time, randomness, order, and leftover state.
Flaky tests almost always hide a non-deterministic input.

Your turn

Look at your flakiest test (you know the one). What unpredictable thing does it
touch: the clock, a random value, or an order you never pinned down? Make that
input fixed, and watch it go calm. Then go explain "vending machine vs slot
machine" to a friend.

SQL: When to Use != and When to Use IS NOT

Mohamed Idris — Wed, 03 Jun 2026 12:39:55 +0000

If you are learning SQL, you have probably written something like WHERE status != 'borrowed' and it worked fine. Then one day you tried WHERE bonus != 1000 and some rows mysteriously went missing. The reason is the difference between != and IS NOT. Let me explain it in plain English.

The Short Answer

!= (also written <>) compares values. Use it for text, numbers, and dates.
IS NOT compares against NULL, TRUE, or FALSE. In real life you will almost always use it as IS NOT NULL.

They are not interchangeable, and the reason is how SQL treats NULL.

Using != for Normal Values

This is the one you use most of the time. It checks if a value is different from another value.

WHERE status != 'borrowed'   -- status is not the text "borrowed"
WHERE id != 5                 -- id is not 5
WHERE rating != 8.9           -- rating is not 8.9

Simple. If the column has a real value, != does exactly what you expect.

Using IS NOT for NULL

NULL in SQL does not mean "empty." It means "unknown" or "missing." And here is the catch: you cannot compare anything to "unknown" using = or !=, because the result would also be unknown.

So this silently breaks:

WHERE status != NULL   -- returns NO rows, ever

Even a row where status is truly missing will not match, because something != NULL becomes NULL (unknown), and SQL only keeps rows where the condition is TRUE.

The correct way:

WHERE status IS NOT NULL   -- works as you would expect

Quick Reference Table

You want to check	Use
Value is different from another value	`!=` or `<>`
Column is not missing	`IS NOT NULL`
Column is missing	`IS NULL`
Value equals another value	`=`

A Real Gotcha Worth Remembering

Say you have a bonus column. Some employees have a number, and some have NULL because no bonus was recorded. You want everyone whose bonus is not 1000.

You might write this:

WHERE bonus != 1000

This will miss every employee with a NULL bonus, even though their bonus is clearly not 1000. To include them you need:

WHERE bonus != 1000 OR bonus IS NULL

This exact problem shows up a lot in practice (the classic "Employee Bonus" type query), so it is worth burning into memory.

Bonus: A Real Query

Here is a small example. You run a library and you want to report books with an odd ID whose status is not "borrowed", ordered by rating so the best available books show first.

SELECT *
FROM Books
WHERE id % 2 != 0
  AND status != 'borrowed'
ORDER BY rating DESC;

A couple of small notes:

!= works in MySQL, but the official SQL standard operator is <>. Both do the same job in MySQL.
Use single quotes ('boring') for strings. Double quotes work in MySQL but single quotes are safer if you ever switch databases.

Wrap Up

Remember it like this: != is for things that have a value, and IS NOT NULL is for checking that a value even exists. The moment NULL enters the picture, switch from != to IS NOT. That one habit will save you from a lot of confusing "where did my rows go" moments.

"Race Condition": When Two Things Reach for the Same Cookie

Mohamed Idris — Wed, 03 Jun 2026 09:26:00 +0000

There is one cookie left on the plate. You and your sibling both see it. You both
reach at the same time. Who gets it? Nobody planned for "both hands at once," so
the result is a mess (and maybe a broken plate).

Computers do this too, and we call it a race condition.

The idea in one line

A race condition is a bug that shows up when two things run at the same time
and the result depends on who happens to get there first.

The metaphor: the last cookie

Two people, one cookie. The rule was "first to grab it gets it." But if they
grab at the exact same moment, the rule breaks. Sometimes one wins, sometimes
the other, sometimes the cookie ends up on the floor. Same start, different
endings. That randomness is the smell of a race condition.

Time ->
You:     see cookie ----------- grab!
Sibling: see cookie -- grab!
                          ^ both saw "1 cookie", both grabbed. now what?

How it looks in code

Classic example: two requests buying the last item in stock.

// Both requests run this at almost the same time
const item = await db.getItem(7)      // both read: stock = 1
if (item.stock > 0) {                 // both see 1 > 0, both say "yes!"
  await db.setStock(7, item.stock - 1) // both write stock = 0
  await ship(item)                     // we just shipped TWO. we had ONE.
}

Both requests read stock = 1 before either one updated it. So both think
they're fine. You oversell. The bug only appears when the timing lines up, which
is why it's so sneaky: it passes every test on your laptop, then explodes on busy
days.

The fix: don't let them both reach at once

You make the "check and update" happen as one locked step, so the second
request has to wait its turn.

-- Let the database do the check-and-subtract atomically, one at a time
UPDATE products
SET stock = stock - 1
WHERE id = 7 AND stock > 0;   -- only succeeds if stock is still > 0
-- if 0 rows changed, you know you were too late. don't ship.

Now the database hands out the cookie to exactly one winner. The loser is told
"sorry, sold out," instead of both walking away thinking they won.

A real case

Race conditions love:

Selling the last ticket or item.
Two clicks creating two accounts with the same email.
A counter (likes, views) losing updates when many people act at once.

The pattern is always the same: read, decide, write, with someone sneaking in
between your read and your write.

Gotchas juniors hit

1. "It works on my machine."
Of course it does. You're the only user. Races need traffic. Test with the real
world in mind.

2. Adding a sleep to "fix" it.
Slowing things down just hides the bug for a while. The race is still there.

3. Trusting a read you made a moment ago.
By the time you write, the value may have changed. Let the database check the
condition at write time.

Recap

A race condition = the answer depends on who gets there first.
It hides during quiet times and bites under load.
The shape is always read, decide, write with a gap in the middle.
Fix it by making the check-and-change one locked, atomic step.

Your turn

Find a "read, check, then write" in your code (like "if username is free, create
it"). Imagine two users doing it at the exact same millisecond. Could both win?
If yes, you found a race. Tell a friend about the last cookie.

"Atomic": All of It, or None of It

Mohamed Idris — Tue, 02 Jun 2026 09:26:00 +0000

You send money to a friend. The app takes $50 out of your account. Then, right
in the middle, the server crashes. Your $50 is gone, but your friend never got
it. Money just vanished into the void.

That nightmare is exactly what the word atomic is here to prevent.

The idea in one line

An atomic action either fully happens or fully doesn't. There is no
half-finished, in-between mess.

The metaphor: stapling pages together

Imagine a contract with two pages: "take $50 from Alex" and "give $50 to Sam."

If the pages are loose, someone could grab page one and drop page two. Disaster.
So you staple them together. Now they move as one thing. Either both pages go
through, or neither does. You can't tear them apart.

NOT ATOMIC                       ATOMIC (stapled)
[ take $50 ] done                [ take $50 ]  \
[ give $50 ] CRASH                            } both, or neither
money lost                       [ give $50 ]  /

"Atomic" comes from the old idea of an atom: something you cannot cut in half.

How you actually do it: a transaction

In databases, you staple steps together with a transaction.

-- Wrong way: two separate steps. A crash between them loses money.
UPDATE accounts SET balance = balance - 50 WHERE name = 'Alex';
-- ... crash here ...
UPDATE accounts SET balance = balance + 50 WHERE name = 'Sam';

-- Right way: staple them. All of it, or none of it.
BEGIN;
  UPDATE accounts SET balance = balance - 50 WHERE name = 'Alex';
  UPDATE accounts SET balance = balance + 50 WHERE name = 'Sam';
COMMIT;   -- if anything fails before this, ROLLBACK undoes the whole thing

BEGIN starts the staple. COMMIT makes it real. If something breaks in
between, a ROLLBACK throws the whole half-done mess away, like it never started.

A real case

Any time two things must be true together, you want atomic:

Move money between accounts.
Book the last concert seat AND charge the card.
Create a user AND give them a starter project.

If only one half lands, you get "ghost" data: a charge with no seat, a user with
no project. Atomic operations keep those from ever existing.

Gotchas juniors hit

1. Doing related writes as separate, unprotected steps.
Two UPDATEs in a row are not safe just because they sit next to each other in
your code. Wrap them.

2. Confusing atomic with "fast."
Atomic is about all-or-nothing, not speed. A slow operation can still be atomic.

3. Thinking one row is always safe but many rows aren't.
A single statement is usually atomic on its own. The danger shows up when one
logical action needs multiple steps. That's when you reach for a transaction.

Recap

Atomic = all of it, or none of it. No half-done state.
Picture stapled pages: they move together or not at all.
In databases, you get this with a transaction (BEGIN ... COMMIT).
Use it whenever two or more changes must succeed together.

Your turn

Find a place in your app where you write to the database twice for one action.
Ask: "What if it crashes between the two writes?" If that scares you, wrap them
in a transaction. Now go explain "stapled pages" to a friend.

A bot opened a pull request for me! and I finally "got" automation

Mohamed Idris — Tue, 02 Jun 2026 03:42:49 +0000

Today I added a tool called Renovate to one of my projects. A few minutes later, something quietly magical happened: a bot opened a pull request for me, my tests ran themselves, and after I clicked one button, my app redeployed with the update.

I didn't write a single line of code for any of that.

That's the moment it clicked for me. There's a whole world of little robots that do the boring, repetitive parts of building software so you don't have to. Companies lean on them heavily. And once you see the pattern, you start spotting places to use them everywhere.

This post is the friendly tour I wish I'd had. No deep jargon, I promise — and if I use a word, I'll explain it.

The one idea behind all of them

Every one of these tools, no matter how fancy it sounds, is built on the same simple idea:

When X happens, do Y.

That's it. Something happens (you push code, a clock hits 6am, a website goes down), and the bot does a task in response (runs your tests, sends a message, opens a fix). No human needed for the boring middle part.

A nice way to picture it: imagine a tireless assistant who

watches your project,
follows the rules you set,
does the repetitive task, and
only taps you on the shoulder when a real human decision is needed.

That's the whole genre. The differences are just what they watch and what they do.

Quick vocab, so nothing trips you up:
PR (pull request) = a proposed change to your code that you review and approve. CI/CD = robots that automatically test and ship your code. Webhook = a little "hey, something just happened!" ping one app sends to another.

Why companies are obsessed with these

Because boring work is where humans make mistakes and lose time. Bots are good at exactly the things we're bad at:

They never forget a step on the checklist.
They never get tired, and they work at 3am.
They do the same job whether you have 1 project or 1,000.
They free people up to do the thinking work instead of the chores.

A junior engineer with good automation can quietly do the work of a much bigger team. That's not hype — it's just leverage.

Real use cases, across very different areas

Here's where it gets fun. These bots aren't just one thing. Let me walk through genuinely different corners of the software world.

1. Keeping your code safe and up to date

This is the one that started my "aha." The libraries your app depends on get updates all the time — bug fixes, new features, and importantly, security patches. Staying current by hand is tedious and easy to forget.

Renovate and Dependabot watch for new versions, open a PR with the update, let your tests run on it, and wait for you to merge. Snyk focuses on the scary stuff: it warns you when a library you use has a known security hole.

Think of it as a friend who reads every "version 2.4.1 is out" announcement so you never have to.

2. Reviewing every change, automatically

Good teams review each other's code. But humans forget things, and reviews take time. So bots help:

Codecov tells you if your new code is actually covered by tests.
SonarCloud and CodeRabbit read the change and leave comments about bugs, smells, or style.
GitGuardian screams if you accidentally committed a password or API key.

It's like having a reviewer who never sleeps and never forgets the checklist — so the humans can focus on the interesting parts of the review.

3. Building, testing, and shipping (CI/CD)

This is the backbone. You push code, and a robot builds it, runs all the tests, and deploys it if everything's green. Tools: GitHub Actions, GitLab CI, CircleCI.

On top of that, release bots like semantic-release and release-please read your commit messages, figure out the new version number, write the changelog, and tag the release — all by themselves.

My own setup does this: I push to the main branch, the tests run, and if they pass, the app redeploys to my server. I haven't manually deployed anything in weeks.

4. Talking to your team (alerts and "ChatOps")

Software needs to tell humans things. Bots are the messengers:

UptimeRobot and healthchecks.io ping your sites and message you the moment one goes down.
PagerDuty and Opsgenie wake up the on-call engineer when something breaks at night.
Slack, Discord, and Telegram bots post updates: a new signup, a failed payment, a daily summary.

Fun fact: I build Telegram bots that send people a verse of the Quran every morning. That's exactly this category — a bot that does something useful on a schedule and talks to people. If you've ever made a Discord bot, you've already lived here.

5. Tidying up your issues and project board

Open-source projects and busy teams drown in issues and tasks. Bots keep things tidy:

A stale bot politely closes issues nobody has replied to in months.
Triage bots auto-label new issues ("bug", "documentation") and assign them.
Linear and Jira automations move a card to "Done" the moment its PR is merged.

Small things, but they save hours of clicking every week.

6. Infrastructure on autopilot (GitOps)

Here's a wilder one. Instead of clicking around a cloud dashboard to set up servers, you describe your infrastructure in a file. Then a bot makes the real world match the file.

Terraform + Atlantis: you open a PR that changes your infrastructure, and a bot shows exactly what will change before you approve it.
ArgoCD / Flux: whatever's in your Git repo is what's running, always. Change the file, the cluster updates itself.

The big idea: your servers are described in code, and a robot keeps reality in sync. Fewer "it works on my machine" surprises.

7. Connecting apps with zero code

Not everything needs to be programmer-y. Tools like Zapier, Make, n8n, and IFTTT let you wire apps together by dragging boxes around:

New Google Form submission → add a row to a spreadsheet → send a welcome email.

No coding. This is huge for small businesses and side projects, and honestly even devs use it for quick wins instead of writing a whole script.

Bonus: the new wave — AI agents

The newest members of this family use AI to do fuzzier work: reviewing a PR in plain English, drafting a fix, triaging a bug report, or answering "why is this failing?" They're early and not magic, but they're the same old pattern — watch, decide, act — with a smarter brain in the middle. Worth keeping an eye on.

So how do they actually work? (the honest, simple version)

Under the hood, almost all of them start from one of two triggers:

An event — something happens and an app gets a webhook ping. "Someone just pushed code." "A new issue was opened." The bot wakes up and reacts.
A schedule — a clock. "Every hour, check for new versions." "Every morning at 6am, send the report." (Programmers call this a cron job.)

Then the bot uses an API (a way for programs to talk to each other) to do the actual task — open a PR, post a message, restart a server.

On GitHub, many of these are "GitHub Apps" you install with a click and give specific permissions to. That's exactly what I did with Renovate: install, point it at my repos, done.

You can build these too (you might already have)

Here's the encouraging part: this is not wizard stuff. If you've ever:

written a script that runs on a schedule, or
made a Telegram/Discord bot, or
set up a GitHub Action,

…you've already built an automation bot. The mental model is the whole skill. The tools are just details you look up when you need them.

Start tiny. Pick one annoying thing you do by hand every week, and ask: could a "when X, do Y" robot do this?

Ideas to spark your next project

A few buildable ones, from "an afternoon" to "a real product":

A bot that posts your app's daily signups to a Discord channel each morning.
A scheduled job that backs up your database and messages you if the backup fails.
A PR bot that comments "hey, you forgot to update the changelog."
A bot that checks all your websites are up and texts you if one isn't.
A friendly "welcome!" bot that greets first-time contributors on your open-source repo.
A "stale PR" nudger that pings you about pull requests sitting untouched for a week.
A no-code Zapier flow: new customer in Stripe → add them to your mailing list → say hi.

The takeaway

These tools aren't magic. They're just patient. They do the small, repetitive, easy-to-forget tasks so you can spend your energy on the parts that actually need a human brain.

Once you start noticing the chores in your own workflow — updating dependencies, deploying, sending the same message, checking the same dashboard — you'll see automation opportunities everywhere.

My advice? Pick the most boring thing you did this week, and let a robot do it next week. That first "it worked while I was making tea" moment is genuinely delightful. ☕

If you found this useful, take a moment and think of a boring task you want to automate first.

"Idempotent": The Scary Word That Means "Press It Again, It's Fine"

Mohamed Idris — Mon, 01 Jun 2026 11:30:00 +0000

You click Pay Now. The page hangs. Did it work? You don't know. So you click
it again. And now you're sweating, because what if you just paid twice?

That little moment of fear is exactly the problem one fancy word solves. The word
is idempotent. It sounds like a spell from a wizard book, but the idea is
simple and you already understand it from real life.

The idea in one line

An action is idempotent if doing it once or doing it ten times leaves the
world in the same state.

The metaphor: a light switch vs a counter

Think about two buttons.

ELEVATOR "UP" BUTTON              A TALLY COUNTER
press once  -> light on          press once  -> 1
press again -> still on          press again -> 2
press 50x   -> still on          press 50x   -> 50
   = IDEMPOTENT                      = NOT idempotent

Pressing the elevator button again does nothing new. The button is already lit,
the elevator is already coming. That extra press is harmless. That is
idempotent.

The tally counter is the opposite. Every press changes the result. Pressing it
again is never safe if you only meant to count once.

So when someone says "make this endpoint idempotent," they mean: make it like
the elevator button, not the tally counter.

Where you actually meet this: HTTP

HTTP methods are a classic example. Some are idempotent by design.

GET    /users/7      read it        -> idempotent (reading never changes anything)
PUT    /users/7      set name="Al"  -> idempotent (set to the same value = same result)
DELETE /users/7      remove user 7  -> idempotent (gone once, gone forever)
POST   /users        create a user  -> NOT idempotent (each call makes a NEW user)

See PUT? "Set the name to Al" gives the same result whether you call it once or
five times. The name is just Al at the end. But POST to create a user? Call it
five times and you get five users. Oops.

That's why a flaky network plus a POST is the scary "did I pay twice?" combo.

The fix: an idempotency key

Real payment APIs (like Stripe) solve this with an idempotency key. You make
up a unique id for the action and send it along:

// What a junior might write first
await fetch("/charge", {
  method: "POST",
  body: JSON.stringify({ amount: 2000 }),
})
// retry on timeout -> might charge twice. yikes.

// The fix: send a key that names THIS one attempt
await fetch("/charge", {
  method: "POST",
  headers: { "Idempotency-Key": "order-42-attempt" }, // same key on every retry
  body: JSON.stringify({ amount: 2000 }),
})

Now the server has a rule: "If I already saw order-42-attempt, don't charge
again. Just return the result from last time." Retry as much as you want. One
charge. The button is now an elevator button.

A real case you've probably hit

Webhooks. A service like GitHub or Stripe sends your server a message ("payment
succeeded!"). Networks being networks, they sometimes send the same message
twice to be safe. If your handler is idempotent, the duplicate does no harm. If
it isn't, you might email the customer twice or ship two boxes.

The senior move: check "have I already handled event evt_123?" before doing
the work.

Gotchas juniors hit

1. Thinking idempotent means "returns the same response."
Not quite. It means the state ends up the same. A second DELETE might
return 404 Not Found instead of 200 OK, and that's fine. The user is still
deleted. Same world.

2. Assuming POST can never be safe.
It can, with an idempotency key. The method isn't magic; your design is.

3. Forgetting reads can have side effects.
A GET that secretly bumps a "view count" is no longer truly idempotent. Keep
reads clean.

Recap

Idempotent = doing it again changes nothing new. Like an elevator button.
Not idempotent = each call adds up. Like a tally counter, or POST /users.
It's about the final state, not the exact response text.
Make risky actions safe with an idempotency key so retries can't double up.

Your turn

Look at the last form you built. If a user double-clicks submit on a slow
connection, what happens? If the answer is "two records," you found a spot that
wants idempotency. How would you fix it?

If you can explain "elevator button vs tally counter" to a friend, you've got it.

SSH Keys Easily Explained

Mohamed Idris — Mon, 01 Jun 2026 09:30:00 +0000

You signed up for a hosting service. You're ready to deploy your app. Then a box
pops up: "Paste your SSH public key."

And you freeze. What key? Where is it? Is it safe to paste? Did I just leak
something I shouldn't?

Take a breath. By the end of this post you'll know exactly what an SSH key is,
why there are two of them, and what to paste (and what to never, ever paste).
You'll get it so well you could teach a friend.

The idea in one line

An SSH key is a pair of files that lets you prove who you are to a server,
without typing a password.

The metaphor: a padlock and its only key

Think of a public key as a padlock. You can make a thousand copies of it and
hand them out to anyone. Servers, friends, GitHub, your hosting provider. It's
fine. A padlock locked shut is useless to a stranger.

Think of the private key as the one real key that opens those padlocks.
There is only one, it lives on your computer, and you never give it away. Ever.

PUBLIC KEY  =  a padlock        -> share it freely
PRIVATE KEY =  the only key     -> keep it secret, keep it safe

So when a server wants to know "are you really you?", it puts a message inside a
box, locks it with your padlock (public key), and tosses it over. Only your real
key (private key) can open it. You open it, prove you can, and you're in.

The magic part: your private key never leaves your machine. The server only
ever sees the padlock.

How it actually works (the short version)

You                                  Server
 |                                      |
 | "Hi, I'm Alex"     ----------------> |
 |                                      |  finds your padlock (public key)
 |                                      |  locks a random message with it
 | <----------------  here's a puzzle   |
 |                                      |
 | unlock it with my                    |
 | private key, send proof  ----------> |
 |                                      |  proof checks out
 | <----------------  welcome in!       |
 |                                      |

You never send your private key across the internet. You only send proof that
you own it. That's why SSH keys are way safer than passwords. A password gets
typed and sent; a private key just stays home and answers puzzles.

Making your keys (the part you actually do)

Open a terminal and run this one command:

ssh-keygen -t ed25519 -C "you@example.com"

ssh-keygen is the tool that makes the key pair.
-t ed25519 picks a modern, strong key type. (If a service complains it's too old to support it, use -t rsa -b 4096 instead.)
-C "..." is just a label, usually your email, so you remember whose key it is.

It will ask where to save and for an optional passphrase. Press Enter to accept
the defaults. When it's done, you have two new files:

~/.ssh/id_ed25519        <- PRIVATE key. secret. never share.
~/.ssh/id_ed25519.pub    <- PUBLIC key. the .pub one is safe to share.

See that .pub? That tiny detail saves people. The file ending in .pub is
the public one. That is the one you paste into hosting dashboards.

"The host wants my SSH key": what to actually paste

When a hosting service, GitHub, or a server asks for "your SSH key," they almost
always mean your public key. Here's how to grab it safely:

cat ~/.ssh/id_ed25519.pub

You'll see something like this:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAID...a bunch of characters... you@example.com

Copy that whole line and paste it into the box. Done. That's the padlock. It is
meant to be shared, so pasting it is totally safe.

The box says "SSH key"?
        |
        v
Paste the file that ends in  .pub      [ OK ]   yes
Paste the file with NO .pub            [STOP]   NEVER (that's your private key)

If you ever open a file and the very first line says
-----BEGIN OPENSSH PRIVATE KEY-----, stop. That's the private one. Close it
and grab the .pub file instead.

A real case: deploying with `git push`

Say you set up your public key on your hosting provider. Now you can do this:

git push production main

No password prompt. No "enter your credentials." It just works, because your
machine quietly proves it owns the matching private key. That smooth, password-free
deploy you've seen senior devs do? This is the whole trick.

Same thing with connecting to a server directly:

ssh user@your-server.com
# you're in, no password typed

Gotchas juniors hit

1. Pasting the private key by mistake.
If you ever paste a key and it starts with -----BEGIN ... PRIVATE KEY-----, you
pasted the wrong file. Treat that key as burned: generate a new pair and replace
it everywhere.

2. Thinking you need a new key for every service.
You don't. One public key can go on GitHub, your host, and ten servers at once.
It's a padlock. Copies are fine.

3. Wrong file permissions.
SSH is picky for your safety. If it refuses your key, tighten the permissions:

chmod 600 ~/.ssh/id_ed25519        # private key: only you can read it
chmod 644 ~/.ssh/id_ed25519.pub    # public key: readable is fine

4. Forgetting to back up the private key.
If you wipe your laptop without saving ~/.ssh/, that key is gone. You're not
locked out forever (just make a new pair and re-add the public key everywhere),
but it's annoying. Keep a safe backup.

Recap

An SSH key is a pair: a public key (padlock) and a private key (the only key).
Share the public key freely. It's the file ending in .pub.
Never share the private key. It stays on your machine and just answers puzzles.
When a host asks for "your SSH key," paste the .pub file. That's it.
Result: secure, password-free logins and deploys.

Your turn

Run ssh-keygen -t ed25519 on your machine, then run
cat ~/.ssh/id_ed25519.pub. Look at the two files you made. Which one would you
paste into a hosting dashboard, and which one would you guard with your life?

If you can answer that out loud, you've got it. Now go teach a friend.

Part 14: Window Functions (Ninja Mode)

Mohamed Idris — Fri, 29 May 2026 17:48:42 +0000

This post is part of the SQL: Zero to Ninja series.

Your boss asks: "Show me each user's orders, and next to every order put its rank, like their 1st order, 2nd order, 3rd, by total." You reach for GROUP BY... and hit a wall. GROUP BY squashes all of a user's orders into one row. But you wanted to keep every order AND add a rank. You need both. That is exactly what window functions do, and they are the move that turns you into a SQL ninja.

The idea in one line

A window function computes a value across a group of rows (a "window") while keeping every single row, unlike GROUP BY, which collapses them into one.

The metaphor: the bakery queue

You are standing in line at the bakery. A little screen says you are customer number 4. You can see your position in the line. But here is the thing: you are still you, still standing there as yourself. You did not get blended into "the line." You kept your identity and also got a number.

That is a window function. Every row stays itself, and you bolt on extra info computed from the rows around it (your position, the running total, the person before you).

GROUP BY is the opposite. It is like the baker saying "I do not care about individuals, there are 12 people total." Twelve people become one number. Useful sometimes, but you lost everybody.

The shape: OVER (PARTITION BY ... ORDER BY ...)

A window function always has an OVER (...) clause. That is what makes it a window function.

SELECT
  name,
  total,
  ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY total DESC) AS rank_in_user
FROM orders;

Read OVER (...) in plain English:

PARTITION BY user_id   -->  split rows into one queue per user
ORDER BY total DESC     -->  inside each queue, line them up biggest first
ROW_NUMBER()            -->  hand each row its position number

PARTITION BY is like having a separate bakery line per user. ORDER BY decides who stands where. No PARTITION BY? Then it is one big single line for the whole table.

Numbering rows: ROW_NUMBER, RANK, DENSE_RANK

These three all number rows, but they treat ties differently. Say two orders have the same total of 100.

total   ROW_NUMBER   RANK   DENSE_RANK
 150        1          1         1
 100        2          2         2
 100        3          2         2
  80        4          4         3

ROW_NUMBER(): always 1, 2, 3, 4. No ties allowed, it just picks an order. Great for "give me exactly one row each."
RANK(): ties share a number, then it skips ahead (1, 2, 2, 4). Like the Olympics, two silvers and no bronze.
DENSE_RANK(): ties share a number, but it does not skip (1, 2, 2, 3). No gap.

Pick ROW_NUMBER when you need a unique number, RANK/DENSE_RANK when ties should genuinely tie.

Running totals with SUM() OVER

Add ORDER BY inside the window and SUM becomes a running total (each row adds itself to everything before it):

SELECT
  id,
  total,
  SUM(total) OVER (ORDER BY created_at) AS running_total
FROM orders;

id  total   running_total
 1    50         50
 2    30         80     (50 + 30)
 3    20        100     (80 + 20)

Every row is still here, and now each one knows the total so far. Try doing that with GROUP BY. You cannot, because GROUP BY would have crushed these into one row.

Peeking at neighbors: LAG and LEAD

LAG() looks at the previous row, LEAD() looks at the next one. Perfect for "compare this order to the user's last order."

SELECT
  user_id,
  total,
  LAG(total) OVER (PARTITION BY user_id ORDER BY created_at) AS previous_total
FROM orders;

user_id  total   previous_total
   7       50         NULL    (first order, nobody before)
   7       80         50      (look back one row)
   7       60         80

Now subtract total - previous_total and you instantly see if a user is spending more or less than last time.

The killer real case: top 3 orders per user

Here is the request from the top of the post: rank each user's orders, biggest first. ROW_NUMBER with PARTITION BY nails it:

SELECT
  user_id,
  total,
  ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY total DESC) AS rn
FROM orders;

Same trick ranks products by price inside each category:

SELECT
  category,
  name,
  price,
  ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC) AS price_rank
FROM products;

Notice the difference from GROUP BY:

GROUP BY category       -->  ONE row per category (you lose the products)
ROW_NUMBER() OVER (...) -->  EVERY product stays, plus a rank column

That is the whole point. The window keeps everybody and adds a column.

Gotcha: you cannot filter a window result in WHERE

This is the big one. Window functions run after WHERE. So you cannot say WHERE price_rank <= 3, the rank does not exist yet when WHERE runs.

-- WRONG: price_rank is not known during WHERE
SELECT category, name,
  ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC) AS price_rank
FROM products
WHERE price_rank <= 3;   -- error!

The fix is to wrap it in a subquery or a CTE (remember Part 10?), then filter on the outside:

-- RIGHT: compute the rank inside, filter it outside
WITH ranked AS (
  SELECT category, name,
    ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC) AS price_rank
  FROM products
)
SELECT category, name
FROM ranked
WHERE price_rank <= 3;   -- now it works, the column exists out here

That CTE wrapper is the standard "top N per group" pattern. Memorize it.

Gotchas juniors hit

Filtering on a window in WHERE. It is not there yet. Wrap it in a CTE or subquery and filter outside.
Forgetting PARTITION BY. Without it, your "rank per user" becomes "rank across the whole table." The partition is what resets the count for each group.
Mixing up RANK and DENSE_RANK on ties. RANK leaves gaps (1, 2, 2, 4), DENSE_RANK does not (1, 2, 2, 3). Pick on purpose.

Recap

A window function keeps every row and adds a value computed from nearby rows. GROUP BY collapses rows; windows do not.
Shape: function OVER (PARTITION BY ... ORDER BY ...).
ROW_NUMBER, RANK, DENSE_RANK number rows and differ on ties. SUM() OVER (ORDER BY ...) gives running totals. LAG/LEAD peek at neighbors.
"Top N per group" = ROW_NUMBER() inside a CTE, then filter in the outer WHERE.
Windows run after WHERE, so filter their results in a wrapper, not in WHERE.

Your turn

Write a query that gives each user only their single most expensive order (use ROW_NUMBER() and a CTE wrapper). Which column do you PARTITION BY, and what do you keep where rn = 1? Explain it to a friend and the ninja headband is yours.

And that is the series. You went from "what even is a database" all the way to window functions, the stuff a lot of working devs still find scary. You can query, filter, join, group, change data safely, model relationships, use subqueries and CTEs, index for speed, wrap things in transactions, block SQL injection, and now slice data with windows. That is a real, job-ready SQL toolkit.

So go build something. A tiny dashboard, a leaderboard, a "top products" report, anything that makes you write real queries against real data. That is how it sticks. Want to revisit a topic or share the series with a friend? Head back to the README for the full roadmap. Congratulations, ninja. You finished.