DEV Community: Sarim Nadeem

10 API and Database Blunders Every Beginner Makes (and How to Fix Them Before Production Bites Back)

Sarim Nadeem — Sat, 13 Jun 2026 04:13:25 +0000

You wrote your first REST endpoint. You ran your first SELECT *. Things worked. Life was good.

Then a colleague casually mentioned "idempotency key," another asked why your /users?page=10000 request takes 12 seconds, and your tech lead frowned at your migration script. Suddenly, "it works on my machine" is not enough anymore.

I have been through that frowning-tech-lead phase. So has every senior engineer you know. The mistakes are surprisingly predictable — and almost all of them are easy to avoid if someone points them out before you ship.

This post is that someone.

Below are 10 mistakes I see beginners make again and again with APIs and databases. For each one, you get the blunder, why it bites, and the actual fix.

TL;DR for the skimmers: Always use idempotency keys on mutating endpoints. Use cursor pagination, not offset. Version your API from day one. Normalize first, denormalize only when profiled data tells you to. Index foreign keys. Watch out for N+1 queries. Never run blocking schema changes on hot tables.

Part 1 — API Blunders

1. Shipping a POST endpoint without idempotency keys

This is the single most expensive mistake on day 1 of API design, and almost nobody catches it in a code review.

The blunder:

POST /orders
{ "user_id": 42, "amount": 99.99 }

The user taps "Pay." The phone's signal drops mid-request. The HTTP client retries. Two charges. One angry customer. One support ticket.

GET requests are naturally safe to retry — reading does not change state. But POST, PATCH, and DELETE are not. Without protection, every network blip becomes a duplicate.

The fix — accept an Idempotency-Key header:

POST /orders
Idempotency-Key: 8f14e45f-ceea-467a-9575-d7a08c9b4f1c
{ "user_id": 42, "amount": 99.99 }

On the server side:

Client generates a UUID and sends it on every mutating request.
Server checks if it has seen that key. If yes, return the stored response — do not re-execute.
If no, process the request, store the response keyed by that UUID, then return it.
Expire the record after 24 hours.

Stripe's entire business depends on this pattern. If they had shipped without it in 2011, retrofitting it would have been a breaking change for every customer they had. Bake it in from day one.

A minimal SQL schema for storing idempotency records

CREATE TABLE idempotency_keys (
  key           TEXT PRIMARY KEY,
  api_key_id    BIGINT NOT NULL,
  request_path  TEXT NOT NULL,
  request_hash  TEXT NOT NULL,
  status        TEXT NOT NULL DEFAULT 'processing',
  response_code INT,
  response_body JSONB,
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  expires_at    TIMESTAMPTZ NOT NULL DEFAULT now() + INTERVAL '24 hours'
);

Tip: wrap the idempotency check and the business operation in the same database transaction. This prevents a crash between "recorded the key" and "completed the work" from leaving you in a half-done state.

2. Using offset pagination on anything that will grow

Almost every beginner writes pagination like this:

SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 200000;

It works. On page 1. With 10,000 rows, it still works. Then your table hits 50 million rows and ?page=10000 takes 5 seconds.

Why it breaks: Offset pagination tells the database "skip the first 200,000 rows, then give me 20." The database literally scans and discards 200,000 rows before reading the ones you want. There is no index optimization that fixes this — it is how OFFSET works.

The fix — cursor-based pagination:

-- First page
SELECT id, name, created_at FROM orders
ORDER BY created_at DESC, id DESC
LIMIT 21;

-- Next page — cursor decodes to the last seen (created_at, id)
SELECT id, name, created_at FROM orders
WHERE (created_at, id) < ('2025-12-01T10:30:00Z', 9847)
ORDER BY created_at DESC, id DESC
LIMIT 21;

Return a response shaped like this:

{
  "data": [ ... ],
  "pagination": {
    "has_more": true,
    "next_cursor": "eyJjcmVhdGVkX2F0IjoiMjAyNS0xMi0wMVQxMDozMDowMFoiLCJpZCI6OTg0N30="
  }
}

Quick comparison so you know when to pick which:

Approach	Performance at deep pages	Stable during inserts?	Best for
Offset (`?page=2`)	Slow (scans + discards)	No (page contents shift)	Tiny admin tables (under 100K rows)
Cursor (`?cursor=abc`)	Fast at any depth	Yes	Public APIs, feeds, anything that grows

Pro tip: Fetch LIMIT + 1 rows. If you get the extra one back, set has_more: true and drop it. This saves you a separate COUNT(*) query, which on a large table can take 30+ seconds on its own.

3. "We will add versioning later"

You will not. Or, more precisely, you will — and it will be a breaking change for every existing consumer.

The blunder: Shipping /users instead of /v1/users. When a breaking change inevitably comes, you have to either tell every client to update or maintain a confusing patchwork.

The fix — pick a versioning strategy on day one:

For public APIs, just use URL path versioning. It is the most discoverable and the easiest for third parties.

GET /v1/users/123

That is it. Adding /v1/ on day one is a 30-minute decision. Retrofitting it after launch is a multi-month migration.

A common pushback is "versioning is premature optimization." It is not. Adding versioning later is breaking. Adding it now is free. The asymmetry makes the decision for you.

4. Useless error responses

Compare these two error responses:

Bad:

HTTP/1.1 400 Bad Request

Good:

{
  "error": {
    "code": "invalid_currency",
    "message": "Currency 'usd' is not valid. Did you mean 'USD'? Currencies must be uppercase ISO 4217 codes.",
    "param": "currency",
    "request_id": "req_8f14e45f"
  }
}

Good error messages are the best API documentation. They tell developers exactly what went wrong, why, and how to fix it. The request_id field is a small thing that pays for itself a hundred times over when someone opens a support ticket — you can correlate it to a log entry in seconds.

Pick one consistent error envelope and use it across every endpoint. Do not let one route return { "error": "..." } and another return { "errors": [...] }. Clients build error handlers around that shape. Changing it later is a breaking change even when the HTTP status code is the same.

5. Wrong HTTP status codes (or all 200s)

A surprising number of APIs return 200 OK with { "success": false, "error": "..." } in the body. Please do not do this.

HTTP status codes exist precisely so clients, proxies, monitoring tools, and load balancers can react without parsing your JSON. The basics every beginner should memorize:

Code	Meaning	Common use
`200`	OK	Successful GET/PUT/PATCH
`201`	Created	Successful POST that created a resource
`204`	No Content	Successful DELETE
`400`	Bad Request	The request body is malformed
`401`	Unauthorized	Not authenticated (no/invalid token)
`403`	Forbidden	Authenticated, but not allowed
`404`	Not Found	The resource does not exist
`409`	Conflict	Conflicting state (e.g., duplicate email)
`422`	Unprocessable Entity	Validation failure on otherwise-valid request
`429`	Too Many Requests	Rate limited — include `Retry-After`
`500`	Internal Server Error	Your bug, not theirs

A common beginner mix-up: using 401 when you mean 403. Remember — 401 means "I do not know who you are," 403 means "I know who you are, you just cannot do this."

6. Mixing naming conventions

This one is small but it is the number-one developer complaint about inconsistent APIs:

GET /users         → { "createdAt": "...", "userName": "..." }
GET /orders        → { "created_at": "...", "user_name": "..." }
GET /products      → { "creation_date": "...", "name": "..." }

Three endpoints. Three conventions. One frustrated client developer.

Pick one — snake_case or camelCase — and apply it everywhere. If one endpoint uses created_at, every endpoint uses created_at. Add a linter (spectral is great for OpenAPI specs) to your CI so this fails the build automatically. Humans will not catch this consistently. Linters will.

Part 2 — Database Blunders

7. Denormalizing "for performance" before you have a problem

Here is a scene I have witnessed more times than I can count:

Beginner: "I am going to copy the user's name into every order so I do not have to JOIN."

Then the user updates their name. Now half the orders show "Sarah" and half show "Sara." And nobody knows which one is current.

Quick refresher:

Normalization stores each fact exactly once. The user's name lives in users. Orders reference the user via user_id. Reading an order with the user's name requires a JOIN.
Denormalization copies data for read speed. The user's name is also stored on the orders row, so you skip the JOIN.

When normalization is the right default:

You are building a new application and do not know your read patterns yet.
Data integrity matters (financial records, anything regulatory).
Writes are roughly as common as reads.

When denormalization actually earns its place:

Reads outnumber writes by a huge margin (a product catalog read 1,000× per write).
JOINs are measurably the bottleneck — you have profiled, not guessed.
You are building a read-optimized model on the side, such as a search index, analytics table, or CQRS read model — and you have a clear story for how it gets refreshed.

The order matters: normalize first, then denormalize specific paths when the data tells you to. Going the other way around — starting denormalized and trying to clean it up — is one of the most painful refactors in software.

Rule of thumb: If you are reaching for denormalization before you have a query profiler showing a JOIN is the bottleneck, you are guessing. Add proper indexes first. Most "JOIN performance problems" turn out to be missing indexes.

8. Indexing nothing — or indexing everything

Two equally common, equally painful extremes.

Indexing nothing. Every query is a full table scan. The application feels fine for a week. Then your users table hits a million rows and login takes 3 seconds because you forgot an index on email.

Indexing everything. Every INSERT, UPDATE, and DELETE now has to update all 12 indexes you created "just in case." Writes get slower and slower until your hot table cannot keep up with traffic.

Indexes are not free. Every index adds a write operation to every change of the underlying row. A table with 8 indexes means a single insert causes roughly 9 disk writes (1 for the table, 8 for the indexes).

A sane starting point:

Always index your primary key (the database does this for you).
Index every foreign key. Beginners forget this constantly, and unindexed FKs make JOINs slow and DELETE on the parent table catastrophic.
Index columns you WHERE on most often (email, status, user_id).
For multi-column filters, use a composite index — but pay attention to column order. A composite index on (user_id, created_at) helps WHERE user_id = ? AND created_at > ? but not WHERE created_at > ? alone. Put the column you filter by exact match first; put the range column last.
Then stop. Adding more indexes "for safety" actively hurts you.

Bonus blunder — functions on indexed columns

-- Does NOT use the index on `email`
SELECT * FROM users WHERE LOWER(email) = 'sara@example.com';

The function wraps the column, so the database cannot use the index. Either store the value already lowercased, or create a functional index:

CREATE INDEX idx_users_email_lower ON users (LOWER(email));

This is one of the most common reasons "I added an index but my query is still slow" tickets land in senior engineers' inboxes.

9. The N+1 query problem

