010 — API Design Mistakes
and what to ship instead
Five API design mistakes and what to ship instead:
✕ 200 OK with "error" in the body |
✓ Use the status code — 400, 404, 409 |
✕ /getUserData, /createNewUser |
✓ Nouns plus methods — GET /users, POST /users |
| ✕ Returning every field, every time | ✓ Page it, filter it, let callers ask for less |
| ✕ Breaking changes on the same URL | ✓ Version it, and deprecate loudly |
| ✕ Stack traces in the error response | ✓ A stable error code and a safe message |
📺 Watch the Short · published Aug 4
011 — Security Habits
no security team required
Five security habits that take about five minutes each:
| ✕ Secrets committed to the repo | ✓ Environment variables or a secret store |
| ✕ SQL built by string concatenation | ✓ Parameterized queries, every time |
| ✕ Trusting input because the UI validated it | ✓ Validate again on the server — always |
| ✕ Rolling your own password hashing | ✓ bcrypt, scrypt, or Argon2 — never MD5 |
| ✕ Dependencies untouched for a year | ✓ Automate the update PRs, patch the CVEs |
📺 Watch the Short · published Aug 5
012 — Flaky Tests
before you hit re-run again
Five moves when a test is flaky — because flaky is a bug, not bad luck:
- → Stop hitting re-run — flaky is a bug, not bad luck.
- → Run it 100 times in a loop to catch the failure.
- → Hunt shared state left behind by other tests.
- → Replace sleeps with a wait on a real condition.
- → Freeze the clock instead of asserting on real time.
📺 Watch the Short · published Aug 6
013 — Client Problems, Not Code
they want the problem gone
Five habits that separate a developer from an engineer a client keeps calling back:
| ✕ Building exactly what they asked for | ✓ Finding out what they actually need |
| ✕ Quoting the build before you understand it | ✓ Asking what happens if they do nothing |
| ✕ Writing code when a tool already does it | ✓ Recommend the tool — lose the job, keep the client |
| ✕ Measuring success in features shipped | ✓ Measuring it in the problem disappearing |
| ✕ Being the developer they hired once | ✓ Being the engineer they call next time |
📺 Watch the Short · published Aug 11
014 — Estimates
before you say a number
Five moves for the moment someone asks how long it'll take:
- → Never answer with a number on the spot.
- → Estimate the unknowns, not the code.
- → Break it down until each piece is a day or less.
- → Give a range, and say what would widen it.
- → Re-estimate out loud the moment scope moves.
📺 Watch the Short · published Aug 12
015 — Tech Debt
what to fix, what to leave
Four checklists for tech debt — how to tell real debt from personal taste, which debt is worth paying now, and how to actually get time for it:
Before you call it tech debt
- It slows every change down
- It causes the same bug twice
- It blocks the next feature
- Not just "I'd write it differently"
Debt worth paying now
- You touch that code weekly
- It's behind repeat incidents
- New joiners trip on it
- The fix is smaller than the pain
Debt you can live with
- Nobody has touched it in a year
- Ugly, but covered by tests
- It's getting deleted next quarter
- It's boring and it works
How to get time for it
- Attach it to a feature you're shipping
- Quantify it in hours lost per week
- Fix it while you're already in there
- Never ask for a "refactor sprint"
📺 Watch the Short · published Aug 13
016 — Caching Mistakes
and what each one costs
Five caching mistakes and the fix for each:
| ✕ Caching before you've measured | ✓ Find the slow call first, then cache it |
| ✕ A cache key with no expiry | ✓ Set a TTL you can actually defend |
| ✕ Caching per user what everyone shares | ✓ Cache the shared thing once |
| ✕ Serving stale data silently | ✓ Invalidate on write, not on hope |
| ✕ An outage when the cache goes down | ✓ Fall back to the source — degrade, don't die |
📺 Watch the Short · published Aug 18
017 — Error Handling
that decide how bad the bug gets
Five error handling habits:
| ✕ Returning null when something fails | ✓ Throw, or return a typed result |
✕ Catching Exception at every layer |
✓ Catch only where you can recover |
| ✕ "Something went wrong" | ✓ Say what failed and what to do next |
| ✕ Retrying forever on any failure | ✓ Bounded retries, exponential backoff |
| ✕ Validating deep in the call stack | ✓ Reject bad input at the edge |
📺 Watch the Short · published Aug 19
018 — Saying No
without being difficult
Five ways to say no without becoming the difficult one:
- → Say yes to the goal, no to the approach.
- → Show the trade: "yes, and this slips."
- → Ask which item they'd drop instead.
- → Offer the smaller version that ships this week.
- → Put the no in writing — kindly, and once.
📺 Watch the Short · published Aug 20
019 — Git Undo
before you panic
Five git recovery moves for when something's gone wrong:
- → Wrong branch? Cherry-pick it over, then reset.
- → Bad message?
git commit --amend, before you push. - → Already pushed?
git revert— never reset a shared branch. - → Lost a commit?
git reflogremembers what log forgot. - → Half-done work in the way?
git stash, then carry on.
📺 Watch the Short · published Aug 25
020 — Asking For Help
that make you look senior
Five ways to ask for help that read as senior rather than junior:
| ✕ "It doesn't work" | ✓ "X fails with Y — I tried Z" |
| ✕ Asking before you've tried anything | ✓ Showing what you already ruled out |
| ✕ DMing one person and waiting | ✓ Asking in the channel, where anyone can answer |
| ✕ Burning a day rather than admitting it | ✓ Time-box it — 30 minutes, then ask |
| ✕ Disappearing once they've helped | ✓ Post what actually fixed it |
📺 Watch the Short · published Aug 26
021 — Git Habits — Branching
the branching ones
Five more git habits that read as junior, this time about branching and history:
| ✕ A branch called "fix" or "test2" | ✓ Name it for the change: fix/login-timeout |
| ✕ Merging main into your branch five times | ✓ Rebase onto main, keep the history linear |
| ✕ One branch alive for three weeks | ✓ Merge small, merge often |
| ✕ Resolving conflicts by taking yours | ✓ Read both sides, then re-run the tests |
✕ git pull leaving merge commits everywhere |
✓ git pull --rebase, and make it the default |
📺 Watch the Short · published Aug 27
More Quick Tips
New ones land most weeks — see everything tagged tips, or subscribe on YouTube.