This is the silent killer. Your tests pass. Your dev environment is fast. Production goes live, and every page load fires 500 database queries.

The blunder (in pseudo-code, but every ORM has its flavor):

const orders = await db.query("SELECT * FROM orders WHERE user_id = ?", userId);
// orders.length = 50

for (const order of orders) {
  // BOOM — this fires one query per order. 50 orders = 50 queries.
  order.items = await db.query("SELECT * FROM items WHERE order_id = ?", order.id);
}

One initial query (the "1") plus N follow-up queries (one per row). Hence "N+1."

The fix — fetch in batches:

-- Single query, get all items for all 50 orders at once
SELECT * FROM items WHERE order_id IN (1, 2, 3, ..., 50);

Then group them in memory by order_id. One round-trip instead of fifty.

Most ORMs have a name for this. In Rails it is includes. In Sequelize it is include. In Django it is select_related / prefetch_related. In Prisma it is include. Learn yours. If you take only one thing from this section, take this.

10. Running ALTER TABLE on a live, large table during business hours

The first time you do this in production, you find out two things very fast:

ALTER TABLE on a table with 100 million rows can lock the table for hours.
Locked means no writes. Locked means your application throws errors. Locked means an incident channel that pings you at 3 a.m.

The fix — never do a blocking schema change on a hot table. Use online schema migration tooling:

MySQL: gh-ost (built by GitHub for exactly this reason) or pt-online-schema-change.
PostgreSQL: Most simple changes (ADD COLUMN with no default, CREATE INDEX CONCURRENTLY, ADD CONSTRAINT NOT VALID then VALIDATE) can be done online if you do them in the right order.

The bigger pattern is "expand and contract":

Expand: Add the new column / table / index. Application keeps writing the old way and the new way.
Backfill: In a separate batch job, populate historical data. Do it in small batches to avoid long-running transactions.
Migrate reads: Switch the application to read from the new column.
Contract: Drop the old column.

Never combine "add the new thing" and "drop the old thing" in one deploy. That is how you cause an outage. If you roll back the deploy, the old code now has no column to write to.

A small bonus: things that look safe but are breaking changes

These are the ones that bite you after a few months in production, when someone says "I just added a tiny thing." Memorize this list:

Adding a required field to a request body — old clients break.
Renaming a field (even on a new version) — clients with cached schemas break.
Tightening validation (was 500 chars, now 255) — existing data fails on update.
Changing the sort order of a list endpoint — clients silently get wrong data.
Wrapping a response in an envelope ([...] → { "data": [...] }) — every client breaks.
Changing a timestamp format from "2025-12-01T10:30:00Z" to "2025-12-01T10:30:00+00:00" — both are valid ISO 8601, both are different strings, and string-comparing clients fail.

The pattern: anything that changes the shape or rules of a response is a breaking change, even when the data is "logically the same."

Your pre-ship checklist

A reasonable checklist for your next API or service:

[ ] Mutating endpoints accept an Idempotency-Key header.
[ ] Pagination is cursor-based by default.
[ ] URLs include /v1/ from day one.
[ ] One consistent error envelope across every endpoint.
[ ] HTTP status codes match what actually happened.
[ ] Naming convention enforced by a linter in CI.
[ ] Normalized schema by default, denormalized only on profiled hot paths.
[ ] Every foreign key has an index.
[ ] No N+1 queries — verified by logging actual SQL in dev.
[ ] Schema migrations go through expand-and-contract, never blocking changes on hot tables.

If you ship something with this list checked, you are already operating well above the level most beginner APIs hit production at.

Wrapping up

Here is the honest truth: nobody catches all of these on their first project. I did not. The people writing your favorite developer tools did not. The fastest path to leveling up is not memorizing patterns — it is recognizing the names of the failure modes when you read code, so you can spot them before they hit production.

What is the one mistake from this list that you learned the hard way? Drop it in the comments — I would love to hear it, and so would the next person reading this post.

Happy shipping.

Debugging in the Age of AI: 10 Blunders Beginners Make When They Stop Thinking

Sarim Nadeem — Sat, 13 Jun 2026 04:11:15 +0000

There is a specific scene playing out in offices and bedrooms and university dorms right now, thousands of times a day:

A bug appears.
The developer copies the entire error message.
They paste it into ChatGPT / Copilot / Claude / Cursor.
They paste back whatever code the model spits out.
The error goes away.
They move on.

That last step — "the error goes away, they move on" — is where a generation of developers is silently breaking their own careers.

I am not anti-AI. I use these tools every day. They are genuinely incredible at helping you debug when you already know how to debug. The problem is that beginners are skipping the "learn how to debug" part entirely. They are not getting worse at debugging because they are stupid — they are getting worse because AI hides the symptoms of bad debugging just well enough that you never notice you are doing it wrong.

This post is a tour through what real debugging looks like, and the specific blunders I see beginners make in 2026 because the AI is doing their thinking for them.

The one-line version: AI is a power tool you use inside the debugging loop — it is not a replacement for the loop itself. The developers who keep their debugging skills sharp in the AI era will be the ones in highest demand five years from now.

The systematic debugging loop (the thing AI is letting you skip)

Every effective debugging session follows the same six steps. If you only remember one thing from this post, remember this loop:

Reproduce → Isolate → Bisect → Fix → Verify → Prevent

Step	What it actually means
Reproduce	Get the bug to happen on demand. Exact steps, exact inputs, exact environment.
Isolate	Figure out which layer it lives in — frontend, API, database, infra, third-party.
Bisect	Narrow down further. Which commit? Which function? Which line? Which input?
Fix	Address the root cause, not the symptom.
Verify	Confirm the fix works and nothing else broke.
Prevent	Write a regression test. Add monitoring. Update the runbook.

You will notice that "ask the AI" is not a step. That is intentional. AI is a tool you can use inside any of these steps — but it cannot replace the loop itself. The moment you skip the loop, you are not debugging. You are gambling.

Part 1 — The AI-era beginner blunders

Blunder 1: Pasting the error into the chat without reading it first

This is the foundational mistake. Everything else flows from it.

A stack trace is not garbage text to be handed off to a robot. It is a precise, structured description of what your computer was doing when it failed. The error message tells you the what, the line number tells you the where, and the trace tells you the how you got there.

Before you paste anything into an AI, read it yourself. All of it. Ask:

What is the actual exception class? (NullPointerException vs TimeoutException vs PermissionDenied are completely different stories.)
Which line in your code is at the top of the trace? Not the framework's — yours.
What was the input that caused it?
Is this the original error, or is it wrapping a deeper one? (Look for "caused by" / "during handling of the above exception" / "from previous exception.")

Nine times out of ten, just reading the trace carefully gives you the answer. The other one time, you can ask the AI with vastly more context — and you can tell when its answer is wrong.

If you cannot describe in one sentence what the error is telling you, you are not ready to ask anyone — human or AI — to help you fix it.

Blunder 2: Skipping reproduction because "AI already gave me a fix"

This is the one I see most often, and it is the most dangerous.

The developer sees an intermittent bug. They describe it to the AI. The AI suggests a fix. They apply the fix. The bug appears to go away. They ship it.

Three weeks later, the bug comes back. Or worse — it does not come back, but the user-visible symptom changes into something more subtle that nobody catches for six months.

The rule: If you cannot reproduce the bug on demand before applying a fix, you have no way to verify the fix actually fixed it. You just have a fix you cannot disprove.

A bug you cannot reproduce is a bug you have not understood. Common things to check before you reach for any fix:

What were the exact inputs that triggered it?
Does it happen every time, or sometimes? If sometimes — what is different on the times it happens?
Does it happen in dev, staging, or only production? What is different about those environments?
Is it timing-related? Concurrency? Cache state? Specific data?

This is unglamorous work. AI does not help much with it. You actually have to think. That is the point.

Blunder 3: Patching the symptom and calling it a fix

This is the bug that came from the AI's training data and is now infecting codebases everywhere.

You get a TypeError: cannot read property 'name' of undefined. You paste it in. The AI suggests:

// "Fix" suggested by the AI
if (user && user.name) {
  console.log(user.name);
}

The error goes away. You ship it. You feel smart.

But you never asked the actual question: why is user undefined here in the first place? Should it ever be? Is there a bug upstream that fails to populate it? Is there a race condition where the data has not arrived yet? Is this revealing a deeper problem in how your app handles authentication state?

The AI fixed the symptom. The disease is still there. Six weeks later, you find that user is undefined because an API call silently fails 0.5% of the time — and now you have null-checks littered through the entire codebase masking a real reliability bug.

Always ask "why" at least three times before accepting any fix.

Show the "five whys" walkthrough for this exact bug

Why is user undefined here? → Because the API returned 401.
Why did the API return 401? → Because the token expired.
Why did the token expire without being refreshed? → Because our refresh logic only runs on page load, not before each request.
Why does our refresh logic only run on page load? → Because the original implementation assumed sessions would never outlive a page lifetime.
Why did that assumption hold? → It didn't anymore once we added long-lived single-page navigation.

Now you know what to actually fix: the token refresh policy, not a null-check. The null-check would have hidden the real bug forever.

Blunder 4: Trusting confident-but-wrong AI suggestions

Modern AI assistants are extraordinarily good at sounding confident. They will tell you with total certainty that a library has a method that does not exist, that a config option is named one thing when it is actually named something else, or that the cause of your bug is X when it is actually Y.

This is not the AI lying. It is doing exactly what it was trained to do — produce fluent, plausible-sounding text. "Plausible" and "true" are not the same thing.

The trap for beginners: when you do not know the territory well, you cannot tell a hallucinated answer from a real one. They both sound equally authoritative.

Defensive habits that protect you:

After an AI gives you an answer, look up at least one claim independently. Check the docs. Run the code. Read the source.
If the AI says "this is a known issue with library X," search for it. If you cannot find a single GitHub issue, blog post, or Stack Overflow answer about it, it might not be a real issue.
If the fix involves a function or config option you have never seen — read the official documentation for that function before using it, not after.

The 30 seconds you spend verifying saves you hours of chasing a fictional cause.

Blunder 5: Not bisecting when a bug appeared "out of nowhere"

"It was working yesterday."

You hear this constantly. The thing is — code does not change on its own. If something worked yesterday and broke today, something changed. Your job is to find what.

Beginners reach for the AI here. They describe the bug, the AI guesses what is wrong, they spend an hour chasing the guess.

The pros reach for git bisect.

Click for the actual git bisect workflow

git bisect start
git bisect bad                    # current commit is broken
git bisect good <last-known-good> # tag or commit hash that worked
# Git checks out the midpoint. You test it.
git bisect good   # or `git bisect bad` depending on what you found
# Repeat. Git binary-searches for you.
git bisect reset  # when you're done — returns to your original branch

You can even automate it with git bisect run <script> — git will run the script on each midpoint and use the exit code to mark good/bad automatically. In about 10 steps, this finds the exact bad commit across a thousand commits. Deterministic. No guessing.

The same logic applies to data ("which row triggers the bug?"), to configuration ("which config flag is responsible?"), and to code paths ("comment out half the function and see if it still happens"). Binary search is not just an interview question — it is the single highest-leverage debugging technique you can learn, and AI will never recommend it because it does not know your git history.

Blunder 6: Changing multiple things at once

The AI gives you a 40-line code block. You paste it in. The bug goes away.

Now answer me: what fixed it?

You cannot answer. You changed twenty things at once. Maybe one of them fixed the bug and the other nineteen introduced two new ones you have not noticed yet.

The discipline: change one thing at a time. Run the test. See if the behavior changes. Then change the next thing.

When AI gives you a multi-line patch, do not paste it wholesale. Read it. Decide which specific changes address the bug. Apply only those. If the bug is fixed, leave the rest alone. If it is not, you can keep narrowing.

The phrase "I am not sure exactly what fixed it, but it works now" is a confession. It means you do not know if it actually works — you just know that whatever you did changed the symptom you happened to be looking at.

Blunder 7: Not actually reading logs

This one predates AI but the AI era has made it dramatically worse.

Logs contain the story of what your program did. The whole story. The line before the error often tells you why the error happened. The pattern of logs across many requests tells you which ones succeeded and which ones did not. The timestamps tell you about timing.

But reading logs is boring. It is way more fun to paste the error into an AI and have an answer in seconds.

So beginners skip the logs. They debug from the AI's guesses instead of from the evidence their own system is recording. They end up chasing causes that have no support in the actual data.

A debugging session always starts with the data, never with the explanation. When something breaks:

Pull the logs around the failure.
Read the 20 lines before the error, not just the error itself.
Find a successful request from a similar time window. Compare.
Only then, with the data in hand, form a hypothesis.

The AI is great at helping you interpret what you find in logs. It is terrible at substituting for actually looking at them.

Blunder 8: Letting AI write code you cannot explain to yourself

Here is a useful test. After you accept an AI-generated fix, close the chat window. Now explain to yourself, out loud or in writing:

What this code does, line by line.
Why this particular approach was chosen.
What would happen if [some specific edge case] occurred.
How you would write a test for it.

If you cannot answer any of those, you do not understand the code in your own codebase. You are now maintaining software you cannot reason about. The day a bug appears in that code, you will not be able to debug it — you will have to go ask the AI again, and the AI does not remember the last conversation.

This is the most pernicious long-term effect of AI on beginner developers: a slowly accumulating pile of code in their own repos that they themselves do not understand. Every PR is a small loan against future understanding. Eventually the debt comes due.

The code in your repository is your responsibility. The AI is not on call. You are.

Blunder 9: Skipping verification — "AI said it works"

Closely related to the previous point. The AI generates the fix. You apply it. The original error stops appearing. You ship.

You did not:

Run the test suite.
Test edge cases adjacent to the bug.
Check that performance did not regress.
Verify the fix on production-like data, not your tiny dev dataset.
Check that the AI's "fix" did not break something else.

Verification is the part where you act like a skeptical reviewer of your own work. AI cannot do this for you, because AI does not know what "working" means in your business context. Only you do.

A minimum verification checklist for any fix:

[ ] The original repro case no longer fails.
[ ] The full unit test suite passes.
[ ] At least one new test exists that would have caught this bug.
[ ] You manually tested at least one edge case near the bug.
[ ] You ran the change against a realistic data sample, not just your local one-row test.

Blunder 10: Never asking "how do we prevent this class of bug?"

You fixed the bug. The error stopped. You closed the ticket. Onto the next thing.

But you have a one-time opportunity right now that you will never have again — the opportunity to prevent every future bug like this one from happening.

Could a type system have caught this?
Could a lint rule have caught this?
Could a unit test catch it next time?
Could a monitoring alert catch it before users do?
Is the same anti-pattern present elsewhere in the codebase?
Should this go in the team's debugging runbook so the next person who hits it has a shortcut?

This is the "Prevent" step from the loop at the top, and almost nobody does it — beginners least of all. They are exhausted from the bug. They want it gone. They never harvest the learning.

AI cannot do this step for you, because the learning is about your specific codebase and team. Spend ten minutes on it after every bug. Over a year, this single habit will compound into a meaningful gap between you and the developers who skip it.

A few classic anti-patterns that AI has not solved (it just hides them better)

These are not new — they predate AI. But AI has made them harder to notice, because the AI patches the surface symptom while the underlying habit gets worse.

Debugging by staring at code. If you have been reading the same function for 20 minutes, stop. Run it. Print things. Use a debugger. Code that is not running cannot teach you what it does.
Assuming your mental model is correct. The reason a bug feels impossible is almost always because your mental model of the system is wrong. The bug is reality telling you to update your model. Listen to it.
Confirmation bias. Once you have a theory, you start unconsciously looking for evidence that supports it and ignoring evidence that contradicts it. The most useful question in debugging is: "What would prove my current theory wrong?" Then look for that.
Cargo-cult fixes. "I added a try/catch and the error stopped." Did it? Or is the error now being silently swallowed while the underlying problem continues? try/catch without a deliberate plan for what to do in the catch block is a way of muting your system, not fixing it.

How to actually use AI in debugging (the good version)

I am not telling you to never use AI. I use it for debugging every single day. But there is a way to do it that makes you sharper instead of duller. The shape of it is:

Use AI as a rubber duck, not an oracle. Explain the bug to it. The act of explaining often surfaces the answer yourself before the AI even responds.
Use AI to generate hypotheses, not conclusions. "Give me five possible reasons this could be happening" is a great prompt. "Fix this bug" is not.
Use AI to explain unfamiliar code. Got a stack trace from a library you have never used? Ask the AI to explain what the library does and what that error class usually means. Then go verify in the docs.
Use AI to write the regression test, not just the fix. Once you understand the bug, ask the AI to help you write a test that would have caught it. This is the highest-value use of AI in debugging.
Verify everything. Treat AI output the same way you would treat a Stack Overflow answer from 2014 — useful, often right, sometimes confidently wrong, never the final word.

The beginner checklist

Print this out. Tape it to your monitor. Use it on your next bug.

[ ] I read the error message and stack trace before doing anything else.
[ ] I can reproduce the bug on demand.
[ ] I have looked at the logs, not just the error.
[ ] I have a specific hypothesis about the cause, not just a guess.
[ ] I am changing one thing at a time.
[ ] I am fixing the root cause, not patching the symptom.
[ ] I asked "why" at least three times.
[ ] If AI suggested code, I can explain every line of it.
[ ] I verified the fix with the original repro case and the test suite.
[ ] I wrote a regression test for this bug.
[ ] I asked: "How do we prevent this class of bug from happening again?"

Closing thought

There is no shortcut to becoming a good debugger. AI is not making the skill obsolete — it is making it more valuable, because everyone else is unlearning it.

The developers who will be most in demand five years from now are the ones who can do what AI cannot: sit with a hard bug, form a hypothesis, test it against evidence, and reason their way to a real fix. AI will make the routine parts of that work faster. It will not do the work for you.

Use the tools. Use them aggressively. But do not let them do your thinking for you. The thinking is the job.

What is a debugging mistake AI talked you into recently? Drop it in the comments — I would genuinely love to hear how this is playing out on other people's teams.

Happy debugging. 🔍

"The Frontend Knowledge Gap That AI Won't Close For You": true

Sarim Nadeem — Sat, 06 Jun 2026 04:49:18 +0000

Most tutorials teach you how to build a button. This post teaches you why the browser renders that button, what happens when a user clicks it on a phone with a 3G connection, and why your rendering strategy choice can make or break a business.

Frontend engineering is not the "easy" side of software. It's the side where every millisecond of latency is felt by a real human being, where you ship code that runs on hardware you don't control — thousands of device models, dozens of browser versions, network conditions ranging from fiber to 2G.

Let's break it down from the ground up.

🧱 Part 1 — Component Architecture: The Foundation

Every modern frontend framework — React, Vue, Angular, Svelte — is built on the same core idea: UIs are compositions of reusable, encapsulated pieces called components.

But "make components" is where the easy part ends. The hard questions are: How big should a component be? When do you split one? How do they talk to each other?

How Frameworks Think About Components

Different frameworks model components differently, and understanding the mental model helps you write better code in any of them.

React treats components as functions that return UI descriptions. Given some props and state, you return what the screen should look like. React re-renders a component whenever its state changes or its parent re-renders.

function ProductCard({ product, onAddToCart }) {
  const [quantity, setQuantity] = useState(1);

  return (
    <div className="product-card">
      <img src={product.image} alt={product.name} />
      <h3>{product.name}</h3>
      <p>${product.price}</p>
      <input
        type="number"
        value={quantity}
        onChange={(e) => setQuantity(Number(e.target.value))}
      />
      <button onClick={() => onAddToCart(product.id, quantity)}>
        Add to Cart
      </button>
    </div>
  );
}

Vue uses reactive state that automatically tracks dependencies. When you read a reactive property in a template, Vue records that the template depends on it. When the property changes, only the affected parts re-render — fundamentally different from React's "re-render everything and diff" approach.

Angular uses TypeScript classes with decorators. It relies on zone.js to intercept async operations and trigger change detection. At scale, Angular apps need OnPush change detection to avoid checking the entire component tree after every async event.

💡 The takeaway for beginners: The framework doesn't matter as much as the mental model. Learn one deeply, and the others become variations on the same theme.

Composition Beats Inheritance

In modern frontend development, composition won — and it won decisively. Instead of creating class hierarchies where child components inherit behavior from parents, we build complex components by combining simpler ones.

Why? Because composed components are flexible (they work in contexts the author never anticipated), testable (each piece can be tested alone), and readable (you see every behavior by reading the imports).

// Composition: flexible and explicit
function SearchableList({ items, renderItem }) {
  const [query, setQuery] = useState('');
  const filtered = items.filter(item =>
    item.name.toLowerCase().includes(query.toLowerCase())
  );

  return (
    <div>
      <SearchInput value={query} onChange={setQuery} />
      <ul>{filtered.map(renderItem)}</ul>
    </div>
  );
}

// The parent decides how to render each item
<SearchableList
  items={products}
  renderItem={(p) => <ProductCard key={p.id} product={p} />}
/>

When to Split a Component

This is one of the most common questions in interviews — and in real engineering decisions. Here's a simple framework:

Reuse — The same UI pattern appears in multiple places.
Complexity — The component has grown past ~200-300 lines, or has more than 3-4 independent state variables.
Independent testing — You need to test a specific piece of logic in isolation.
Performance — A section re-renders frequently, and extracting it prevents the parent from unnecessary re-renders.

Don't split just because a component feels "too long." A 400-line component handling one coherent concern is often better than four 100-line components connected by a web of props and callbacks. Premature decomposition creates indirection without value.

Part 2 — Rendering Strategies: The Most Impactful Decision

Rendering strategy is the single most impactful architectural decision in a frontend application. It determines how fast users see content, how your app performs on slow devices, how search engines index your pages, and how much infrastructure you need.

Client-Side Rendering (CSR)

The browser downloads a near-empty HTML file and a JavaScript bundle. JS creates the entire page.

How it works:

Browser gets a mostly empty HTML document.
Downloads and parses a JS bundle (50KB to 2MB+).
JavaScript executes, makes API calls, builds the DOM.
User sees a blank page or spinner until step 3 completes.

Good for: Authenticated dashboards, design tools (Figma), internal tools — anywhere SEO doesn't matter and users expect a loading state.

Bad for: Content sites needing SEO, low-end devices, pages where first meaningful paint matters.

Server-Side Rendering (SSR)

The server runs the app, generates the full HTML, and sends it to the browser. The user sees content immediately. Then JavaScript downloads and "hydrates" the page — attaching event handlers to make it interactive.

The catch — the "uncanny valley": After SSR, the page looks ready but isn't interactive yet. Buttons appear clickable but do nothing until hydration completes. This is arguably worse than a loading spinner because the spinner at least sets expectations correctly.

⚠️ The hydration tax is proportional to your component tree size. Every component that renders on the server must re-render on the client during hydration. This is why frameworks like Astro, Qwik, and React Server Components exist — they're all different strategies for reducing or eliminating the hydration cost.

Static Site Generation (SSG)

Pages are generated at build time and served from a CDN as static files. This is the fastest possible delivery — a CDN can serve a static HTML file in 5-20ms from an edge node, versus 50-500ms for an SSR response.

Works for: Docs, blogs, marketing pages — content that changes infrequently and looks the same for every user.

Breaks when: Content updates constantly, or the page is personalized per user.

Streaming SSR and React Server Components

These are the newer approaches solving the hydration problem:

Streaming SSR sends HTML fragments as they become ready. The browser starts rendering the header immediately while the server is still fetching data for the product grid below.

React Server Components (RSC) are components that run only on the server. Their JavaScript is never sent to the browser. They never hydrate. They can directly access databases without an API layer. Only the interactive parts (buttons, carousels, forms) ship JS to the client.

💡 The practical impact: An e-commerce product page might have 50 components. With traditional SSR, all 50 ship JavaScript to the browser. With RSC, only the interactive ones do — maybe reducing 200KB of code down to 30KB.

Quick Comparison

Strategy	SEO	Speed	Freshness	Best For
CSR	❌	Slow first paint	Always fresh	Dashboards, tools
SSR	✅	Fast first paint	Always fresh	Personalized content
SSG	✅	Fastest	Stale until rebuild	Blogs, docs, marketing
ISR	✅	Fast	Near-fresh	E-commerce products
Streaming SSR	✅	Progressive	Always fresh	Complex pages

The real-world answer: Most applications use a hybrid strategy. The marketing page is SSG. Product pages are ISR. The dashboard is CSR. Search results are SSR. Modern meta-frameworks like Next.js and Nuxt support all of these in a single application.

Part 3 — State Management: Where Clean Architecture Lives or Dies

State management is where frontend projects either stay clean or collapse into an unmaintainable mess. The key insight that separates beginners from experienced engineers: not all state is the same kind of thing.

The State Hierarchy (Exhaust Simpler Options First)

Before reaching for any library, work through this list:

Local component state (useState / ref) — State that lives in one component. Toggle states, form inputs, local UI state. This handles 60-70% of all state in a typical app.
Lifted state — Two siblings need the same data? Lift the state to their common parent. Explicit and debuggable. Handles another 15-20%.
Context (React Context / Vue provide/inject) — Data many components need but that changes infrequently: theme, locale, current user. Context is a dependency injection mechanism, not a state management solution.
Server state library (TanStack Query / SWR) — Data from API calls. This is not "state" you manage — it's a cache of server data. These libraries handle fetching, caching, background refetching, and cache invalidation.
External state library (Zustand / Redux / Jotai) — The remaining 5-10%: complex, frequently changing, shared client state like shopping carts or multi-step wizards.

⚠️ The #1 state management mistake: Using Redux for everything. Storing API responses in Redux. Storing form values in Redux. Storing toggle state in Redux. This creates a massive, hard-to-debug global object. The cure is worse than the disease. For most new projects: TanStack Query for server state, useState for local state, and Zustand if you genuinely need shared client state.

Server State vs. Client State

This distinction is the most important mental model in modern state management:

Server state lives on the server — you're caching a copy. It can become stale. It can be updated by other users. Examples: user profiles, product listings, order history.

Client state exists only in the browser. There's no server truth. It's ephemeral. Examples: whether a modal is open, which tab is active, items in an unsaved draft.

// Server state — use TanStack Query
function useProducts(category) {
  return useQuery({
    queryKey: ['products', category],
    queryFn: () => fetch(`/api/products?cat=${category}`).then(r => r.json()),
    staleTime: 5 * 60 * 1000, // Consider fresh for 5 minutes
  });
}

// Client state — use Zustand
const useCartStore = create((set) => ({
  items: [],
  addItem: (product, qty) => set((state) => ({
    items: [...state.items, { product, qty }],
  })),
}));

Part 4 — Performance: Every Millisecond Counts

Performance isn't a "nice to have." Since May 2020, Google's Core Web Vitals — three specific metrics measuring loading, interactivity, and visual stability — are ranking signals in Google Search. Companies that ignored frontend performance suddenly had SEO teams demanding engineering resources.

The Three Core Web Vitals

LCP (Largest Contentful Paint) — How long until the biggest visible element renders. Target: under 2.5 seconds.

The #1 mistake? Lazy-loading the hero image. loading="lazy" tells the browser "don't load this until it's near the viewport." But the hero image is in the viewport. Lazy-loading it adds 200-500ms of unnecessary delay. The LCP image should always load eagerly with a <link rel="preload"> in the <head>.

INP (Interaction to Next Paint) — How long from when a user clicks/taps to when the browser paints the response. Target: under 200ms. This replaced FID in March 2024 because FID only measured the first interaction — INP measures all of them.

CLS (Cumulative Layout Shift) — How much the page jumps around unexpectedly. Target: under 0.1. Images without dimensions, late-loading ads, and web font swaps are the usual culprits.

💡 Quick wins for CLS: Always set width and height on images (or use aspect-ratio in CSS), reserve space for ads and dynamic content, and use font-display: optional to prevent font-swap layout shifts.

Bundle Size — The Silent Killer

Every kilobyte of JavaScript has three costs: download (network transfer), parse (the browser reads the source), and execute (the engine runs the code). On a fast laptop, these are invisible. On a mid-range phone on 3G, they're brutal:

Bundle Size	Download (3G)	Parse (Mid-range Phone)	Total Delay
100 KB	~1.0s	~0.3s	~1.3s
300 KB	~3.0s	~0.9s	~3.9s
500 KB	~5.0s	~1.5s	~6.5s
1 MB	~10.0s	~3.0s	~13.0s

How to fight it:

Tree shaking removes unused code at build time. import { debounce } from 'lodash' with ES modules only includes that one function, not the entire 72KB library.
Code splitting breaks your bundle into chunks loaded on demand. Each route loads only the JS it needs.
Audit your dependencies. Run npx source-map-explorer or check bundlephobia.com. Common offenders: moment.js (300KB — use dayjs instead), full lodash without tree-shaking (72KB — use lodash-es).

Main Thread Blocking

The browser's main thread handles JS execution, DOM updates, layout, painting, and user input — all on one thread. When your JavaScript runs for 100ms straight, the page freezes. Break up long tasks:

// Bad — blocks the main thread
function processLargeList(items) {
  items.forEach(item => expensiveOperation(item));
}

// Better — yield to the browser between chunks
async function processLargeList(items) {
  const CHUNK_SIZE = 100;
  for (let i = 0; i < items.length; i += CHUNK_SIZE) {
    const chunk = items.slice(i, i + CHUNK_SIZE);
    chunk.forEach(item => expensiveOperation(item));
    await new Promise(resolve => setTimeout(resolve, 0)); // Let the browser breathe
  }
}

For truly CPU-heavy work, use Web Workers — they run in a separate thread so the UI stays responsive.

Part 5 — Testing: What to Test (and What NOT to Test)

The Testing Trophy

For frontend, Kent C. Dodds' Testing Trophy replaces the traditional test pyramid:

Level	Proportion	What to Test
Static analysis (base)	Always on	TypeScript, ESLint catch bugs at compile time
Unit tests	15-20%	Pure functions, hooks with complex logic, utilities
Integration tests (largest!)	50-60%	Component behavior from the user's perspective
E2E tests (top)	15-20%	Critical user journeys — signup, checkout

Why do integration tests dominate? Because a unit test for a React component that tests useState in isolation tells you almost nothing. What matters is: "When the user types in the search box and presses Enter, does the results list update?" That requires rendering the component, simulating user interaction, and checking the output.

Test Behavior, Not Implementation

// ✅ Good — tests what the user experiences
test('adding item to cart updates the count', async () => {
  render(<ProductPage product={mockProduct} />);
  expect(screen.getByText('Cart (0)')).toBeInTheDocument();
  await userEvent.click(screen.getByRole('button', { name: /add to cart/i }));
  expect(screen.getByText('Cart (1)')).toBeInTheDocument();
});

// ❌ Bad — tests implementation details
test('calls setCartItems when clicked', () => {
  const setCartItems = jest.fn();
  jest.spyOn(React, 'useState').mockReturnValue([[], setCartItems]);
  // This breaks on any refactor and tests React, not your code
});

Part 6 — Browser Internals That Actually Matter

You don't need a PhD in browser architecture, but understanding the basics separates engineers who can debug performance issues from those who just guess.

The Event Loop (Simplified)

The browser has two task queues:

Macrotask queue: setTimeout, setInterval, I/O callbacks.
Microtask queue: Promise.then, queueMicrotask.

After each macrotask, the browser drains the entire microtask queue before handling the next macrotask or rendering. This means a chain of Promises can starve the render loop.

The Critical Rendering Path

This is the sequence from receiving HTML to pixels on screen:

Parse HTML → Build DOM tree (starts while still downloading)
Parse CSS → Build CSSOM (CSS is render-blocking — nothing renders until all CSS in <head> is parsed)
Combine DOM + CSSOM → Render tree (only visible elements)
Layout — Calculate geometry: position, size, margins
Paint — Fill in pixels: colors, borders, text
Composite — Combine layers (GPU-accelerated)

The Golden Rule of Animation

Only animate transform and opacity. These are handled by the GPU compositor without touching layout or paint. Animating left, top, width, or height triggers a full layout recalculation on every frame — at 60fps, that's 60 reflows per second.

/* ❌ Bad — reflow every frame */
.animate-bad:hover { left: 100px; top: 50px; }

/* ✅ Good — GPU compositor only */
.animate-good:hover { transform: translate(100px, 50px); }

♿ Part 7 — Accessibility Is Not Optional

Accessibility isn't a feature. It's engineering quality. A button that can't be activated with a keyboard is a broken button for millions of users.

The Non-Negotiable Checklist

Color contrast: Normal text needs at least 4.5:1 ratio.
Keyboard navigation: Every interactive element must be reachable and operable via keyboard.
Focus indicators: When an element gets keyboard focus, show a visible ring (use :focus-visible).
Alt text: Every <img> needs an alt attribute. Decorative images get alt="".
Form labels: Every input needs an associated <label>. Placeholder text is not a label.
Semantic HTML first: <button> is always better than <div role="button">. Native elements give you keyboard handling and screen reader support for free.

💡 The business case beyond lawsuits: Accessible sites perform better for everyone. Semantic HTML improves SEO. Keyboard navigation improves power-user productivity. Accessibility isn't charity — it's good engineering.

Part 8 — Security in the Browser

XSS: The #1 Frontend Vulnerability

Cross-Site Scripting happens when an attacker injects malicious scripts into your page. React's JSX auto-escapes by default, but dangerouslySetInnerHTML bypasses that protection.

Prevention layers:

Output encoding — Use framework defaults. Never insert raw HTML from user input.
Content Security Policy (CSP) — An HTTP header restricting which scripts can run.
Sanitization — Use DOMPurify if you must render user-provided HTML.

Token Storage

Never store auth tokens in localStorage. Any XSS vulnerability can read them. Tokens belong in HttpOnly cookies — they're not accessible from JavaScript, only sent over HTTPS (with Secure), and restricted to same-site requests (with SameSite=Strict).

Part 9 — Modern Trends Worth Knowing

Islands Architecture (Astro) — Render static HTML, hydrate only the interactive components. 80-90% of a content site is static — you only pay the JS cost for the interactive parts.

Resumability (Qwik) — Serializes app state into HTML. No hydration step at all. JavaScript loads only when the user interacts.

Signals (Angular v16+, Solid, Preact) — A fine-grained reactivity primitive that tracks exactly which DOM nodes depend on which values. Eliminates the need for useMemo, useCallback, and React.memo.

Server Actions (React / Next.js) — Call server functions directly from client components without writing API endpoints. Eliminates boilerplate for form submissions.

Edge Rendering — Server rendering at CDN edge nodes (~5-20ms vs ~50-200ms from origin). Near-SSG speed with SSR-level freshness.

Part 10 — Where to Go From Here

If you're just starting your frontend engineering journey, here's a practical roadmap:

Master one framework deeply. React, Vue, or Angular — pick one, understand its mental model, build real things with it.
Learn the browser. DevTools is your best friend. Understand the Network tab, the Performance panel, and the Elements inspector.
Care about performance from day one. Don't bolt it on later. Set a performance budget, measure Core Web Vitals, and treat them like tests.
Write tests that matter. Integration tests with Testing Library. E2E tests for critical paths with Playwright. Skip testing implementation details.
Build accessible by default. Use semantic HTML, test with your keyboard, run axe-core. It's much harder to retrofit accessibility than to build it in.
Read source code. Pick a component library (Radix, Headless UI, shadcn/ui) and read how they handle keyboard navigation, focus management, and ARIA patterns. You'll learn more from reading good code than from any tutorial.

Frontend engineering is deep, nuanced, and constantly evolving. But the fundamentals — how the browser works, how components compose, how state flows, how performance is measured — change slowly. Invest in understanding why things work the way they do, and the frameworks and tools will come naturally.

This post was inspired by the incredible Frontend Engineering deep-dive at DevWeekends Resources. If you want the full senior/staff-level treatment with interview questions and system design walkthroughs, go read the original.

Found this useful? Drop a ❤️ and follow for more engineering deep-dives. Got questions? Hit the comments — I read every one.

The Agent Is Easy. The Loop Is the Job. — A Developer's No-BS Guide to AI Engineering in 2026

Sarim Nadeem — Sat, 30 May 2026 04:06:55 +0000

Every developer I know has had the same experience: you paste something into ChatGPT, it spits out a working component, and you think "holy crap, my job is over." Then you try it on a real codebase with actual edge cases, and the magic evaporates.

That gap — between a flashy demo and something dependable enough to ship — is where a brand-new discipline lives. It's called AI engineering, and it's not what you think.

So What Is an AI Engineer?

Let's kill the confusion early.

An AI engineer is not an ML engineer with a trendier title. ML engineers live in the model layer — training datasets, optimizing architectures, writing white papers. AI engineers live at the application layer. We take pre-trained models (GPT-4o, Claude, Llama, DeepSeek, pick your poison) and turn them into products that survive contact with real users.

The agent is the easy part. The loop is the job.

Think of it this way: a data scientist built the sentiment model. An ML engineer trained and optimized it. Your job as the AI engineer? Wire that model into a product customers actually use, handle every edge case it throws at you, build evaluation pipelines, and keep the whole thing alive in production.

It has more in common with software engineering than academic research. But it requires a fundamentally different mindset than traditional app development — because you're building on top of something non-deterministic.

AI Engineer vs. ML Engineer vs. Software Engineer

Here's the clearest breakdown I can give:

ML Engineer → Trains and optimizes models. Lives in PyTorch, TensorFlow, SageMaker. Deep math. Output: a trained model.

AI Engineer → Builds applications using models. Lives in LLM APIs, LangChain, vector databases, FastAPI. Moderate math. Output: a working product.

Software Engineer → Builds deterministic software systems. Output: web apps, APIs, infrastructure.

The overlap is real — job postings still confuse these roles constantly — but the day-to-day work is completely different. If your output is a trained model, you're doing ML. If your output is a shipped product built on top of someone else's model, you're doing AI engineering.

The Four Skills That Keep Showing Up

Browse AI engineer job postings on LinkedIn (yes, I know, but the data is there) and four skills surface repeatedly:

RAG (Retrieval-Augmented Generation)
Evals (Evaluation pipelines)
Agents (Autonomous multi-step systems)
Production deployment

Three of those are teachable. Production deployment is so specific to your company and stack that the best anyone can do is teach you the questions to ask.

Under those headline skills, the actual daily work breaks down into:

Context engineering — Sending the right tokens to the model at the right time. Tokens are currency. They cost energy and money. The industry is heading toward "tokens per watt" as the real unit of measure.
Tool design — Giving agents the right abilities and making damn sure they don't do the wrong things.
Evaluation — Measuring whether your agent is actually improving, or whether you just feel like it is.
Production reliability — Self-healing, graceful error handling, latency management. The stuff that decides whether your system survives its first week with real users.

The Build → Eval → Improve Loop

Here's the mental model that separates hobbyists from practitioners:

Build → Eval → Improve → Eval → Improve → ...

Building an agent is trivial. Five lines of code with a modern SDK. You can vibe-code it in an afternoon. The part that matters is everything that comes after.

Evaluate where it fails. Figure out why it fails. Apply the right technique to fix that specific failure. Evaluate again. This loop never ends. It's not a project that ships and moves to maintenance mode — it's a continuous feedback cycle on a non-deterministic system.

This is why picking the right metrics is arguably the hardest part of the job. Pick the wrong metrics and your loop generates noise. Pick the right ones and the whole system compounds. Most of the leverage in AI engineering comes from choosing what to measure.

A Practical Adoption Journey (Lessons From the Trenches)

Mitchell Hashimoto — the creator of Vagrant, Terraform, and Ghostty — recently shared his personal AI adoption journey, and it's one of the most grounded takes I've read. A few key lessons stood out:

Drop the chatbot for real work.

Everyone's first AI experience is a chat interface. And for coding, it's limited — you're hoping the model gets it right, then playing whack-a-mole when it doesn't. To find real value, you need agents — systems that can read files, execute programs, and make HTTP requests in a loop.

Reproduce your own work with agents.

This one is painful but brilliant. Do the work manually, then fight an agent to produce identical results without seeing your solution. It's excruciating, but it builds genuine expertise about what agents are and aren't good at.

Engineer the harness, not just the prompt.

Every time an agent makes a mistake, invest the effort to ensure it never makes that mistake again. This means two things:

Better implicit prompting (like an AGENTS.md file with rules based on observed failures)
Actual programmed tools — scripts to take screenshots, run filtered tests, verify outputs

This "harness engineering" is where long-term efficiency compounds. It's the unsexy work that separates people who dabble with AI from people who ship with it.

The Roadmap: What to Actually Learn

If you're a developer looking to transition into AI engineering, here's a realistic phased approach:

Phase 1: Python and Developer Foundations (2-3 months)

Everything in AI engineering runs on Python. Get solid with OOP, Git, CLI tools, and API consumption. This isn't optional — it's the foundation every framework and tool sits on.

Phase 2: LLM Fundamentals and App Development (2-3 months)

Learn how LLMs actually work (tokenization, context windows, temperature). Master prompt engineering, function calling, and the Model Context Protocol (MCP). Build and deploy real AI apps with FastAPI and Docker.

Phase 3: Data, Math, and Machine Learning (3-4 months)

You don't need a PhD, but you do need to understand the science underneath. Statistics, supervised/unsupervised ML, and deep learning fundamentals give you the intuition to debug and improve AI systems rather than just calling APIs blindly.

Phase 4: Embeddings, RAG, and Agents (2-3 months)

This is where it all comes together. Vector databases, semantic search, RAG pipelines, evaluation frameworks, and autonomous agents. This phase covers what companies are actively hiring for right now.

Timeline reality check: if you're starting from scratch, plan for 8-12 months at 10-15 hours per week. Coming from software engineering? 3-5 months. From data science? 3-6 months.

Why This Matters (and Why It's Not Hype)

The numbers are hard to ignore. AI engineers in the US earn a median of roughly $142K per year, with senior roles exceeding $220K and total compensation at top companies reaching $300K-$600K. LinkedIn ranked AI Engineer the fastest-growing job title in the US for two consecutive years.

But more than the salary, it's the nature of the work. If you go look at OpenAI's job postings, they aren't hiring "AI engineers" in the abstract. They're hiring people for one specific slice of the system: tool selection, human-in-the-loop, safety, token optimization. That's the scale of effort required when your product is an agent.

As more companies become AI-native — with the product itself being just an agent — we're going to see massive, specialized teams of AI engineers. This isn't a passing fad. It's the early days of a discipline.

## Start Here, Not Everywhere

If you take one thing from this post, let it be this: stop trying to learn everything at once.

Don't jump to agents before you can comfortably make API calls and handle JSON
Don't chase every new framework (LangChain, LlamaIndex, CrewAI) — learn one deeply first
Don't skip evals. Evals are the difference between "it works sometimes" and "it works"
Don't confuse watching tutorials with building things. Ship something. Anything.

The tools will change. The fundamentals won't. Connecting models to real products, building reliable pipelines, and deploying systems that actually work — that's software engineering, and it stays valuable no matter what the next wave looks like.

The agent is easy. The loop is the job. Welcome to AI engineering.

Further reading:

Engineers Don’t Fail Technical Interviews Because They’re Bad at Tech — They Fail Because They Ignore Communication

Sarim Nadeem — Sun, 24 May 2026 03:50:46 +0000

The biggest engineering disasters are rarely caused by syntax errors. They are caused by misunderstandings, ego clashes, assumptions, silence, and poor communication.

A lot of junior engineers believe that becoming “technically strong” is enough.

So they:

Grind LeetCode for months.
Memorize frameworks.
Learn trendy stacks.
Build side projects.
Watch system design videos at 2x speed.

And then...

They enter a technical interview.

Or a sprint planning meeting.

Or a production incident call.

Or a design review.

And suddenly:

They cannot explain their thought process.
They become defensive when questioned.
They interrupt others.
They freeze under pressure.
They misunderstand requirements.
They cannot communicate trade-offs.
They fail to collaborate.

The painful reality?

Engineering is not just about writing code. Engineering is about reducing ambiguity between humans.

And the engineers who ignore communication and soft skills eventually hit a wall.

The Industry Lie That Damages Engineers

There is a dangerous belief floating around in engineering culture:

“If you are technically good enough, everything else will automatically work out.”

It does not.

Some of the smartest engineers fail interviews, lose promotions, damage team trust, and create toxic work environments because they never learned how to:

communicate clearly,
handle disagreements professionally,
ask good questions,
explain technical decisions,
manage expectations,
listen actively,
or collaborate under pressure.

A company is not hiring a code generator.

A company is hiring someone who can:

think clearly,
communicate effectively,
work with uncertainty,
collaborate with teams,
and solve business problems.

That changes everything.

The Junior Engineer Mistakes That Quietly Destroy Opportunities

1. Confusing Silence With Intelligence

Many junior engineers stay silent in meetings because they think:

“If I ask questions, people will think I am inexperienced.”

In reality?

Senior engineers usually respect thoughtful questions.

What actually hurts you is:

pretending to understand,
making assumptions,
and implementing the wrong thing.

A wrong implementation caused by unclear communication is far more expensive than asking a “simple” question.

Real Industry Example

NASA’s Mars Climate Orbiter mission failed because one engineering team used imperial units while another used metric units.

The result?

A $125 million spacecraft was lost because of communication and coordination failures.

Not because engineers couldn’t code.

2. Treating Feedback Like a Personal Attack

One of the fastest ways to stagnate as an engineer is becoming emotionally attached to your code.

A pull request review is not a war.

Yet many engineers react like this:

Defensive tone.
Passive aggression.
Long argumentative threads.
Refusing suggestions.
Taking critiques personally.

Strong engineers separate:

their identity from
their implementation.

Your code being improved does not mean you are weak.

The engineers who grow the fastest are usually the ones who:

absorb feedback calmly,
ask clarifying questions,
and optimize for learning instead of ego.

3. Explaining Technologies Instead of Solving Problems

This mistake destroys technical interviews.

The interviewer asks:

“Why would you choose Redis here?”

And the candidate starts explaining:

Redis internals,
caching architecture,
persistence mechanisms,
memory models,
and random buzzwords.

But they never answer:

“What business problem does Redis solve in THIS scenario?”

Great engineers connect technology to:

scalability,
latency,
reliability,
user experience,
cost,
and business impact.

Technology is a tool.

Problem solving is the actual job.

Associate-Level Engineers Often Develop a Dangerous Habit

Once engineers gain a little experience, a new problem appears.

Ego.

Not always loud ego.

Sometimes subtle ego.

The kind that appears as:

dismissing juniors,
refusing alternative approaches,
overcomplicating systems,
trying to sound “smart” in meetings,
or turning technical discussions into competitions.

The “Smartest Person in the Room” Trap

Many engineers unknowingly optimize for appearing intelligent instead of being useful.

That leads to:

overengineering,
unnecessary abstractions,
difficult communication,
and team friction.

The best engineers often explain extremely complex systems using simple language.

Because clarity is a sign of mastery.

Not complexity.

Senior Engineers Fail Too — Just Differently

People assume senior engineers have mastered communication.

That is not always true.

Some senior engineers become technically excellent but emotionally difficult to work with.

And that becomes a massive organizational bottleneck.

The Senior-Level Communication Failures Nobody Talks About

1. Destroying Psychological Safety

If junior engineers are afraid to:

ask questions,
admit mistakes,
or share ideas,

then the team becomes slower and more fragile.

The best senior engineers create environments where:

people can think out loud,
uncertainty is acceptable,
and mistakes become learning opportunities.

A fearful team hides problems.

A healthy team surfaces problems early.

2. Winning Arguments Instead of Solving Problems

Technical disagreements are normal.

But immature engineers turn disagreements into:

ego battles,
authority flexing,
or intellectual dominance contests.

Strong engineering culture focuses on:

evidence,
experimentation,
trade-offs,
and shared outcomes.

Not personal victories.

“Tell Me About a Time You Had a Technical Disagreement” — The Interview Question That Exposes Engineers

One of the most revealing interview questions is:

“Tell me about a time you had a significant technical disagreement with a colleague.”

This question is not testing whether you were “right.”

It tests:

emotional intelligence,
collaboration,
conflict management,
professionalism,
and communication maturity.

Many candidates accidentally fail this question.

The Wrong Way To Answer

Here is how weak candidates usually answer:

“My teammate wanted to use X technology, but I knew Y was better. I convinced everyone, and we used my solution.”

This answer silently communicates:

ego,
poor collaboration,
lack of empathy,
and inability to handle disagreement professionally.

The Strong Engineer Response

A mature response sounds more like this:

“We had different opinions regarding the architecture because we were optimizing for different constraints. Instead of debating emotionally, we listed the trade-offs, validated assumptions with data, and aligned on the approach that best matched the business priorities.”

Notice the difference.

The focus shifts from:

personal victory

to:

collaborative problem solving.

That is what companies look for.

Communication During Production Incidents Reveals Real Engineers

Anyone can appear confident when systems are stable.

Pressure reveals communication quality.

During outages and production incidents:

bad communication creates chaos.

Common failures include:

panic-driven messaging,
unclear ownership,
missing updates,
blaming teammates,
emotional reactions,
and assumption-based decisions.

Strong engineers during incidents:

stay calm,
communicate clearly,
provide concise updates,
define ownership,
avoid blame,
and prioritize coordination.

The Hidden Skill: Translating Complexity

One of the most valuable engineering skills is the ability to explain complex technical ideas to:

non-technical stakeholders,
managers,
clients,
designers,
or junior engineers.

If your explanation only makes sense to experts, then communication has failed.

A strong engineer can:

simplify without oversimplifying,
explain trade-offs clearly,
and adapt communication based on the audience.

Why Many Engineers Struggle in Meetings

Most engineers are never taught how meetings actually work.

So meetings become:

vague,
exhausting,
unstructured,
and unproductive.

Common mistakes:

Talking Without Purpose

Speaking more does not make you appear smarter.

Clear, structured communication does.

Not Listening Actively

Many engineers listen only to respond.

Strong communicators listen to:

understand constraints,
identify assumptions,
and uncover hidden problems.

Avoiding Clarification

Ambiguity kills projects.

Good engineers clarify:

scope,
timelines,
responsibilities,
risks,
dependencies,
and expectations.

The Communication Skill That Changes Careers

The highest-paid engineers are often not the people writing the most code.

They are the people who can:

align teams,
reduce confusion,
influence decisions,
mentor effectively,
explain trade-offs,
and create trust.

Because organizations scale through communication.

Not just code.

Verified Case Study: The Challenger Disaster

One of the most tragic examples of communication failure in engineering history was the Space Shuttle Challenger disaster.

Engineers had concerns regarding the O-ring performance in cold temperatures.

But:

communication gaps,
management pressure,
unclear escalation,
and organizational failures

contributed to catastrophic decision-making.

The issue was not purely technical.

It was also communicational and organizational.

Engineering failures are often human failures first.

The Engineers Who Grow Fastest Usually Do These Things

They Ask Better Questions

Instead of trying to sound intelligent, they optimize for clarity.

They Document Clearly

Good documentation is scalable communication.

They Admit Uncertainty

Pretending to know everything destroys trust.

They Stay Calm During Criticism

Professional maturity matters.

They Think in Trade-Offs

Engineering rarely has perfect solutions.

Only trade-offs.

Practical Ways To Improve Your Engineering Communication

1. Practice Explaining Technical Concepts Simply

Try explaining:

APIs,
databases,
caching,
or CI/CD

to non-technical people.

That forces clarity.

2. Write More

Writing improves thinking.

This is one reason strong engineers often:

write documentation,
technical blogs,
RFCs,
design proposals,
and architecture notes.

Clear writing exposes unclear thinking.

3. Learn To Handle Disagreements Calmly

Disagreement is normal.

Emotional escalation is optional.

4. Observe Strong Communicators

Watch how experienced engineers:

ask questions,
structure explanations,
handle pushback,
and simplify complexity.

5. Focus on Understanding Before Responding

This single habit improves:

interviews,
meetings,
code reviews,
leadership,
and collaboration.

Final Thoughts

The engineering world glorifies:

frameworks,
algorithms,
architecture,
and scalability.

But many careers quietly collapse because engineers never learned how to:

communicate clearly,
collaborate professionally,
manage disagreements,
listen actively,
or explain ideas effectively.

The uncomfortable truth?

A technically average engineer with strong communication skills will often outperform a technically brilliant engineer who cannot work effectively with people.

Because modern engineering is a team sport.

Not a solo coding competition.

And the engineers who truly stand out are usually the ones who can:

think deeply,
communicate clearly,
stay calm under pressure,
and align humans around solutions.

That is what real engineering looks like.

Think Like a Senior Engineer

Sarim Nadeem — Sun, 17 May 2026 04:19:16 +0000

Skip this article, and every other technical concept you learn becomes a collection of isolated facts you will forget under interview pressure. Read it first. Read it twice. Practice it daily.

This guide is not about memorizing answers. It is about developing the mental frameworks that separate senior engineers from everyone else. Interviewers at top companies care far more about how you think than what you know. When they ask, "How would you approach a problem you have never seen before?" — they are testing for exactly the skills below.

They do not want a memorized answer — they want to watch you think. These frameworks are your thinking toolkit.

Core Idea: Every technical course teaches what to know. This guide teaches how to think. Master these mental tools, and you can reason through any architectural problem or system failure — even on topics you have never studied before.

1. First Principles Thinking

First principles thinking means decomposing a problem down to its fundamental truths and building your reasoning upward — instead of reasoning by analogy ("Netflix does it this way, so we should too"). It is about understanding the why behind every technical choice so you can make better choices in unfamiliar situations.

The 4-Step Process

What is the actual problem we're solving?
What are the fundamental constraints?
What are all possible ways to satisfy those constraints?
Which way best fits our specific context?

Example: "Why do we need a message queue?"

Analogy Thinking:

"Netflix uses Kafka, so we should use Kafka too."

First Principles Thinking:

"We need decoupling, buffering, and asynchronous processing. With an entry rate of 500 messages per second and a 3-person engineering team, Kafka's operational overhead isn't justified. AWS SQS or RabbitMQ fits our exact constraints better."

Anti-Pattern: Cargo Culting

Cargo culting is blindly copying practices from large tech companies without understanding why those practices exist.

Classic Trap 1: "We need microservices" (when you only have 12 engineers).
Classic Trap 2: "We need Kubernetes" (for a single running service).
Classic Trap 3: "We need NoSQL because it scales" (when standard SQL handles your load perfectly).

Technique: The Five Whys

Ask why? five times on any architectural decision to dig past surface-level choices and uncover the core technical insight.

Surface Level: "We use Redis for caching."           → Why?
First Why:     "Because our API is slow."             → Why is it slow?
Second Why:    "Because we hit the DB every request." → Why every request?
Third Why:     "Because the data changes frequently." → How frequently?
Fourth Why:    "80% of reads are for data that changes only once a day."
Insight →      Use long TTL for static data, short TTL for volatile data,
               and precompute our most expensive queries.

Never say "we should use X because big companies use X." Always explain the specific problem technology X solves in your specific context.

2. Systems Thinking

Systems thinking means understanding that everything is connected. A software system is not a collection of independent parts; it is a web of dependencies, data flows, and shared resources. Changing one component creates ripple effects across others, often in ways you did not predict.

Key Insight: The Optimization Ripple Effect

Imagine you optimize a database query to run 10x faster:

First-order effect: That specific endpoint becomes faster.
Second-order effect: The endpoint can now handle more traffic, rapidly increasing connection pool usage.
Third-order effect: Other critical endpoints sharing the same connection pool start timing out.
Fourth-order effect: Users continuously retry those timed-out endpoints, creating a thundering herd problem.

A junior engineer celebrates the faster query. A senior engineer asks, "What else will this change affect?"

Feedback Loops

Positive (Amplifying) — destabilizing: Server slows down → requests queue up → memory rises → more load → server slows further (retry storms).
Negative (Stabilizing) — self-correcting: Auto-scaling groups, circuit breakers, and rate limiting.

Emergent Behavior

A system behaves in ways no individual component was designed to produce:

Thundering Herd: Caches expire simultaneously, causing all servers to slam the database at the exact same instant.
Metastable Failure: A brief traffic spike pushes a system into a permanently degraded state it cannot recover from without a full restart.
Split-Brain: A network partition causes two nodes to both think they are the cluster leader, leading to data corruption.

Blast Radius Mental Model

Before any engineering change, evaluate the worst-case scenario if it fails:

Blast Radius	Example	Approach
Small	CSS styling changes	Ship directly, fix forward
Medium	New internal API endpoint	Feature flag, canary deploy
Large	Production DB migration	Blue-green deployment, rollback plan
Critical	Core auth system changes	Multi-stage rollout, manual gates

Interview Killer Question: Your service is 99.9% reliable. Each of its 5 downstream dependencies is also 99.9% reliable. What is your actual system success rate?

Answer: 0.999⁵ = 99.5%. System reliability degrades multiplicatively. Your error rate is now 5× worse than any individual part.

3. Trade-Off Thinking

There are no "best" architectural solutions — only architectural trade-offs. Every single engineering decision optimizes for some metrics at the direct expense of others.

The "It Depends" Framework

Whenever you use the phrase "It depends", you must immediately back it up with what it depends on:

Scale: Are we designing for 100 concurrent users or 100 million users?
Team Size: A 3-person startup or a 200-person enterprise department?
Timeline: Fast-moving startup MVP or a highly regulated bank migration?
Constraints: GDPR, HIPAA, SOX — completely non-negotiable?
Budget: What are our infrastructure and licensing cost ceilings?

Interview Pattern: When asked "Should we use X or Y?", never answer directly. Start with: "It depends on several factors..." → enumerate constraints → "Given context Z, I would choose X because..."

Amazon's Reversibility Framework

Two-Way Door (Reversible): Choosing a logging library, tweaking a UI layout, implementing a new feature flag.
→ Strategy: Decide quickly, test in production, reverse it if it fails.

One-Way Door (Irreversible): Selecting a core database schema, defining a public API contract, picking a primary backend language.
→ Strategy: Invest serious time, write extensive design documents, prototype deeply, and sleep on it.

Common Mistake: Spending weeks over-investing in two-way doors (bikeshedding minor tools) while rushing through irreversible one-way doors. Flip this ratio entirely.

YAGNI — You Aren't Gonna Need It

Do not build complex engineering solutions for problems you do not currently have:

No plugin system for an internal tool used by 5 people.
No enterprise Kafka cluster for 10 events per second.
No CQRS patterns for a simple single-database CRUD application.
No abstract database wrapper layer "in case we decide to switch databases later."

When to Over-Engineer (The YAGNI Exceptions):

Security: Never take shortcuts. An SQL injection vulnerability you promise to fix later is a live data breach today.
Data Integrity: Once you corrupt production data, recovery is often impossible.
Core Business Logic: The foundational engine that generates your company's revenue.
API Contracts: Once external consumers depend on your public API schema, modifying it becomes an irreversible one-way door.
Observability: You cannot debug a production incident if you don't have logs when the crash occurs.

4. The Inversion Technique

Instead of asking "How do I make this system work perfectly?", invert the question and ask: "How could this system fail catastrophically?" Then systematically build guardrails to prevent each failure mode.

Example: Designing a Reliable Payment System

Don't ask: "How do I design a reliable payment system?"
Ask: "What are all the ways our payment system can break?"

Failure Mode 1: Charging a customer's card without recording it in our database.
→ Prevention: Write the transaction state to the DB before calling the payment API; enforce unique idempotency keys.
Failure Mode 2: Recording a success state internally without actually processing the charge.
→ Prevention: Run an automated background reconciliation job cross-referencing internal records against provider receipts daily.
Failure Mode 3: Double-charging a customer due to a network glitch.
→ Prevention: Require unique, client-side generated idempotency tokens on every single API request block.

Key Takeaway: Forward thinking leads to the happy path. Inverted thinking forces you to build the structural guardrails that keep that happy path safe from real-world chaos.

5. Thinking in Layers of Abstraction

A senior engineer fluidly moves between different technical zoom levels — from high-level architecture down to low-level implementation details — knowing exactly which layer matters for the problem at hand.

The 10 Layers of Computing

Transistors / Logic Gates
CPU Instruction Sets
Operating System Kernels
Runtimes / Virtual Machines
Language Syntax & Standard Libraries
Frameworks
Application Business Code
API Surface Layers
Distributed System Architecture
Product & Business Logic

Zoom Out when: Designing large distributed architectures, resolving multi-service production bugs, or evaluating long-term business trade-offs with leadership.

Zoom In when: Executing micro-performance optimizations, writing security-sensitive code blocks, or debugging specific low-level memory leaks.

Leaky Abstractions

All non-trivial abstractions leak. You must understand the layer directly below yours to recognize when your abstraction begins to break:

TCP abstracts away network packet loss — but when packet drop rates spike, your connections experience severe latency stalls.
An ORM completely abstracts raw SQL — but it can easily generate unoptimized N+1 queries for complex joins behind the scenes.
Managed Kubernetes abstracts away infrastructure — but an OOM-killed pod will still drag your service into infinite crash loops if unmonitored.

6. The Debugging Mindset

The Scientific Method for Production Bugs

Observe: Gather concrete metrics, stack traces, and structured logs. Never guess.
Hypothesize: Form a specific, testable hypothesis — "The p99 latency spike was caused by the unindexed database lookup introduced in yesterday's 4 PM deployment."
Test: Design a clean isolation experiment to confirm or disprove that specific theory.
Conclude: Confirmed? Deploy the fix. Disproved? That is still massive progress — eliminate that variable and repeat.

The Common Mistake: Shotgun Debugging. Randomly changing code lines hoping the bug disappears. It is incredibly slow, teaches you nothing, and frequently introduces hidden secondary bugs.

"What Changed?" — The First Question

Bugs rarely appear spontaneously. Correlate the exact time the issue started with the exact time a change occurred:

Was there a recent code deployment or configuration update?
Did user traffic patterns shift significantly?
Did an upstream cloud dependency update or an SSL certificate expire?

The Bisection Strategy

When debugging massive systems or large codebases, split the search space in half repeatedly:

Git Bisect: Code worked at commit A but broken at commit G? Test the midpoint commit D to instantly isolate which half contains the breaking change.
System Isolation: Disable half your middleware layers, route traffic away from half the cluster nodes, or comment out half your configuration parameters to isolate the root cause immediately.

7. Growth Mindset

T-Shaped Skills

The Vertical Bar (Deep Expertise): Becoming the go-to expert in one domain (e.g., Database Internals or Frontend Performance). You understand its runtime, compile mechanics, and can debug what others find impossible.
The Horizontal Bar (Broad Literacy): The ability to skim code in unfamiliar languages, have intelligent architecture reviews across teams, and know exactly what questions to ask domain experts.

The Blameless Postmortem Structure

When production systems break, look for systemic engineering failures rather than human blame:

Timeline: A highly accurate, chronological sequence of events.
Root Cause Analysis: Drill deep using the Five Whys until you uncover a systemic process error — never settle for "Engineer X made a typo."
What Went Well: Acknowledge fast detection, great team collaboration, or solid backup recovery.
Action Items: Specific, assigned, and time-bound.

❌ Incorrect: "Improve our test suite."
✅ Correct:   "Add an automated integration test for payment edge-case
               timeouts — assigned to Alice — due by March 15."

8. Decision-Making Under Uncertainty

An 80% Solution Today is Better Than a 100% Perfect Solution in 3 Months. Ship minimal functional increments to learn from real users, rather than over-engineering against hypothetical problems.
Time-Boxing Exploration. Set a strict limit: "We will spend exactly 2 hours investigating this alternative library. At 4 PM, we make our final decision with whatever info we have." This completely halts analysis paralysis.
Architecture Decision Records (ADRs). Maintain a team journal recording every major design choice, alternatives considered, weighted trade-offs, and confidence levels. This defeats hindsight bias entirely.

9. Technical Mental Models

Mental Model	What It Means
Pareto Principle (80/20)	80% of crashes come from 20% of your code. Profile first; optimize only the hot path.
Occam's Razor	A sudden outage is likely a bad config change, not a rare Linux kernel bug.
Conway's Law	System architectures mirror your org's communication structure. Want clean microservices? Create autonomous teams.
Goodhart's Law	Forcing "95% code coverage" results in hollow tests that assert nothing.
Chesterton's Fence	Never remove legacy code until you understand why it exists. That "redundant-looking" conditional is likely protecting against a race condition.
Survivorship Bias	Copying Netflix's microservices while ignoring the hundreds of startups that drowned in operational complexity.

The Daily Practice Framework (15 Minutes)

To fundamentally transform how you approach complex engineering problems, practice these 5 habits daily — 3 minutes each:

Question One Assumption — Pick a technical rule your team takes for granted. Ask: "Is this still true? Was it ever actually true?"
Explain it to a Rubber Duck — Explain a core part of your architecture out loud. Where your explanation stutters or relies on vague jargon is where your understanding has a gap.
Read One Public Postmortem — Analyze an incident report from Cloudflare, GitHub, or AWS. Study their detection speed, depth of the Five Whys, and quality of action items.
Draw One System Diagram — Sketch a high-level data flow diagram of your application on paper. Identify your DB stores, external API dependencies, and single points of failure.
Ask "What Could Go Wrong?" — Look at your current active code branch. Force yourself to list 3 extreme failure modes: What if traffic scales 10x? What if our cache cluster vanishes? What if a partial rollout fails?

Every technical decision is a trade-off. Master the frameworks. Own the thinking.

From One to One Billion: A Guide to System Scalability

Sarim Nadeem — Wed, 22 Apr 2026 12:12:00 +0000

From One to One Billion: A Guide to System Scalability

In the world of modern computing, scalability isn't just a "nice-to-have" feature—it is the difference between a successful application and a system crash. Whether you are building a small app or a global service, understanding how to handle growth is essential.

1. What is Scalability?

At its core, scalability is the property of a system to handle a growing amount of work. It is a characteristic that applies to everything in the tech stack: computers, networks, algorithms, and even networking protocols.

The Two Ways to Scale

When a system needs more power, there are generally two directions to go:

Vertical Scaling (Scale Up): Adding more power (CPU, RAM) to an existing machine.
Horizontal Scaling (Scale Out): Adding more machines to your network to share the load.

2. Concurrency vs. Parallelism

These two terms are often used interchangeably, but they represent very different concepts in logic and execution.

Concurrency

Concurrency is the ability of a system to manage multiple tasks at once. It doesn't necessarily mean they are running at the same instant; instead, the system uses time-sharing (context switching) to juggle them. This improves responsiveness and throughput.

Parallelism

Parallelism is the simultaneous execution of tasks on multiple processing units (like a multi-core CPU).

Key Difference: Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once.

3. High-Performance Computing (HPC) & Scaling Laws

When we talk about extreme levels of performance, we use two specific notions of scaling to measure efficiency:

Strong Scaling: How the solution time varies with the number of processors for a fixed total problem size.
Weak Scaling: How the solution time varies with the number of processors for a fixed problem size per processor.

The Bottleneck Rule: Amdahl’s Law

Amdahl’s Law is the most critical concept to understand when scaling software. It explains a harsh reality: You cannot make a program infinitely fast just by adding more processors.

The speed of your program is always limited by the part that cannot be run in parallel (the "serial" part). If a portion of your code must happen in a specific order, that portion will eventually become your bottleneck.

1. The Formula

To calculate the theoretical speedup of a task, we use this formula:

$$S_{latency}(s) = \frac{1}{(1 - p) + \frac{p}{s}}$$

2. Breaking Down the Variables

$S_{latency}$: This is the Total Speedup you actually achieve.
$p$: The percentage of the program that can be parallelized (e.g., 0.95 for 95%).
$(1 - p)$: The Serial Part that must run one step at a time.
$s$: The Resource Speedup (usually how many CPU cores you are adding).

3. The "Plain English" Explanation

Imagine you are baking a cake.

Parallel Part ($p$): Cracking 10 eggs. If you have 10 people, you can do this almost instantly.
Serial Part ($1-p$): Baking the cake in the oven. No matter how many people you have in the kitchen, the cake still takes 30 minutes to bake.

The Takeaway: If the "baking time" (serial part) takes up 50% of your total process, your total speedup will never exceed 2x, even if you hire a thousand chefs to crack the eggs.

4. Why This Matters for Scalability

When you scale a system, you must identify the serial bottlenecks first. Adding more hardware (Horizontal Scaling) only helps the parts of your code that are "parallel-ready." If your database lock or your network handshake is serial, that is where your scaling will hit a wall.

4. Web Scale Computing

"Web Scale" is a term popularized by cloud giants like Google, Amazon, and Netflix. It refers to architectures that enable extreme levels of agility and scalability.

Web Scale Computing involves:

Interprocess Communication (IPC): The sharing of data between running processes to ensure the system stays synchronized.
Elasticity: The ability to automatically scale resources up and down based on real-time demand.
Indeterminacy: Managing the unpredictable effects that happen when thousands of cores and massive networks interact simultaneously.

5. Why Does This Matter?

Understanding these principles allows you to build systems that don't just work today, but continue to work as your user base grows. By mastering the balance between IPC, Parallelism, and Horizontal Scaling, you can achieve "Web Scale" levels of performance.

The Internet’s Bouncer: A Clear Guide to SOP and CORS

Sarim Nadeem — Tue, 14 Apr 2026 11:06:57 +0000

The Internet’s Bouncer: A Clear Guide to SOP and CORS

If you’ve ever seen a red error message in your browser console shouting about "Cross-Origin Request Blocked," you’ve met the web’s most important security duo: SOP and CORS.

Here is everything you need to know to understand how they work together to keep the web safe.

What is Same-Origin Policy (SOP)?

The Same-Origin Policy (SOP) is a fundamental security feature implemented by web browsers. It’s like the internet’s bouncer, preventing web pages from making requests to different origins unless they match.

Without SOP, malicious websites could easily access sensitive data on other tabs you’ve got open—imagine your bank account details hanging out for all to see!

What Defines an "Origin"?

If any of these three components differ between two URLs, they are considered to have different origins:

Protocol (e.g., http vs. https)
Domain (e.g., example.com vs. api.example.com)
Port (e.g., :80 vs. :443)

Example:

https://example.com:443/page1  ✅ Same origin as https://example.com:443/page2
http://example.com/page1       ❌ Different origin from https://example.com/page2 (different protocol)

How SOP Restricts Interactions

To protect your data, the browser restricts what scripts can do across origins:

Cookies: You can only access cookies for your own origin.
Storage: LocalStorage and SessionStorage are origin-specific. No peeking at someone else’s data!
DOM Access: A script from Origin A cannot access the DOM of a page from Origin B.
AJAX/Fetch Requests: Requests are blocked by default unless explicitly allowed.

What Is CORS (Cross-Origin Resource Sharing)?

CORS is a security feature that allows or restricts resources on a web server to be requested from a different domain. It’s like giving permission to certain websites to knock on your server’s door and grab some data.

Without CORS, web pages are locked in their own origin-sandbox, unable to communicate with external APIs, CDNs, or other resources.

Why Is CORS Important?

Enforces SOP: It makes the strictness of SOP flexible for legitimate communication.
Controlled Sharing: Servers can whitelist specific domains to keep data safe.
Prevents Attacks: It helps protect against attacks like Cross-Site Request Forgery (CSRF) and Cross-Site Scripting (XSS).

The CORS Workflow

1. Simple Requests

These include GET, POST, and HEAD requests that don’t require special handling.

The browser sends the request with an Origin header.
If the server returns an Access-Control-Allow-Origin header that matches, all is good.

2. Preflight Requests

These are like asking the server, "Hey, is it cool if I send a DELETE request?" before making the actual request. This is done via an OPTIONS call.

CORS Headers You Should Know

Access-Control-Allow-Origin: Specifies which origins are allowed access.
Access-Control-Allow-Methods: Defines permitted HTTP methods (GET, POST, etc.).
Access-Control-Allow-Headers: Specifies which custom headers can be used.
Access-Control-Allow-Credentials: Allows cookies or authorization headers to be included.

The Wildcard Policy

A wildcard * is appropriate when an API response is intended to be accessible to any code on any site, such as Google Fonts.

Note: The value of * is special because it does not allow requests to supply credentials. This means it won't allow HTTP authentication, SSL certificates, or cookies to be sent in the cross-domain request.

Summary

SOP is the "Default Deny" policy that keeps your browser secure.
CORS is the "Explicit Allow" protocol that lets modern web apps talk to each other.

Happy coding!